InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

January 3, 2000

The Rush To XML
continued...page 2 of 2

Illustration by Dave Plunkett

Related links:

XML: The Language Of Integration

XML Toolbox

And from our sister publication:

InternetWeek Vendors Debut XML Development Tools

Send Us Your Feedback

Intra-enterprise application integration refers to the process of integrating two applications within the organization, such as enterprise resource planning with customer-management systems. In the past, companies have spent considerable effort to forge custom integration or, more recently, have purchased application-integration solutions. Both approaches are labor-intensive and costly and have proven difficult to maintain.

But most of what companies want from application integration is data integration. For example, they want certain data from their ERP system to be passed to the customer-management system. Businesses use XML to describe a variety of data types and give them semantic meaning.

NuSkin Enterprises Inc., a Provo, Utah, maker of beauty products, is experimenting with XML as a way to integrate its SAP R/3 ERP system with a variety of other applications, moving data with a lot of record formatting. By converting those formats to XML, says NuSkin software engineer Joseph Ruffolo, the company should easily move data between systems that support XML without having to map the record formats to each individual system.

Automotive Rentals Inc., a Mount Laurel, N.J., fleet-management company, also had the problem of exchanging information between multiple systems. Unable to get all its divisions to standardize on the same system, the company is turning to XML to pull data into common fields. Automotive Rentals could have come up with its own common data format, a tedious and labor-intensive effort, but XML was there and was fast and easy, says Bill Kwelty, the company's manager of customer services.

The biggest interest in XML, however, is focused on business-to-business applications. XML provides a standard way to express data in a structured format. More important, it provides a common vocabulary for understanding the data along with the structure.

The common vocabulary is contained in the document type definition, an ASCII file that describes the meaning of the particular XML tags. The document type definition, which describes the fields and their attributes, can accompany the document, allowing it to be read and understood on the fly by any XML-capable system. Companies can create DTDs for themselves, or join together in industry groups to create them for a particular industry.

The emergence of industry-specific DTDs will fuel the adoption of XML in the business-to-business arena. By standardizing on a set of DTDs, trading partners can exchange XML documents and send and receive requests for data quickly and easily.

EDI was supposed to do for business-to-business data exchange what XML seems poised to do. EDI provides a way to exchange information between organizations in a highly structured way for specific purposes.

While EDI sounds good in principle, it has proven very difficult to implement in practice. Industries spent long periods of time just hammering out the EDI formats. The technology requires the use of complex systems and pricey, value-added networks. EDI also entails painstaking mapping from one field to another. If something changes, even something as minor as adding a new digit to a product identifier, everything has to be redone. Although large companies adopted EDI, often forcing their suppliers to go along reluctantly, the majority of businesses ignored EDI.

By contrast, XML is much easier to deploy, which makes it a natural for business-to-business use, says Sabre's Offutt. XML is based on Internet protocols such as HTTP, rather than relying on some value-added network. The tools--text parsers and Web browsers--are widely available, low-cost commodities. And, companies don't have to hire hard-to-find and highly paid EDI specialists. Almost any programmer can become proficient with XML in a matter of hours. As a result, XML can succeed where EDI and EDIFact has struggled, Offutt says. Where it takes a company six months to implement an EDIFact system at a price that can run well into six figures, he says, a comparable XML system can be implemented in days for little additional cost.

Despite its obvious advantages in business-to-business and enterprise application integration, XML isn't a foregone conclusion. As a markup language, XML lacks procedural capabilities. It must be augmented with some sort of processing, whether scripting or programming, to process the XML data once it gets where it is going.

Also, Hurwitz Group's Russom suggests, companies will need a way to query XML data, an XML equivalent to SQL. A standard has been proposed, XQL, but it hasn't been finalized. Meanwhile, Offutt and others want business processes defined in XML. By defining business processes in XML, the accompanying scripting could be simplified, if not eliminated.

As the new decade begins, XML is far better than anything else available. It's already being widely adopted by systems integrators and vendors, who are working XML into many products.

For most IT organizations, however, XML may remain essentially invisible. Instead, business-to-business service providers will simply incorporate XML into their products, portals, and tools. "Companies will be aware of XML and get the benefits of it," says Gerald Lester, a senior consultant at Computerized Processes Unlimited Inc., a provider of XML integration software for the process manufacturing industries. "But they won't have to interact with XML unless they want to."

return to page 1