OK, I will admit it: XML is data exchange nirvana. It's the data format swiss-army knife that we've always wanted and finally got: It lets us represent virtually any type of data in a simple, structured way that others can easily read and use. XML is simple, it is straighforward, and we really just have to learn three little things to use it: angle brackets, tags, and tag values.
And XML is everywhere these days. A quick survey of the systems in your organization will surely turn up the fact that XML is now present in just about everything, from Microsoft Office 2003 to Amazon's intriguing REST APIs.
However, there seems to be trouble in paradise. Since it's been invented, just about every conceivable attempt has been made to make XML "easier" for software developers to read, write, and manipulate. And if you took a survey of the ways to represent XML in forms other than itself, you would surely come away thinking that XML must be the most difficult data format in the world to use. In fact, since XML's emergence and ascendency, the number of attempts made at wrapping XML in an object model have been astonishing.
We've always had Plain Old XML (POX) of course, just XML in ASCII form, angle brackets and all. But then the first XML APIs arrived on the scene. Originally it was just SAX and DOM, but now there are XOM, Stax, and JDOM, to name just three of many, many others. All of these essentially purport to do wrap XML the "right" way. And more are on the way. Surely there is something important we don't know about XML.
Figure 1: POX (Plain Old XML) and the myriad methods for manipulating it
As important as wrapping, there are now also innumerable ways to convert information represented in your local programming language into XML, whether that is C#, Java, or whatever else you happen to use. For instance, the .NET Common Language Runtime can already convert any .NET datatype into SOAP, and there are a constellation of Java<->XML mappings. And that takes us close to the neverending debates about XML over the wire and SOAP vs. REST.
All of this attention around converting things to and from XML reveals a huge and ongoing fascination with the problem of keeping information in two different formats. One being XML, which just about anyone can consume, and the other being whatever format you actually do your work/store things in. Note that for some reason, these are hardly ever the same thing. And that's where we begin to understand all the hoopla around the ways for getting things into and out of XML.
The big, ugly secret of XML is this: Though simple to read and easy to look at, XML is very unpleasant to manipulate and process directly. A recent post by Quoderat says it best: [XML object models] always look easier with the simple examples used in introductions and tutorials, but as soon as you try to use them in a real-world application, their relatively minor advantages disappear in the noise of trying to deal with the complexity of XML structure.
So, as enterprise architects, what does this mean we should do? XML isnt' going away, nor should it. Having to deal with XML natively, which is absolutely critical when dealing with web services for example, isn't going away. But manipulating XML directly results in amazingly fragile, brittle, and smelly code that won't last beyond the next structural schema change.
The title of this post says it all: there is a huge challenge hidden in the fact that POX is the means around which all XML-based interoperability has been staked. But the ongoing flood of XML APIs show us that dealing with XML abstractions in our native representations is still a hugely unsolved problem. In fact, I have seen untold mountains of code that marshals XML back and forth between local languages and systems. Schema conversion, XSL-style, has become a huge help but it still doesn't directly address the impedance problems that programming languages themselves have with XML.
If you've read this far in hope of a solution, I'm sorry to deliver the news. The right answer to the dual representation problem (POX<->local representation) hasn't been found yet. Certainly many folks are looking at the problem and some are getting closer including the Hibernate XML mapping folks. And some are clearly struggling, such as Microsoft's X# effort.
There's no question, the POX plague is a significant morass in any enterprise architecture which has XML interoperability as a key feature. Those who work in service-oriented architectures will be happy to tell you the many pitfalls that await. The percentage of code that has to deal with XML conversion and change frequency in such architectures is alarming.
For now, the problem has to be scoped and monitored as a risk in any project that has significant POX in the seams of its architecture. And enterprise architects are duly warned to keep a watchful eye on things as XML continues to make inroads into our systems.
Technorati: Enterprise Architecture, Computers and Internet, Programming