HMTP/WebSocket - actor messaging for Hessian
As we get closer to finishing up the web profile for Resin and as the WebSocket draft works through the IETF committee, we have the opportunity to make Hessian a full actor messaging protocol, not just limited to RPC calls.
The idea of HMTP is to redesign XMPP (Jabber) as a binary actor protocol using Hessian, and simplify the model by removing the IM-specific parts. The messaging model means HMTP can be non-blocking, and can support bidirectional messaging: unsolicited messages from the server and the client.
Each HMTP Actor has a unique JID (Jabber identifier), which resembles an email address:
harry@tictactoe.com/13
The “/13″ is an optional resource identifier, because harry might have multiple connections to the server (or an Actor programming model might have multiple load-balanced Actors like MDB queues.)
In Java, the basic API is a stream with two messaging styles: one-way messages, and RPC get/set, which covers the important messaging patterns:
class ActorStream {
// The actor's jid
String getJid();
// message (one-way)
void message(String to, String from, Serializable payload);
// RPC calls - "get" is like a REST get, and "set" is like a REST POST/PUT
// i.e. get has no side-effects
void queryGet(long qid, String to, String from, Serializable payload);
void querySet(long qid, String to, String from, Serializable payload);
void queryResult(long qid, String to, String from, Serializable payload);
// errors
void messageError(String to, String from, Serializable payload, ActorError error);
void queryError(long qid, String to, String from, Serializable payload, ActorError error);
}
The qid (query-id) is needed in the RPC calls to match the get/set with the corresponding result or error.
Unlike RPC Hessian, HMTP is non-blocking. A queryGet RPC call returns when the packet is sent. The actor will receive the result message as a normal message. There may even be one-way messages interleaved between or queries returning out of order.