So far I have been using either handmade or generated (e.g. JAXB) Java objects as 'carriers' for messages in message processing software such as protocol converters. This often leads to tedious programming, such as copying/converting data from one system's message object to an instance of another's system message object. And it sure brings in lots of Java code with getters and setters for each message attribute, validation code, etc.
I was wondering whether it would be a good idea to convert one system's XML message into another system's format – or even convert requests into responses from the same system – using XSLT. This would mean I would no longer have to unmarshall XML streams to Java objects, copy/convert data using Java and marshall the resulting message object to another XML stream.
Since each message may actually have a purpose I would 'link' the message (and the payload it contains in its properties or XML elements/attributes) to EXSLT functions. This would change my design approach from an imperative to a declarative style.
Has anyone done this before and, if so, what are your experiences? Does the reduced amount of Java 'boiler plate' code weigh up to the increased complexity of (E)XSLT?
Best Answer
using XSLT to transform messages is a very common technique that you'll find supported in most ESB frameworks such as Apache Camel, Mule, Spring Integration, Ikasan etc.
The trade off is that XSLT can be difficult to maintain and there can be a lack of flexibility in the programming model that it offers. I've found that I'd often have to call out to a datasource to do a lookup or a POJO to perform some other complex transform. In the end up we only used XSLT for fairly simple transforms and had other components in the ESB flow do the rest.
There is also a performance cost in terms of performing the transform and the validation afterwards. There's a large array of libraries to choose from which perform the transform and validation with varying performance characteristics (think memory and CPU impacts).
There's another serialisation cost when you eventually transform back to a Java object.