Search our
entire site
Enter your search
terms below, or visit
our search page

Search case
studies only
Enter your search
terms below:

For the table
of contents and
hyperlinks to
general topics
proceed to toc

XML poses data-architecture debate

JANUARY 1999

Experts disagree: Is XML a database feature, or the next middleware?

As the Extensible Markup Language (XML) gains momentum on the Web, the debate is no longer whether it should be implemented. The question now is where the XML data should be stored when it is implemented.

With the November 1998 announcement of its XML-based Excelon data server, Object Design outlined a new XML infrastructure that allows XML data to be stored in a middleware cache where, according to Object Design officials, it can be manipulated more fully than in a relational database.

The product, which benefits from Object Design's underlying object database, enables developers to retain their legacy data and back-end systems, but transforms and stores the information as XML in a middle tier.

"The legacy data is staying the same, but once it's changed, you should manage it as XML," said Coco Jaenicke, product marketing manager at Object Design. "I believe if you want to fully leverage XML, it needs to be leveraged by an XML data management system."

The extensibility, flexibility, and portability of XML are lost in a relational database, Jaenicke said, leaving developers with something that "looks like XML, smells like XML, but doesn't walk like XML."

In fact, XML may be giving new life to object databases. Computer Associates, Versant, and Ardent all are planning XML extensions to their object database products.

"They are very much clinging to their relational model, and what they're doing is putting a wrapper on top of a Band-Aid on top of a wrapper," Jaenicke said. "They're warping it into a tree, but at the heart of it all, you've got a relational database underneath."

XML everywhere

But not everyone subscribes to this view. Relational database vendors, such as Oracle, say XML's greatest value will come when developers use it to make their current databases and data warehouses work harder for them on the Web. Even other object database vendors, such as Userland Software, aren't on the same page with Object Design.

"Anyone who says XML `belongs' anywhere in particular doesn't understand what XML is about," said Dave Winer, president of Userland Software, in Burlingame, Calif. "XML should be everywhere! Every database should be able to import and export XML-formatted text. So should every programming and scripting language. That's the purpose of XML; to break down the barriers and to allow all kinds of data to be interchanged with all kinds of software."

Tim Bray, the co-author of the XML specification, said a decade of experience with XML's precursor, the Standard Generalized Markup Language, or SGML, has shown that structured documents are not easily stored or managed in relational databases.

"You can do it, but it requires a whole lot of ad-hockery and kludgeware," Bray said. "In the world of XML, sometimes this won't be a problem, because a certain proportion of XML is going to be used to interchange meta data, purchase orders, and remote procedure calls, which are naturally tabular and will work just fine. But there will be another proportion [of XML documents] that does have document-style structures and causes such problems. How big are the relative proportions going to be? Nobody knows."

If people do rule out relational databases to store XML documents, Bray said there are still questions as to whether object databases are the way to go.

"A cynic would argue that the object database guys, having resoundingly failed to come up with a workable business model, are thrashing about looking for a problem for their solution," Bray said. "I think the jury's out, myself. It is clear that you can build nice XML-repository solutions on object databases, but it's not clear whether they can be made scalable or industrial-strength."

No life of its own

How to use XML also depends on the type of application being developed. For example, WebMethods uses XML to enable companies to deliver enterprise resource planning (ERP) system information to their suppliers and partners. In that case, there is no need to worry about how to store the XML data, according to Phillip Merrick, chief executive of WebMethods, in Fairfax, Va.

"The XML document is a very transitory thing and only exists for the amount of time it takes to get around the network," Merrick said. "There are certain specific applications where you're going to just generate the XML on one side and consume it on the other. XML isn't going to have a life of its own."

Merrick sees Object Design's architecture as most beneficial to people looking to pull information from various databases into one centralized XML cache store.

According to Steve Muench, an XML evangelist at Oracle, in Redwood Shores, Calif., the only situation in which storing XML in the middle tier (as opposed to a database) makes sense is when the middle tier includes a Web proxy server.

"If a million people a day are requesting the same static XML file, then a proxy server can be used to take [an] unnecessary load off of the original provider of the data/XML," Muench said.

Muench also said that enterprise customers are likely to approach XML from two perspectives: as a way to add meaningful meta information to business documents; and as a technology to make it easier to acquire, integrate, and exchange the growing amount of data they keep about their customers.

"This is data they already have in their enterprise relational databases and this is data which customers have no intention of representing natively as a set of XML documents on the file system," Muench said. "In this scenario, XML is served and processed dynamically in the same engine where the data lives, allowing everything to scale."

Bray said he isn't sold on relational databases, but did say that Oracle has taken a step in the right direction with Oracle8i, which he described as "an existing relational database product with an XML bag on the side."

"We'll have to see how far this road leads," Bray said. "I'm dubious, but then brute force and big bucks can work wonders."

Bray also said vendors of hierarchical storage systems that pre-date relational systems might be a good way to contain large quantities of XML documents.

Many paths

Jeremy Allaire, vice president of technology strategy at Allaire Corp., in Cambridge, Mass., said XML is being used to solve many different problems, which leads people mistakenly to look for one standard solution.

"It does not seem that these issues will get quickly resolved, or that there is any one answer. It really depends on your vantage point, and on how you are using XML," Allaire said.

In fact, the seemingly disparate XML-as-middleware and relational database approaches may be converging, according to Allaire.

"One caveat is that an outgrowth of the XML middleware approach is a generalized model for serializing and storing object data," Allaire added. "It would seem to me that at some point the kinds of functionality seen in object databases would merge with the formats and mechanisms of XML middleware."

Rita Knox, vice president and research director at the Gartner Group, in Stamford, Conn., agreed. The issue comes down to the type of application the developer is creating, she said, but noted that "there is no single answer that is going to be right for all applications."

TABLE OF CONTENTS