burlap-notes.xtp

RESIN 3.2 最新源码

<p>XML has two main use patterns: a static syntax described by a DTD (document
type descriptor), and an extensible syntax using XML namespaces and
presumably defined by an XML schema.  XML-RPC choose the DTD
and SOAP choose XML schema.  Burlap choose the DTD.

</p><p>A major advantage of the DTD choice is that any Burlap request or
response is verifiable without any external schema.  The DTD defines
the entire grammar for Burlap.  So a tester can use that grammar to validate
that a Burlap client or server is conformant.  The grammar serves as
a testplan.

</p><p>The schema route gives more flexibility without adding expressive power.
The same object might have two different serializations if the
XML schema differs.  With Burlap or XML-RPC, the class has a
unique serialization.  With SOAP the different representations leave open
the possibility of interoperability issues.

</p></s2>

<s2 title="Object Identifiers (URL)">

<p>Burlap uses a URL to locate the server object.  Usually, this will
be an HTTP url, but nothing in the Burlap protocol requires the
use of HTTP.  Since URLs are sufficient and already familiar, it seems
obvious to use them.

</p><p>An advantage of the particular encoding used for
EJB is that intelligent load balancers can use it to direct the
request to an owning server.  It's not required that the URL for
Burlap servers follow the same conventions as the EJB encoding.  In
the EJB encoding, the bean home interface is also a URL, easily
determined by removing the object identifier as the last name.  This
makes getting meta information easier.

</p><p>XML-RPC, in contrast, uses a combination of an HTTP URL and an
object identifier embedded in the request.  The object identifier is
part of the &lt;methodName&gt; item.</p>

<example title="http://host/RPC2">
&lt;?xml version="1.0"?&gt;
&lt;methodCall&gt;
  &lt;methodName&gt;examples.getStateName&lt;/methodName&gt;
  &lt;params&gt;
    &lt;param&gt;
      &lt;value&gt;&lt;i4&gt;41&lt;/i4&gt;&lt;/value&gt;
    &lt;/param&gt;
  &lt;/params&gt;
&lt;/methodCall&gt;
</example>

<p>SOAP also uses the URL to identify the target object.  The primary
model for SOAP appears to be more service-based rather than
object-based.  In other words, it appears that most SOAP servers will
only have a single URL and not have separate URLs for object
instances.  In constrast, Burlap heavily uses sub-URLs (path-info) to
identify object instances.  Nothing in the SOAP protocol precludes
using sub-URLs, so this isn't a limitation of the SOAP spec.  It just
appears to be counter to the culture of SOAP to use lots of URLs.  As
the SOAP spec says, objects-by-reference are not part of
the SOAP specification.

</p></s2>

<s2 title="Method Selection and Overloading">

<p>Since EJB requires method overloading, Burlap supports it.  Burlap
implements method overloading with "method name mangling".  The type
of the method arguments becomes part of the method name.  To support
simpler clients, like script-based clients, one of the methods will
also typically respond to an unadorned method.</p>

<example title="add(2,3) call">
&lt;burlap:call&gt;
  &lt;method&gt;add_int_int&lt;/method&gt;
  &lt;int&gt;2&lt;/int&gt;
  &lt;int&gt;3&lt;/int&gt;
&lt;/burlap:call&gt;
</example>

<p>Because Burlap's encoding is lossy, some overloaded methods are
indistinguishable.  For example <var>add(int)</var> and <var>add(short)</var>
are both encoded as integer argument.  So only the integer version
will be callable.   The main reason for the lossy limitation is to
make Burlap less Java-dependent.  <var>int</var>, <var>long</var>, and
<var>double</var> are supported by most languages.  We expect this won't
be a large limitation.  Few objects have methods with aliased methods.

</p><p>XML-RPC doesn't specifically address this issue.  Since its
method selection is very similar to Burlap's, name mangling would
be easy to implement in XML-RPC.

