2

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?

Improve this question

    2 Answers 2

    Reset to default
    5

    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.

    Improve this answer
      4

      XSLT can get really complicated really fast

      Having spent a lot of time enduring the pain of poorly applied XSLT solutions I'd strongly counsel against them, unless your mapping transformations are brain-dead simple.

      I would much rather try to work through a load of fairly simple, repetitive POJOs trying to find a transformation bug than fiddle endlessly with esoteric XSLT constructs.

      Interesting side notes

      Off topic, but might be worth mentioning, is that you can add custom code easily enough to your auto-generated JAXB classes using the techniques described in this article. Also, this article about Hypertext Application Language (HAL) contains some interesting bridging techniques using SAM Types, contracts and all driven through Guava Functions. Might make a dull job a lot more interesting.

      Improve this answer
      2
      • I agree that fully comprehending XSLT's syntax and semantics can be a challenge. On the other hand, I am willing to invest time on a learning curve if this saves me from creating message wrapping POJO's in Java and carrying their contents from one message object to the other. And I disagree (at least a bit) on the simplicity of POJO's because serializing and unserializing XML to objects and values can be very challenging. XSLT can combine both the parsing and the generation of XML messages in an all-XML context.
        – user57328
        CommentedJun 21, 2012 at 21:15
      • No problem with you taking the time to learn it, and your all-XML context is a valid point. However, consider the people who will have to maintain your code once you've moved on to other projects. Make sure that you are very detailed in your explanations of how the XSLT works if you stray off the obvious path. I frequently encountered code that was poorly documented, relied on strange processing techniques and the original creator was not available. That made those experiences rather unpleasant.
        – Gary
        CommentedJun 25, 2012 at 9:51