Eric
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
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.
Sure, if you only want to route on the "To" address (Hessian does not
seem to use any specific transport headers like SOAPAction etc), we can
easily create a binary payload with the actual hessian message and route
it. This will be fast, as no one will try to decode, read or transform
the actual payload. If this is fine with you, this is simple to
implement. This also does not require any classes/JARs to be available
on the ESB - nor cause any additional overhead for serealization or
de-serialization. Only limitation is that you cannot read/use or modify
the actual data in the method call
And if you really want to now look into the message and do the other
stuff, you can easily write a mediator to convert the message into
expanded XML - use any other mediator - and convert it back into binary
and send it off :)
Is this acceptable? Please evaluate against your actual requirements and
use cases
asankha
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
