- hessian
- quercus/php
- resin 3.0
- resin 3.1
- resin 4.0
-
- changes
- configuration
- examples
- installing
- overview
- starting
-
- guide: admin
- admin
- amber
- bam
- caching
- clustering
- comet
- database
- deployment
- ejb 3.0
- embedding
- filters
- ioc
- jsf
- jsp
- logging
- messaging
- quercus
- remoting
- security
- resources
- servlets
- third-party
- troubleshooting
- virtual host
- watchdog
- webapp
|
| | ||||||||||||||||
|
The Burlap protocol was created to solve a specific problem: Allow Java Enterprise Java Beans (EJB) services to interoperate with non-Java servers and clients using an XML-based protocol. The Burlap home page contains the latest information about Burlap. The name "Burlap" was chosed for a simple reason: it's boring. 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 Burlap protocol has the following requirements:
The design notes explain some of the design decision in creating the Burlap protocol. The leading XML-based RPC protocols do not meet these requirements. UserLand's XML-RPC is insufficiently powerful to support Java serialization or EJB. Microsoft's SOAP is overly complicated and underdefined. In particular, it requires XML namespaces, attributes, overly complicated typing, and external schema. Burlap uses SML (Simple Markup Language), a restricted subset of XML:
The smallness of SML allows less room for bugs, simplifies testing, and makes reasonably-fast implementations feasible. It forces conformance by eliminating ambiguities. The SML grammar needs only six productions: Burlap's object serialization has 9 primitive types:
It has 2 combining constructs:
Finally, it has 2 special contructs:
Null represents a null pointer. The XML short form is forbidden, i.e. <null> must have separate open and close tags. <null> values are allowed in place of any <string>, <xml>, <base64>, <list>, <map>, or <remote>. A boolean value expressed as an integer, 0 or 1. A 32-bit signed integer. A 64-bit signed integer. A 64-bit IEEE floating pointer number. A 16-bit unicode character string encoded in UTF-8. The UTF-8 encoding follows from the SML rules. Similarly, the only escapes allowed are &#xx;, &lt;, &gt;, and &amp;. All whitespace is significant. An XML document encoded as a 16-bit unicode character string encoded in UTF-8, following the rules for <string>. Special characters, like `<' must be escaped. The only escapes allowed are &#xx;, &lt;, &gt;, and &amp;. All whitespace is significant. An ISO8609-encoded date. A base64-encoded binary stream. The base64 string may have whitespace after any triplet, but not within a triplet. An ordered list, like an array. The <type> element describes the type of the list and the <length> element specifies the number of values in the list. Both <type> and <length> tags are required, but both may be empty. If the <length> is empty, the receiver will determine the list length from the actual number of elements before the </list>. Each <list> item is added to the reference list. See the <ref> element. A <list> might also be represented by a <null> or <ref>. Parsers must be prepared to recognize any of those three. Represents serialized objects and Hashtables. The <type> element describes the type of the map. Objects are represented by a map from field names to their values and <type> is the class of the object itself. The <type> element is mandatory, although its value may be empty. For objects, unrecognized keys must be ignored. Each <map> is added to the reference list. A <map> might also be represented as <null> or <ref>. An integer referring to a previous <list> or <map> instance. As each <list> or <map> is read from the input stream, it is assigned an integer. A later <ref> can then use the previous object. <ref> 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 <map> and <list> to an array as its read. The <ref> will return the corresponding object from the array. To support circular structures, the implementation would store the <map> or <list> 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'. A reference to a remote object. The <type> element specifies the object type and the <string> element specifies the remote object's URL. Remote support is optional. Clients and servers don't need to support <remote> if the service doesn't need it. A Burlap call invokes a method on an object with an argument list. The object is uniquely named by its URL. The arguments are specified by Burlap serialization. The URL uniquely identifies the Burlap object. This spec does not mandate any particular URL naming convention. As an example, the following format is used for EJB: http://hostname/ejb identifies the EJB container. In Resin-EJB, this will refer to the EJB Servlet. HTTP is used as an example; Burlap does not require the use of HTTP. /ejb-name, the path info of the request, identifies the EJB home. EJB containers can contain several entity and session beans, each with its own EJB home. The ejb-name corresponds to the ejb-name in the deployment descriptor. object-id 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. Method names must be unique. 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 _burlap_ are reserved. Servers should accept calls with either the mangled method name or the unmangled method name. Clients should send the mangled method name. Arguments immediately follow the method in positional order. Argument values use Burlap'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. The number and type of arguments are fixed by the remote method. Variable length arguments are forbidden. In other words, implementations may take advantage of the expected type to improve performance. Headers are key, value pairs introduced by a <header> tag. The value of the header can be any serialized object. The reference array is reset for each header. So a header can't point to an object in another header. For example, a request might include a transaction context in a header. The client could require that the server understand the transaction context or fail. Burlap requests and responses have no explicit version id. This is deliberate. There are several different changes that get lumped into a 'version', but each needs different handling. In each case, appropriate mechanisms already exist without adding a version.
Burlap calls return either a <fault> or an object. A successful reply returns a single <value> and possibly some header information. Failed calls return a <fault>. Each fault has a number of informative fields, expressed like <map> entries. The defined fields are code, message, and detail. code is one of a short list of strings defined below. message is a user-readable message. detail is an object representing the exception. In Java, detail will be a serialized exception. ProtocolException | The Burlap request has some sort of
syntactic error.
| NoSuchObjectException | The requested object does not exist.
| NoSuchMethodException | The requested method does not exist.
| ServiceException | The called method threw an exception.
| Metadata is handled by special method calls, methods beginning with _burlap_. _burlap_getAttribute(String key) returns a string. The following attributes are predefined by this spec: attribute | meaning
| home-class | Java class for the home interface.
| remote-class | Java class for the object interface.
| primary-key-class | Java class for the primary key.
| A "Micro Burlap" implementation may omit support for the "double" type. © Copyright 2000-2002 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.
Copyright (c) 1998-2009 Caucho Technology, Inc. All rights reserved. caucho® , resin® and quercus® are registered trademarks of Caucho Technology, Inc. |
- HOME |
- CONTACT US |
- DOCUMENTATION |
- SALES |
- WIKI
caucho® , resin® and quercus® are registered trademarks of Caucho Technology, Inc.