Hello Asankha, > > 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. > Yes, the solution to de-serialize into XML as an intermediate > representation is powerful and useful - but comes at a cost That's why I think it depends on the use case one would like to solve whether this overhead is feasible or not. The most flexible way would be if the user could specify whether the full message should be normalized or not.
> > So maybe your suggestion might be optimized depending on the actual CBR > > requirements. > Sure, if you only want to route on the "To" address (Hessian does not > seem to use any specific transport headers like SOAPAction etc), What do you mean by the "To" address? Just the URL? I'm thinking of the usage of a Hessian Envelope with any custom header information. The spec states the following: "Envelopes may have headers that specify routing or other special processing information." [...] " The envelope syntax enables compression, encryption, signatures, and any routing or context headers to wrap a Hessian message." So my thought was to use custom headers within the Hessian Envelope and "expose" only this information to the ESB. What do you think? > de-serialization. Only limitation is that you cannot read/use or modify > the actual data in the method call The actual data in the method call (method name, arg names and values) are not important for the use cases I have in mind. We only need to specify and access some custom header information and use these as a source for CBR and logging. We have always the same set of additional (header) information we would like pass with each request (no matter if SOAP or Hessian) to the ESB and use this as a source for CBR and logging. As a service clients use a central implementation to abstract from the concrete implementation all this should be transparent to the client implementation. Does this make sense to you or do you have any other ideas to solve our requirements? Regards, Eric _______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
