Hi Asankha, > 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? No, I think you are right and I share your thoughts.
> 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</...> > [...] > The drawback is > that this requires a Hessian serialization into XML - which may beat the > original point of using Hessian in the first place. Yeah, and that's the problem. Although the solution you described seems very flexible it involves the overhead of reading the whole message and de-serializing it. >From my point of view the implementation depends on the focus and feature-set of the targeted CBR-solution. If one would be able to use any part of the message as a source of a CBR definition, there might be no other way as described above. But what if one is only interested in header information in the Hessian envelope in order to decide to which endpoint to route? No need to de-serialize the whole message as the content of the message body is of no interest for this use case. So maybe your suggestion might be optimized depending on the actual CBR requirements. What do others think? Regards, Eric _______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
