📄 burlap-notes.xtp
字号:
<document> <header> <product>resin-ee</product> <title>Burlap Notes</title> <date>December 31, 2001</date> <description> <p>As described in the <a href="burlap-1.0-spec.xtp">Burlap 1.0 spec</a>, we created Burlap to implement Enterprise Java Beans (EJB) using an XML-based protocol with reasonable performance. Although many RPC protocols already exist, including several based on XML, none met our application's needs. The name "Burlap" was chosed for a simple reason: it's boring. Unlike the exciting protocols defining "Internet 3.0", SOAP and XML-RPC, Burlap is just boring text-based protocol to make testing and debugging EJB a little bit easier.</p> </description> </header> <body><s1> <p>Because we're an engineering-driven company and lack the resources to effectively lobby for Burlap as the standard internet services wire-protocol, we have the opportunity to write these design notes from an engineering perspective, devoid of marketing hype. Several of the examples use <a href="http://www.w3.org/TR/SOAP/">SOAP</a> and <a href="http://www.xmlrpc.com/spec">XML-RPC</a> to contrast Burlap's design decisions, but as those protocols have different goals, the contrasts should not be taken as criticisms of the protocols. Most of the design of Burlap, after all, is merely a modification of SOAP and XML-RPC for EJB's needs.</p></s1> <localtoc/><s1 title="Design Goals"><p>The Burlap protocol was created to solve a specific problem: toprovide remote procedure calls for Java Enterprise Java Beans (EJB)using an XML-based protocol without limiting theprotocol to Java servers and clients.</p><p>EJB is often used for distributed computing on a small scale. Onedevelopment team controls the design for both clients and servers.Most often, the application uses a single subnet for allcommunication. As long as the RPC protocol is fast and reliable, mostEJB developers don't care what protocol is used. "Small-scale" mightbe misleading: a site like eBay using EJB internally would be small-scaledistributed computing, but it needs large-scale performanceand reliability.</p><ul><li>It must have sufficient power to support EJB.</li><li>It must be simple so it can be effectively tested.</li><li>It must be as fast as possible.</li><li>It must only require Java introspection. It must not require externalIDL or schema definitions.</li><li>It must use a subset of XML.</li><li>It must allow EJB servers to deployed as a Servlet.</li><li>It should support transaction contexts.</li><li>It should allow non-Java clients to use EJB servers.</li></ul><s2 title="Sufficiency"><p>Fortunately, we know exactly how powerful Burlap needs to be: it needs toserialize and deserialize arbitrary Java objects. In contrast, SOAP andXML-RPC have the much tougher responsibility of an open-ended sufficiencyrequirement. Although Burlap may be sufficiently powerfulfor essentially any service, it's not a design goal.</p><p>Specific requirements:</p><ul><li>Serialize Java primitive types (boolean, int, long, double, String).</li><li>Support nulls.</li><li>Permit shared and circular data structures.</li><li>Support objects, arrays, lists, and maps.</li><li>Deserialize subclassed objects, including Object variables..</li><li>Support remote object references (EJBHome and EJBObject references.)</li></ul><p>Surprisingly, many of the existing protocols are insufficientlypowerful to handle these requirements. Even IIOP/CORBA needed protocoladditions to support full Java serialization.</p><p>XML-RPC is missing a number of the features needed to supportEJBs: 64-bit integer (Java long), nulls, shared data structures, subclassedobjects, and remote object references.</p><p>SOAP explicitly does not support remote object references because itwas perceived as too difficult. In other respects SOAP seems to besufficient. In fact, it defines a large number of types unusable forEJB, including everying in the<a href="http://www.w3.org/TR/xmlschema-2/">XML Schema</a>: sparse arrays,enumerations, integer subranges, durations.</p><p>Maps, including Java Hashtables and HashMaps, are not explicitlysupported by other protocols, even though they are very common inJava programming. All the protocols support special String to Objectmaps, i.e. structures, but none support Object to Object maps. Of course,it's always possible to serialize the Hashtable structure itself, as RMIdoes, but that exposes the implementation details of the hashtable. So aHashtable would look very different from a HashMap serialization, makingit difficult for different languages to interoperate.</p></s2><s2 title="Testability"><p>Testability is the key design goal of Burlap. At this early stageof development, we have 43k lines in the EJB test suite, but only 28klines of code in the EJB implementation. Granted, the EJBimplementation uses Resin libraries heavily which weren't includedin the count, but it should give an idea of the work involved in testing.</p><p>The Burlap spec is as small as possible to reduce thetest suite size. For example, eliminating XML attributes, namespaces, and<a href="http://www.w3.org/TR/2001/PR-xmlschema-1-20010316">XML Schema</a>radically reduces the test suite size and complexity without losing any power.The EJB spec only requires CORBA/IIOP as a wire protocol, butIIOP is a huge ungainly beast and is a binary protocol. BecauseIIOP is huge, testing it is a large task and leaves many places wherebugs can spawn. By using Burlap as the primary wire protocol, we canmake it more reliable because it's more testable, and when we do implementIIOP we can easily localize the bugs.</p><p>Since ambiguity and complexity make testing difficult, both havebeen eliminated where possible in Burlap. Even simple ambiguity can maketesting more difficult. For example, XML-RPC allows either <int>or <i4> to represent 32-bit integers. In theory, an implementationcould parse integers using different code for <int> and for <i4>,so <int> might be carefully tested and <i4> spot-checked, but the<i4> parse might be buggy. If a ServerA implementationgenerally uses <int>, a fully conforming ClientB might use <i4> andrun into a bug undetected for months. So ClientB needs to use<int> for ServerA. The XML-RPC case is trivial, but for more complicatedand verbose specs like IIOP/CORBA and SOAP, full testing may be impossible,forcing bake-off testing so the mutually-incompatible implementations canbe forced to work together.</p><p>Ambiguity is not an academic problem. Every HTTP serverimplementor needs to work around various non-conforming clients. Clients interpret the HTTP cookie spec in many strange annon-conformant ways. For example, one client needs spaces in a"; secure" attribute, but another client can't deal with the spaces.This is a real example. If browsers mess up the simple cookie spec, theSOAP, XML Schema, SOAP Attachment, WSDL, and more! specs, are likelyto cause interoperability and testing problems, like CORBA/IIOP did.Burlap tries to eliminate ambiguity so these problems never show upin the first place.</p><p>The primary motivation for using a text-based protocol, like XML, is theresulting simplicity of each test. The following isone of Caucho's tests for integer serialization.</p><example title="ejb/0004.qa"><title>burlap: server int</title><file file='file:/tmp/caucho/qa/WEB-INF/classes/test/MyBean.java'>package test;import com.caucho.burlap.*;public class MyBean extends BurlapServlet { public int add(int a, int b) { return a + b; }}</file><script out='stdout'>http = new caucho.server.http.TestHttp(File("file:/tmp/caucho/qa"));http.request(@<<END, out);POST /servlet/test.MyBean HTTP/1.0Content-Length: 120<burlap:call><method>add</method><int>32000</int><int>-1000</int></burlap:call>ENDhttp.close();</script><compare file='/stdout'>HTTP/1.0 200 OKServer: Resin/1.1Content-Length: 60Date: Fri, 08 May 1998 09:51:31 GMT<burlap:reply><value><int>31000</int></value></burlap:reply></compare></example><p>Testability is a true measure of the complexity of a spec. Writing asample server easy for any spec, but writing afully-conforming, tested servers that works with all the clients is amuch larger issue. Unfortunately, most spec writers are "white-paperengineers" who don't even implement their design, much less test it.Given the computer industry's reputation for buggy products, it justseems prudent to design the spec to minimize testing and bugs.</p></s2></s1><s1 title="Implementation Decisions"><s2 title="XML vs SML"><p>This decision is obvious. Burlap doesn't need the additionalcomplexity with XML or namespaces or schema, so there's noneed to add them. It would just explode the test-suite, complicate theparsers, and make conformance harder. And all that complexity giveszero added power.</p><p>The XML-specs give no added power because Burlap is an existenceproof for the sufficiency of SML. Here's a rough sketch of a formal proof:</p><ul><li>It encodes Java primitives: <boolean>, <int>, <long>, <double>,<string>, <null>, and is non-lossy for the additional <var>byte</var>,<var>short</var>, <var>char</var>, <var>float</var> primitives.</li><li>It encodes Java arrays (<list> with <type>[foo</type>)</li><li>It encodes Java classes (serialization with <map>)</li><li>It supports Java inheritance (<type> for <list> and<map>).</li><li>All Java objects are generated using a combination of the above.</li></ul><p>(The additional tags <date>, <base64>, <remote>,using <list> for List objects and <map> for Map objects arenot strictly necessary, but make the protocol Java-independent.)</p><p>Since SML is sufficient, any added XML "features" can add nothing tothe expressive power because there's nothing left to add. But addingXML attributes and namespaces and have a huge cost in conformance, testingand performance. It's a good idea to remember that Burlap will always bemachine-generated. Unlike HTML, no graphic designer willever write Burlap documents.</p><p>The trivial <null> tag has only one encoding in Burlap as follows.</p><example title="SML-mandated null"><null></null></example><p>Having only one option not only simplifies the tests andinteroperability, but it improves the parser performance. Thefollowing is explicitly forbidden in Burlap, though allowed in XML:</p><results title="XML null (forbidden in Burlap)"><null/></results><p>At first glance, the XML encoding appears more efficient, becauseit saves 5 characters. In reality, that savings of network bandwidthis in the noise performance-wise. When a typical page even overa 56k modem can be 100k with additional gifs, 5 charactersdoesn't matter. Burlap's use is for single subnets, usuallyrunning at 100Mb or possibly 1Gb. The miniscule savings aren't worththe complexity.</p><p>For Burlap's encoding it's easy to write an efficient parser, knowingwhat kind of results are expected:</p><example>switch (is.readToken()) {case NULL: is.readEndTag("null"); break;case STRING: String v = is.readString(); is.readEndTag("string"); break;...}</example><p>With the XML short-tag "feature", the code would need toreturn a different token for "null-with-trailing-slash", the testsuite would need to add cases and all servers and clients wouldneed to parse both (with possible buggy clients only understandingone form). This example is relatively simple; the addition ofattributes and namespaces would increase the complexity.</p></s2><s2 title="DTD vs XML Schema">⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -