Easing EAI with XML
Enterprise application integration (EAI) generally requires sending information between independently developed chunks of software. To make this work, the information must be in a form that's understandable by all the software involved.
For years, organizations cobbled together custom data formats, translated everything to the format of the most important application, or invented some other idiosyncratic solution. Today, though, there's a standard approach to describing data in a way that can be understood by all kinds of software. Rather than invent a format from scratch for each integration problem, every format can be defined using XML.
Given the increasing availability of XML parsers, XML-aware databases and other XML-oriented tools, taking this standard approach can make EAI a more tractable problem.
If all you're trying to do is define a standard data format for use in your own in-house EAI project, life is simple. First, you must define one or more Document Type Definitions (DTDs), generally known as schemas. Each schema defines a set of HTML-like tags that can be used to describe your data. For example, if you're trying to tie together two existing applications that each deal with customer data, the schema you define might include tags such as <customer>, <billing address> and so on. You can then embed these tags in the data you're exchanging, providing a common approach that lets both applications make sense out of the information they're exchanging.
So far, so good. And if all you're doing is tying together your own applications, using XML to define standard data formats can be relatively simple. The problem arises, though, when the goal is to integrate applications across organizations. Suppose you need to exchange customer information with applications in use at your suppliers. An XML-defined data format still makes sense, but who should define it? Various industry organizations are springing up to answer this question, defining schemas for different uses. But without some agreement on which ones to use, XML will never reach its full potential. Sadly, experience suggests that these kinds of agreements are notoriously difficult to reach. Everybody wants a standard that best matches his or her own way of doing things, and so arguments are inevitable.
Microsoft Corp.'s BizTalk initiative is, among other things, one attempt to sponsor the creation of a standard set of schemas. It appears that Microsoft is more interested in getting the process going than in dictating what the answers should be, which is as it should be: Only people in the industry in which a schema will be used have the knowledge to define it intelligently. Yet even the notation to be used to define schemas is up for grabs today. The current XML standard specifies precisely how schemas should be defined using DTDs, yet other approaches have also been advanced at the Worldwide Web Consortium (W3C). Referred to generically as XML Schemas, these other proposals for schema definition languages have some technical advantages over the older DTDs. But without industry agreement, they just create confusion.
A case in point is the latest incarnation of Internet Explorer. IE 5 ships with solid XML support, yet the schemas Microsoft provides are typically defined using Microsoft's XML schema language, not the currently standard XML DTD notation. Microsoft has submitted its schema definition language to the W3C, but other vendors have also provided input. The W3C has yet to approve any one approach as the successor to today's DTDs. Not only are we facing the challenge of defining standard schemas for various uses, we can't even agree on the notation we'll use to describe them.
I'm confident that these problems will eventually be solved. Until they are, however, be aware that the schema wars are just beginning. The impact on your internal EAI projects should be relatively minor. For larger, multiorganization solutions, however, these standards are essential. --David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at email@example.com.