</p><p>SOAP's method selection is very different.  Each method has its
own XML element and namespace, presumably defined in some external
schema.  It could also support overloading with mangled element
names.  SOAP adds additional complexity to the method call with the
addition of a namespace.  It's not clear what value this adds, other
than additional complications, more tests, and interoperability
issues.

</p><p>Since a service/remote-object has a single set of methods,
selecting the object implicitly selects the method set or object
signature.  In theory, namespaces would allow a client to choose a
different object signature, but it's not clear what application would
need that.  Java and EJB doesn't need that complexity.</p>

<example title="SOAP add(2,3) call">
...
&lt;m:add xmlns:m="http://www.caucho.com/soap/calculator"&gt;
  &lt;a&gt;2&lt;/a&gt;
  &lt;b&gt;3&lt;/b&gt;
&lt;/m:add&gt;
...
</example>

</s2>

<s2 title="Method Parameters">

<p>Burlap method parameters are order-based like Java and essentially
every major programming language.  The number of parameters is fixed
for each method.  Varying-length parameters and extra parameters are
forbidden.  It's easily tested, unambiguous, and it's easy to write a fast
parsers.  The choice seems obvious and hardly worth discussion, but
SOAP dismissed position-based arguments.

</p><p>SOAP's method arguments are named by scheme-defined elements and
can appear in any order:</p>

<example>
...
&lt;m:myMethodCall xmlns:m="my-namespace"&gt;
  &lt;z&gt;13&lt;/z&gt;
  &lt;a&gt;4&lt;/a&gt;
  &lt;m&gt;13&lt;/m&gt;
&lt;/m:myMethodCall&gt;
</example>

<p>For an EJB-implementation, the SOAP method arguments creates
several problems.  What name should the first argument be given?  Does
a client need an external schema or IDL to map the SOAP argument to
the function call?  How intelligent does a client or server have to be
to handle all the possible argument name assignments?  And how can all
this be tested?  The SOAP designers must have had some reason for this
choice, but it directly opposes the needs of an EJB server and client.

</p></s2>

<s2 title="Inheritance (&lt;type&gt;)">

<p>Although most of Burlap's design avoids Java-specific requirements,
solving the inheritance problem requires the deserializer know what
Java class to create.  Burlap's solution makes Java implementations
easy, but doesn't significantly impede other languages and is
no less language-independent than SOAP or XML-RPC.

</p><p>Since Java is an object-oriented language, the type of a value may not
equal the declared type.  For example, an Object field might contain a
Car object or a Truck object.  To serialize the Car or Truck, Burlap
needs to add the object type in the protocol.  XML-RPC, in contrast,
has no accompanying type information, so a Java XML-RPC implementation
can't to create a Car from information in the protocol.  The Java serializer
also need to know if an array will be a Java array, Vector, or
ArrayList.  That's done with the &lt;type&gt; tag in &lt;list&gt; and &lt;map&gt;.</p>

<example>
&lt;map&gt;
&lt;type&gt;com.caucho.example.Car&lt;/type&gt;
&lt;string&gt;color&lt;/string&gt;&lt;string&gt;red&lt;/string&gt;
&lt;/map&gt;
</example>

<p>This is a thorny problem.  The serializer must know the Java type,
but we'd prefer to keep Java-specific information out of the
protocol.  Burlap's solution allows non-Java clients with a
little extra work, and makes Java implementations easy.

</p><p>The heart of the problem how to map a type key in the
protocol to a language-specific type.  That map might appear in a
repository, in some external schema like IDL, or it can be encoded
in the protocol itself for a specific language.  Some simple clients
may not need this mapping.  A simple client in Perl, JavaScript or
Java client might use generic types, like ArrayList and Hashtables to
read the serialized values.  When they write request to a Java server,
they'll need to add the type, but protocol writing is much easier than
protocol parsing.

</p><p>It's not clear whether SOAP uses an external schema or a
repository service (<a href="http://www.w3.org/TR/wsdl">WSDL</a>) to
map to language types, but it's clear something external is required.
The following is a typical SOAP serialization of the Car:</p>

