3

For my last camel project I used xslt to transform incoming xml into an xml format suitable for sending to a third party web service. This works just fine. Is this still considered the best approach for xml-to-xml mapping or are there better and more performant tools that you guys would recommend?

Personally I don't mind xslt but feedback from other developers in my organisation is that they find it difficult to read and maintain, particularly when the conversion is fairly complex. They have a point.

One alternative I am considering is marshalling to java objects and converting before unmarshalling back to xml. This has the benefit of being easier to set up and maintain via converter objects. I am however concerned about the effect on performance the number of operations required to achieve this will have.

Interested in your thoughts.

Many thanks

Elwood
  • 4,451
  • 4
  • 18
  • 20

2 Answers2

2

While I agree with the developers that XSLT is a bit of a pain it is not such a bad pain. I suspect converting from XML to POJO doing a transform and then converting back to XML is going to be a performance killer. There is just so much operations to do that the O-notation of this approach is going to be killer.

DISCLAIMER: I dont work for Altova/Liquid Technologies.

A while ago I worked in a major bank where we used Altovas XML suite. They have a product called MapForce which simplifies development and maintenance of XSLT by light years. I was able to teach a person with NO development experience how to create XSLT that worked. It is a really good product but a bit pricey. Download the eval copy and give it a spin.

Liquid XML also has tools that will allow you to smooth out the rough edges around XSLT creation.

I would strongly recommend that you look at these tools as a option as they might just take the pain away.

Namphibian
  • 12,046
  • 7
  • 46
  • 76
  • Thanks, I have used Altova products in the past and like them a lot. I just need to convince my project this is the way to go. – Elwood Aug 02 '13 at 10:08
2

The main problem with XSLT is the learning curve. You've already mastered the language so that's not a problem for you, but it's a problem for your colleagues who still find the approach strange and unfamiliar. So there's a bit of a dilemma. It's perfectly respectable to use a sub-optimal technology for the job in the interests of reducing the total number of technologies that everyone in the organization has to learn. Having said that, however, XSLT 2.0 is certainly the best tool for the job, and if you're proficient in its use, then using anything else would be pretty painful.

Maintenance with XSLT can be a hassle: I've recently been debugging a transformation that uses a collection of about a dozen stylesheets that's grown like topsy over a period of 15 years, and it's a bit of a nightmare to follow the logic. There are debugging tools that can certainly help here, but there's no substitute for good software engineering discipline: comment the code, and refactor it regularly to keep the structure clean. Which depends in turn on having a good set of regression tests so you know your refactorings are correct.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164