XML servers enabling e-comm and Web models

In the past year, Extensible Markup Language (XML) has come a long way from being just an extension of HTML. XML is now vying with electronic data interchange for new business-to-business applications over intranets, extranets and the Internet.

XML specifies ways to represent data and makes data understandable to competing applications. For example, an Oracle database can understand a catalog, even if the catalog is held in Microsoft's SQL Server.

XML is also supported by Web browsers. A user can cull information from an Oracle database and view it in Netscape Navigator. Even better, with Navigator users can view the content from a product catalog.

XML leads to a lot of interesting business propositions. "We believe nearly everyone is jumping on the XML bandwagon - including nearly every application vendor that supports any publishing to the World Wide Web or supports APIs for transaction processing," says David Alschuler, an analyst at Aberdeen Group.

"Within three to five years, the majority of business-to-business commerce will be carried out in XML," predicts Philip Costa, an analyst at Giga Information Group.

"XML's gotten all this publicity on the client side, just like Java did, but it's on the server side that you need platform independence," says Coco Jaenicke, XML product marketing manager at Object Design, Inc. (ODI).

Three types of XML applications are:

Those that get or create XML, such as Bluestone Software's XML-Server, a dynamic server that translates other data into XML.

Those that view XML, such as Web publishing applications.

Those that manage XML, such as ODI's Excelon, which performs application processing for XML.

One way to understand the process is to look at a fictional net primed for XML. In this net, our Oracle database, IBM mainframes and server farm lie at the bottom layer. On top of that is Bluestone's XML-Server. On top of that is Excelon. Then come the clients, including 500 workstations and two Web servers.

We use Bluestone's Visual XML to create the elements needed to turn disparate data into XML objects. We create Data Type Definitions (DTD), which spell out what each object is called. If we're using XML only to turn database records into XML objects, each DTD is roughly the same as each record, and each set of XML tags is equivalent to the field name.

DTDs are stored in XML-Server. When each database record is passed to the XML server, XML-Server applies the DTDs. XML-Server then outputs fully formed XML objects and passes them along to Excelon.

If we're using XML-Server to create XML objects from applications, the process is different. We'll use Visual XML to turn the applications into Java doclets, which are Java programs running in XML-Server.

When you point Visual XML to a data source, such as an address, it creates a doclet that turns the data into an XML document and its DTD. By using that doclet, any application can read the XML and the DTD and turn it back into data for other applications to read.

Once XML-Server has converted data into XML, it's done. The server then passes the XML data objects to the next layer, either a Java or Visual Basic application, a browser or a device.

Excelon is used to distribute data to the next layer. Excelon is an application server that doesn't worry about distributing the load, where the data came from or what platform the data is running on. Excelon only performs the processing and serves up the data.

Excelon turns the XML elements into persistent objects. Unlike transient objects, persistent objects can be operated on.With persistent objects, you can conduct backup and recovery, survive network glitches, support XML extensibility and perform transactions.

"We're using XML as a communications protocol or a vehicle," says John Capobianco, senior vice president of marketing at Bluestone. "XML lives long enough to be communicated with," not stored.

One of the most advanced features in XML is its extensibility. Simply put, you can add a new tag to a customer record and not render all the other records unusable, or doom the application that's processing them. Without XML, adding an extra field to a relational database is sure to blow your schema, and either throw all your other fields off or confuse the application. Either way, you've got trouble.

With XML, applications ignore any tags for which they don't have instructions. As long as you tell the application, which could be anything from enterprise resource planning to a browser, what to do with the tag, it will correctly interpret the information.

If you're running business-to-business e-commerce, you might use WebMethods' B2B Integration Server. B2B serves as the link between your applications, such as ERP and databases, and your partner's Web sites and ERP systems. B2B maps applications and data on both sides of the site into, and out of, XML.

If you think it sounds like EDI, you're right. If you think XML will replace EDI, the answer's not so simple. "Functionally, it's a replacement for EDI," says Phillip Merrick, president and CEO of WebMethods.

However, few companies are going to replace their established - and costly - EDI systems. Merrick sees XML slowly replacing EDI in e-commerce applications.

"We really believe that a lot of the application servers are going to offer XML services analogous to connectivity services and device services," says Josh Walker, an analyst at Forrester Research.

But, he adds, there will be few people using XML services in the near future, because everyone's in the wait-and-see stage.