What s Next | Mastering Resin

Hessian Specification

All of the work you've done to this point is based on a specification developed by Caucho for the Hessian protocol. The protocol is based on tokens followed by data for serialization, calls, replies, and messages. In this section we detail what Hessian is doing behind the scenes.

Serialization

All data that needs to be sent from a client to a service or from the service to the client is serialized into a token and possibly additional data. The conversions for the supported structures are as follows:

NULL— Represented by a single byte 'N'.
boolean— Represented by the byte `T' or 'F'.
int— Represented by the bytes `I' 0x01 0x02 0x03 0x04, where the bytes of the 32-bit integer are represented by the 0x01, 0x02, 0x03, and 0x04.
long— Represented by the bytes 'L' 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08.
double— Represented by the bytes 'D' 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08.
string— Represented by chunks of data using 'S' and 's' bytes. The 'S' byte represents a final chunk of data, and 's' is the initial chunk. If there is only one chunk of data, the 'S' byte is used. The first two bytes after the 'S' or 's' is the length of the string in 16 bits. The string is 16-bit Unicode UTF-8 encoded.
xml— An XML document is sent in the same manner and format as a string, but the token bytes are 'X' and 'x'.
date— Represented by a 64-bit long consisting of the milliseconds since the epoch. The token byte is 'd'.
binary— Represented by chunks, using 'B' as final and 'b' as initial chunk tokens. Each token is followed by 16-bit length bytes.
list— Represented by the token 'V', then 't', followed by a length of the format 10x00 0x00 0x00 0x03, and then the type value itself; for example, V t 10x00 0x00 0x02 AB. The 't' is undefined in the spec and is available for use by the application. After this initial header information, the values in the list are represented using the values already defined. The last token is a 'z' to indicate the end of the list.
map— Used to represent serialized objects as well as Map objects. The format is 'M', 't' followed by a 16-bit length and the type value itself. In a serialized object, the type name is the object name. In a map, the 't', length, and value may be blank. After this initial header information, the values in the object or map are listed using the values already defined. The last token is a 'z' to indicate the end of the list.
ref— A reference to a previous map or list is represented by 'R' followed by an integer indicating the position where the map or list previously appeared.
remote— A reference to a remote object is represented by 'r' 't' 16-bit length <object type> 'S' length <utf-8 URL>.

Calls

A call from a client to a service indicates the client's desire to invoke the remote object and an appropriate method. All parameters to the method are serialized using the rules outlined in the previous section. The call is represented by this sequence:

 c 0x01 0x00 <header> m <16-bit length> <method name> <parameters> z

The <header> is a placeholder for adding name/value pairs to a method call. An example might be a transaction.

Reply

A call to a service method always results in a reply. There are two possible replies: valid and fault. The valid reply is designated by this sequence:

 r 0x01 0x00 <header> <serialized return value> z

The fault reply is designated by this sequence:

 r 0x01 0x00 <header> <fault> z

The fault is a serialized map containing code, message, and detail values for the fault.