![]() | ![]() | ![]() | ||||||||||||||||||||||||||||||||||||
![]() | ||||||||||||||||||||||||||||||||||||||
documentation examples changes overview quick start installation command-line configuration admin amber clustering caching database deployment ejb 3.0 embedding filters hessian hmtp ioc jsp logging messaging performance quercus/php remoting scheduled tasks security server push servlets third-party troubleshooting virtual hosting watchdog webapp xml and xslt hessian hessian 1.0 spec hessian 2.0 draft spec java binding burlap burlap 1.0 spec burlap design notes hessian messaging | hessian 1.0.2 specification
Hessian is a compact binary protocol for connecting web services. Because Hessian is a small protocol, J2ME devices like cell-phones can use it to connect to Resin servers. Because it's powerful, it can be used for EJB services. The Hessian web services protocol was created as a lightweight binary alternative to the XML-based web services protocols. The Hessian home page contains the latest information about Hessian. Unlike older binary protocols, Hessian is both self-describing and portable across languages. The wire protocol for web services should be invisible to application writers. Wire protocols should not require external schema or IDL. Given the EJB environment, the Hessian protocol has the following requirements:
Hessian's object serialization has 9 primitive types:
It has 2 combining constructs: Finally, it has 2 special contructs: nullNull represents a null pointer. The byte represents the null pointer.values are allowed in place of any , , , , , or . null null ::= N intA 32-bit signed integer. An integer is represented by the byte followed by the 4-bytes of the integer in big-endian orderint ::= I b32 b24 b16 b8 integer 300 I x00 x00 x01 x2c longA 64-bit signed integer. An long is represented by the byte followed by the 8-bytes of the integer in big-endian orderlong ::= L b64 b56 b48 b40 b32 b24 b16 b8 long 300 L x00 x00 x00 x00 x00 x00 x01 x2c doubleA 64-bit IEEE floating pointer number. double ::= D b64 b56 b48 b40 b32 b24 b16 b8 double 12.25 D x40 x28 x80 x00 x00 x00 x00 x00 dateDate represented by a 64-bits long of milliseconds since the epoch. date ::= d b64 b56 b48 b40 b32 b24 b16 b8 2:51:31 May 8, 1998 d x00 x00 x00 xd0 x4b x92 x84 xb8 stringA 16-bit unicode character string encoded in UTF-8. Strings are encoded in chunks. represents the final chunk and represents any initial chunk. Each chunk has a 16-bit length value.The length is the number of characters, which may be different than the number of bytes. string ::= (s b16 b8 utf-8-data)* S b16 b8 utf-8-data "Hello" string S x00 x05 hello xmlAn XML document encoded as a 16-bit unicode character string encoded in UTF-8. XML data is encoded in chunks. represents the final chunk and represents any initial chunk.Each chunk has a 16-bit length value. The length is the number of characters, which may be different than the number of bytes. xml ::= (x b16 b8 utf-8-data)* X b16 b8 utf-8-data trivial XML document X x00 x10 <top>hello</top> binaryA binary value. Binary data is encoded in chunks. represents the final chunk and represents any initial chunk. Each chunk has a 16-bit length value.binary ::= (b b16 b8 binary-data)* B b16 b8 binary-data listAn ordered list, like an array. All lists have a type string, a length, a list of objects, and a trailing 'z'. The type string may be an arbitrary UTF-8 string understood by the service (often a Java class name, but this isn't required.) The length may be -1 to indicate that the list is variable length. list ::= V? ? * z Each item is added to the reference list to handle shared and circular elements. See the element.Any parser expecting a must also accept a or a shared .serialization of a Java int[] = {0, 1} V t x00 x04 [int l x00 x00 x00 x02 I x00 x00 x00 x00 I x00 x00 x00 x01 z anonymous variable-length list = {0, "foobar"} V I x00 x00 x00 x00 S x00 x06 foobar z mapRepresents serialized objects and Maps. The element describes the type of the map. Objects are represented by a map from field names to their values and is the class of the object itself.map ::= M t b16 b8 type-string (, )* z The may be empty, i.e. a zero length. The parser is responsible for choosing a type if one is not specified. For objects, unrecognized keys will be ignored.Each is added to the reference list. Any time the parser expects a , it must also be able to support a or a .Serialization of a Java Object public class Car implements Serializable { String model = "Beetle"; String color = "aquamarine"; int mileage = 65536; } M t x00 x13 com.caucho.test.Car S x00 x05 model S x00 x06 Beetle S x00 x05 color S x00 x0a aquamarine S x00 x07 mileage I x00 x01 x00 x00 z A sparse array map = new HashMap(); map.put(new Integer(1), "fee"); map.put(new Integer(16), "fie"); map.put(new Integer(256), "foe"); M I x00 x00 x00 x01 S x00 x03 fee I x00 x00 x00 x10 S x00 x03 fie I x00 x00 x01 x00 S x00 x03 foe z refAn integer referring to a previous or instance. As each or is read from the input stream, it is assigned the integer position in the stream, i.e. the first or is '0', the next is '1', etc. A later can then use the previous object. Writers are not required to generate , but parsers must be able to recognize them.ref ::= R b32 b24 b16 b8 can refer to incompletely-read items. For example, a circular linked-list will refer to the first link before the entire list has been read. A possible implementation would add each and to an array as it's read. The will return the corresponding object from the array. To support circular structures, the implementation would store the or immediately, before filling in the object's contents.Each <list> or <array> is stored into an array as it is parsed. <ref> selects one of the stored objects. The first object is numbered '0'. circular list list = new LinkedList(); list.head = 1; list.tail = list; M t x00 x0a LinkedList S x00 x04 head I x00 x00 x00 x01 S x00 x04 tail R x00 x00 x00 x00 z remoteA reference to a remote object. The remote has a and a utf-8 string representing the object's URL.remote ::= r t b16 b8 type-name S b16 b8 url EJB Session Reference r t x00 x0c test.TestObj S x00 x24 http://slytherin/ejbhome?id=69Xm8-zW A Hessian call invokes a method on an object with an argument list. The object is specified by the container, e.g. for a HTTP request, it's the HTTP URL. The arguments are specified by Hessian serialization. call ::= c x01 x00* m b16 b8 method-string ( )* z obj.add2(2,3) call c x01 x00 m x00 x04 add2 I x00 x00 x00 x02 I x00 x00 x00 x03 z obj.add2(2,3) reply r x01 x00 I x00 x00 x00 x05 z Object Naming (non-normative)URLs are flexible enough to encode object instances as well as simple static service locations. The URL uniquely identifies the Hessian object. Thus, Hessian can support object-oriented services, e.g. naming services, entity beans, or session beans, specified by the URL without requiring extra method parameters or headers. Object naming may use the query string convention that "?id=XXX" names the object "XXX" in the given service. This convention is recommented, but not required. For example, a stock quote service might have a factory interface like http://foo.com/stock and object instances like http://foo.com?id=PEET. The factory interface would return valid object references through the factory methods. Object naming (non-normative)As an example, the following format is used for EJB: http://hostname/hessian?id= identifies the EJB container. In Resin-EJB, this will refer to the EJB Servlet. "/hessian" is the servlet prefix (url-pattern.) HTTP is just used as an example; Hessian does not require the use of HTTP. , the path info of the request, identifies the EJB name, specifically the home interface. EJB containers can contain several entity and session beans, each with its own EJB home. The corresponds to the ejb-name in the deployment descriptor. identifies the specific object. For entity beans, the object-id encodes the primary key. For session beans, the object-id encodes a unique session identifier. Home interfaces have no ";ejbid=..." portion. Example Entity Home Identifier http://localhost/hessian/my-entity-bean Example Entity Bean Identifier http://localhost/hessian/my-entity-bean?ejbid=slytherin Example Session Home Identifier http://localhost/hessian/my-session-bean Example Session Bean Identifier http://localhost/hessian/my-session-bean?ejbid=M9Zs1Zm Methods and OverloadingMethod names must be unique. Two styles of overloading are supported: overloading by number of argumetns and overloading by argument types. Overloading is permitted by encoding the argument types in the method names. The types of the actual arguments must not be used to select the methods. Method names beginning with are reserved.Servers should accept calls with either the mangled method name or the unmangled method name. Clients should send the mangled method name. Note See the Java binding for a possible overloading scheme.add(int a, int b) add_int_int add(double a, double b) add_double_double add(shopping.Cart cart, shopping.Item item) add_shopping.Cart_shopping.Item ArgumentsArguments immediately follow the method in positional order. Argument values use Hessian's serialization. All arguments share references, i.e. the reference list starts with the first argument and continues for all other arguments. This lets two arguments share values. remote.eq(bean, bean) bean = new qa.Bean("foo", 13); System.out.println(remote.eq(bean, bean)); c x01 x00 m x00 x02 eq M t x00 x07 qa.Bean S x00 x03 foo I x00 x00 x00 x0d z R x00 x00 x00 x00 z The number and type of arguments are fixed by the remote method. Variable length arguments are forbidden. Implementations may take advantage of the expected type to improve performance. HeadersHeaders are (string, object) pairs that preceed the arguments. The value of the header can be any serialized object. For example, a request might include a transaction context in a header. Call with Distributed Transaction Context c x01 x00 H x00 x0b transaction r t x00 x28 com.caucho.hessian.xa.TransactionManager S x00 x23 http://hostname/xa?ejbid=01b8e19a77 m x00 x05 debug I x00 x03 x01 xcb z valid-reply ::= r x01 x00* z fault-reply ::= r x01 x00 * z ValueA successful reply returns a single value and possibly some header information. integer 5 result r x01 x00 I x00 x00 x00 x05 z FaultsFailed calls return a .Each fault has a number of informative fields, expressed like <map> entries. The defined fields are , , and . is one of a short list of strings defined below. is a user-readable message. is an object representing the exception. In Java, will be a serialized exception.Remote Call throws FileNotFoundException r x01 x00 f S x00 x04 code S x00 x10 ServiceException S x00 x07 message S x00 x0e File Not Found S x00 x06 detail M t x00 x1d java.io.FileNotFoundException z z
Metadata is handled by special method calls, methods beginning with .returns a string. The following attributes are predefined by this spec:
"java.api.class" returns the client proxy's Java API class for the current URL. "java.home.class" returns the API class for the factory URL, i.e. without any "?id=XXX" query string. "java.object.class" returns the API class for object instances. In the case of services with no object instances, i.e. non-factory services, all three attributes will return the same class name. Obsolete meta data properties
A "Micro Hessian" implementation may omit support for the "double" type. ::= ::= ::= c x01 x00 * * z ::= r x01 x00 * z ::= r x01 x00 * z ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= H b16 b8 header-string ::= m b16 b8 method-string ::= f ( )* z ::= V ? ? * z ::= M ? ( )* z ::= r ? ::= t b16 b8 type-string ::= l b32 b24 b16 b8 ::= N ::= T ::= F ::= I b32 b24 b16 b8 ::= L b64 b56 b48 b40 b32 b24 b16 b8 ::= D b64 b56 b48 b40 b32 b24 b16 b8 ::= d b64 b56 b48 b40 b32 b24 b16 b8 ::= (s b16 b8 string-data)* S b16 b8 string-data ::= (x b16 b8 xml-data)* X b16 b8 xml-data ::= (b b16 b8 binary-data)* B b16 b8 binary-data ::= R b32 b24 b16 b8 © Copyright 2000-2004 Caucho Technology, Inc. All Rights Reserved. Any party may implement this protocol for any purpose without royalty or license fee, provided that the implementation conforms to this specification. Caucho Technology reserves the right to create a test suite, freely available without royalty or license fee, to validate implementation conformance. The limited permissions granted herein are perpetual and may not be revoked by Caucho Technology or its successors or assigns. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and these paragraphs are included on all such copies and derivative works. This document and the information contained herein is provided on an "AS IS" basis and CAUCHO TECHNOLOGY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. changes in V3
changes in V2
|