Hi all,
> cracking open the Hessian body. However, I would like to add transform
> to/from SOAP.
Paul, I can also think of use cases, where this might be useful. When
introducing such a new feature, it should not have a negative
performance impact to the current implementation, where no
serialization/deserialization takes place. So Synapse should only
perform those steps, if it is really required.
I would also like to add, that this feature might not be trivial to
implement. There are different versions of the Java Hessian
implementation out there. Each version has it's own bugs and
limitations. There are also two protocol versions you would need to
support. If I'm not wrong you would not be able to implement this
without adding a dependency to a concrete version of the Hessian Java
implementation which might not be 100 compatible with client and or
service side versions of the Hessian Java library. Furthermore the
Hessian Protocol has AFAIK some limitations regarding the
serialization/deserialization of some Java type. E.g. type which have no
default constructor and ony one constructor which does not allow null
values. In this case one needs to register special
serializer/deserializer factories. This has to be done on the client and
the server (in this case also on the ESB).
The other opportunity would be to write your own implementation of the
Hessian protocol 1 and 2, but I'm not sure whether this is something you
really want.
Please don't get me wrong, I really like the idea, but just want to
express, that this could get harder to implement, than you might expect.
> If that is a useful feature, please can you raise a JIRA
> requesting it. Also please let us know what other features you might
> look for in Synapse Hessian support.
Regarding the existing Hessian support I'm thinking of a useful feature
which should be rather trivial to implement: The detection of hessian
service faults. Right now no mediator can easily detect, whether a
hessian message represents a service fault like it is possible for SOAP
responses. In order to detect this, it is not necessary to deserialize
the hessian message. The HessianMessageBuilder has access to the input
stream from the SynapseBinaryDataSource and could possibly read the
first few bytes without much performance impact.
A hessian reply has the following general structure:
valid-reply ::= r x01 x00 header* object z
fault-reply ::= r x01 x00 header* fault z
AFAIK, headers are rarely used. So either one would need to read until
the start marker of a serialized object or until a fault marker.
A hessian fault which throws for example a FileNotFoundException looks
like this (first Hessian 1.0, then Hessian 2.0)
r x01 x00
f
S x00 x04 code
S x00 x10 ServiceException
S x00 x07 message
S x00 x0e File Not Found
S x00 x06 detail
M t x00 x1d java.io.FileNotFoundException
z
z
r x02 x00
f
x04 code
x10 ServiceException
x07 message
x0e File Not Found
x06 detail
M t x00 x1d java.io.FileNotFoundException
z
z
Meaning:
r --> reply marker
x01 x00 --> major minor protocol version (1.0); x02 x00 (2.0)
f --> service fault
Hessian defines the following error codes:
ProtocolException: The Hessian request has some sort of syntactic error.
NoSuchObjectException: The requested object does not exist.
NoSuchMethodException: The requested method does not exist.
RequireHeaderException: A required header was not understood by the
server.
ServiceException: The called method threw an exception.
Further details can be found at:
http://hessian.caucho.com/doc/hessian-1.0-spec.xtp
http://hessian.caucho.com/doc/hessian-ws.html
It should also be easy to read the error code as well as the message.
This fault info could then be wrapped in an OMElement which can be
easily used in a similar way then for SOAP messages.
This would of course add some value if someone wants to monitor or
statistically evaluate his service responses.
What do you think? Does this seem feasible and straight forward to
implement?
Regards,
Eric
