CometD is a library collection that allows developers to write web messaging applications: you can send messages from servers to client, from clients to servers, from clients to other clients (via servers), and from server to server (using its clustering solution).
I wrote about these styles of communications in a previous blog post.
CometD 3.0.3 has been released, and it ships a new feature: a simpler API for remote calls.
Most web messaging applications typically just need the concept of message exchanges: they don’t need a request/response paradigm (although they may require some form of acknowledgment that the message has been received by the server).
However, for certain use cases, the application may need a way to send a message that requires a response, effectively using messages to implement remote procedure calls.
CometD has always supported this use case through the use of service channels.
However, applications had to write some code to correlate the request with the response and to handle timeouts and errors. Not much code, but still.
CometD 3.0.3 introduces a new, simpler API to perform remote calls, that takes care under the hood to perform the request/response correlation and to handle timeouts and errors.
From a JavaScript client you can now do (full docs):
cometd.remoteCall("findContacts", { status: "online" }, 5000, function(response)
{
if (response.successful)
displayContacts(response.data);
});
You specify a target for the remote call ("findContacts"), the argument object ({status:"online"}), the timeout in milliseconds for the call to complete (5000), and a function that handles the response.
On the server side, you define a method target of the remote call using the annotation @RemoteCall (full docs):
@Service
public class RoomService
{
@RemoteCall("findContacts")
public void findContacts(RemoteCall.Caller caller, Object data)
{
Map filter = (Map)data;
ServerSession client = caller.getServerSession();
try
{
List contacts = findContacts(client, filter);
// Respond to the client with a success.
caller.result(contacts);
}
catch (Exception x)
{
// Respond to the client with a failure.
caller.failure(x.getMessage());
}
}
}
The target method may implement its logic in a different thread (this is recommended if the computation takes a long time), or even forward the request to another node via an OortService.
The target method must respond to the caller, but it may also broadcast other messages or send to the caller additional messages along with the response.
The possibilities are limitless.
Contacts us if you have any question or if you want commercial support for your CometD application development and support.