UrlBlogGrey

One of my current tasks at work is to develop a mechanism for supporting our legacy transfer record (TR) formats while developing new XML-RPC web services. This is a bit of a challenge since the TR formats are composed of fixed-width strings (read: not XML). So, how can you map between non-XML and XML documents?

I stumbled upon an interesting project in the Jakarta Commons site called "Betwixt". Betwixt is designed to serialize and de-serialize JavaBean compliant objects to-and-from XML documents. This is all possible thanks to the magic that is "reflection". And because it's relying on reflection, Betwixt does not need to have any hints as to the structure of the JavaBeans.

So, I came up with the idea of using our existing TR parser/generator classes to represent the TR strings as JavaBeans, serialize their contents to XML, apply an XSLT template to transform the document structure into something compatible with the XML-RPC web service stubs, and then de-serialize the XSLT output into the stubs. The reverse applies, too. This sounds like a lot of work, but really it's not. I only need to write an XSLT to translate between the TR and XML-RPC stub structures. Betwixt handles the serialization and de-serialization operations on the JavaBeans in just a few lines of code. The alternative would be to have a Java class manually map between the two structures, which is error-prone and difficult to maintain.

I think that there is going to be a huge demand for these kinds of translation services in the future. In our case, we want to support a new XML-RPC interface while having the ability to route all legacy clients to the new interface without any TR interface changes. This is the beauty of code-by-interface programming.