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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
