XML database futures

As SQL and XML capabilities converge in the leading relational engines, you might conclude that there's no future for dedicated XML databases. A year ago, in his keynote at the InfoWorld CTO Forum, BEA Chief Architect Adam Bosworth explained why they're still relevant, and what their new mission will be. Coarse-grained XML messages are the wefts of the service-oriented fabric we're now weaving. We're going to be pumping a lot of those messages, and the pumps won't merely route messages. They'll also scan SOAP headers, correlate messages, enforce security policies, and respond to XPath-style queries -- all this in a real-time environment that can't tolerate the slightest delay.

Oracle Database, IBM DB2, Sybase ASE, and Microsoft SQL Server were built from the ground up to satisfy a different set of requirements: read-write multiuser access to transactional data stores governed by well-defined schemas. Message brokers, by contrast, live in a world of transient messages that aren't written by multiple concurrent users, aren't for the most part subject to the ACID (atomic, consistent, durable, isolated) transaction model, and aren't always fully schematized. Sure, you could use an XML-savvy relational engine to power an XML message pump. But that would be like driving a Hummer to work: a big, heavy, expensive vehicle that was made for a different purpose.

If you've already bought your SQL/XML Hummer, though, it's reasonable to want to make the most of that investment. Do you really need to buy an XML sports car, too, and become acquainted with a whole new set of quirks and foibles? The answer most likely is no. What you probably will buy, at some point, is an enterprise service bus(such as Sonic ESB) or a services fabric (such as webMethods Fabric). It will embed an XML database that may once have been a stand-alone product. For example, Sonic XML Server -- once known as eXcelon -- is vanishing into the woodwork of Sonic ESB.

Will Software AG's Tamino wind up similarly embedded? Bill Ruh, the company's CTO, isn't making any such announcement, but he doesn't discount the possibility either. “We're well suited to create an XML-based enterprise service bus,” he says. “Our mediator can set rules around XML data, do message fan-in and fan-out, call other apps, wait, and make decisions based on the values returned.”

It's true that you can use native XML databases to manage the growing number of business documents created by the new generation of XML-savvy end-user applications. It's handy, for example, to search an insurance database for incident reports that match some structured pattern of in-line metadata. But hybrid SQL/XML databases can do that too, and they can also join the structured XML content with relational columns -- a powerful combination. So XML databases are migrating into a niche that SQL/XML can't and won't occupy. They're becoming the high-performance pumps that push XML traffic around on the emerging services web.