Hi all
Recently, we have started looking at how best we should support Hessian
- the binary web service protocol from Caucho
(http://hessian.caucho.com/). Here are some of my notes and observations
to get started on this..
The "HessianServlet" basically creates a HessianInputStream out of a
POST request sent over HTTP like shown below, where the "x"s refer binary:
xxgetPersonxxxorg.wso2.hessian.server.CustomerxxxxnamexxasankhaxxagexxxxaddressxxMount
LaviniaxxxjoinDatexxxxxx
This is if I call a method "public Person getPerson(Customer c)", where
Customer has attributes String name, int age, String address, Date joinDate
The HessianServlet basically finds out the name of the method (i.e.
getPerson) and using reflection, loads the class Customer, and reads the
parameters from the HessianInputStream as Objects and sets them to the
Customer instance. Then it invokes the method passing the parameters and
gets the return Object and does the reverse.
Now if we think about a typical proxy scenario with CBR as an example,
the ESB will not have any of the classes that are being serialized and
passed around by Hessian. Without these classes, we will not be able to
create the HessianInputStream. I do not think its practical to get all
JARs that define all classes and then place them in the ESB lib.. am I
wrong?
If we don't do the above, we could probably still use the Hessian
grammar (http://wiki.caucho.com/Hessian_2.0_Grammar) to read the above
serialization into some internal format.. such as the following XML :
<hessian>
<method>getPerson</..>
<parameters>
<parameter>
<type>org.wso2.hessian.server.Customer</...>
<String name="name">asankha</..>
<int name="age">32</...>
We should be able to do CBR, and even XSLT etc with this format. Thus
without requiring the ESB to have any JAR files on it at runtime, we can
mediate Hessian messages as normal messages. We can even introduce a new
parameter to a method call, or remove an existing parameter or edit the
value etc. with simple XSLT/XQ/Scripts etc, and Log the requests and
everything else.. and then serialize this back into a Hessian message
without creating an instance of the underlying class. The drawback is
that this requires a Hessian serialization into XML - which may beat the
original point of using Hessian in the first place.
However, personally I would think that to do CBR at the ESB layer, one
would definitely have to read the message causing an intermediate
de-serialization of all requests anyway.. and thus I think using an
internal representation will not be bad
Your thoughts and comments are appreciated
asankha
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