<example title="Car in SOAP">
&lt;e:Car xmlns:e="http://www.caucho.com/soap/cars.xml"&gt;
&lt;color&gt;red&lt;/color&gt;
&lt;/e:Car&gt;
</example>

<p>How do you map from "e:Car" with namespace
"http://www.caucho.com/soap/cars" to the Java class
com.caucho.example.Car?  Since that's not part of the SOAP spec, there
must be an additional spec defining that mapping.  Since our
requirements required a testable implementation (repository is extra
work), no external IDL (so schema is out), the technique used by SOAP
was not appropriate for Burlap.

</p><p>Burlap doesn't preclude clients in other languages from using
their own types.  It would just require the addition of a repository
service or an external IDL.  In other words, it's no more complicated
than the type lookup SOAP requires for every language.  So Burlap
makes Java implementation easy, but doesn't make other languages hard.
When a Python client first encountered a "com.caucho.example.Car", it could
either use "Car" as a Python type, or query some yet-to-be-defined
service mapping to Python.  In other words, it's a trade-off, but it's
unavoidable and we believe the solution is fair to other languages.

</p></s2>

<s2 title="Shared References (&lt;ref&gt;)">

<p>Shared references are an integral vital for serializing any
significant data structure.  Serializing a tree, for example, needs to
link a node's children and the parent in a circular set of
references.  Shared references are one of the necessary capabilities
missing from XML-RPC that Burlap adds.

</p><p>Burlap implements shared references with an implicit array of all
&lt;list&gt; and &lt;map&gt; objects.  Linking to an old object can then
just refer to the object's position in the array.  An advantage of
Burlap's approach is that it only requires a single pass through the
object.</p>

<example title="Burlap References">
&lt;map&gt;
  &lt;type&gt;com.muggle.Car&lt;/type&gt;

  &lt;string&gt;model&lt;/string&gt;
  &lt;string&gt;Ford Anglia&lt;/string&gt;
&lt;/map&gt;
...
&lt;map&gt;
  &lt;type&gt;com.muggle.Person&lt;/type&gt;

  &lt;string&gt;name&lt;/string&gt;
  &lt;string&gt;Arthur Weasley&lt;/string&gt;

  &lt;string&gt;car&lt;/string&gt;
  &lt;ref&gt;1&lt;/ref&gt;
&lt;/e:Person&gt;
</example>

<p>SOAP takes a different approach for shared references.  Declaring an object
uses an <var>id</var> attribute and referring to the object uses a
<var>href</var> attribute:</p>

<example title="SOAP references">
&lt;e:Car id="1"&gt;
  &lt;e:Model&gt;Ford Anglia&lt;/e:Model&gt;
&lt;/e:Car&gt;
...
&lt;e:Person&gt;
  &lt;e:Name&gt;Arthur Weasley&lt;/e:Name&gt;
  &lt;e:Car href="1"/&gt;
&lt;/e:Person&gt;
</example>

<p>The SOAP approach has the advantage that the receiving server
doesn't need to keep track of every object it's received.  In
addition, it can refer to any object, including strings.  With Burlap,
only &lt;map&gt; and &lt;list&gt; can share references, strings and byte
array can't be shared.  As a disadvantage, SOAP requires two passes
over the object before sending it and SOAP's approach requires the
use of XML attributes.

</p></s2>

</s1>

<s1 title="Conclusion">

<p>The Burlap design aimed at reducing the testing and implementation
complexity, and should give decent performance.  Because Burlap is a
wire protocol, EJB users don't care about the protocol details and we
could tailor Burlap to the specific requirements needed to support
EJB.

</p><p>The small size of the Burlap specification should not be confused
with its expressive power.  Burlap is fully capable of handling
Java/EJB calls.  The added complexity and "flexibility" of a
spec like SOAP just introduces ambiguity and adds to the testing
requirements without adding expressive power.

</p></s1>
  </body>
</document>