XML has been touted to the point where you may think it's the greatest thing since sliced bread. As a technology, it's certainly achieved a level of respectable hype. However, does XML have what it takes to solve the problem of seamless business-to-business communication? To answer this question, I'd like to present XML under the limelight of EDI (Electronic Data Interchange). Using human-to-human communication requirements, I'd like to extrapolate those into business-to-business communication requirements and show that XML, by itself, solves only a portion of the problem but can act as an enabler for solving the rest.
How Do We Communicate?
I'd like to focus on the topic of human-to-human communication. This is an analogy similar to the one that RosettaNet, an organization geared toward specifying the interfaces for electronic commerce, used in their overview. It's a scenario we've all experienced and can easily relate to when compared to a similar machine-to-machine scenario. In Figure 1, when a person wants to talk to another person, he or she needs to develop a thought, usually containing some idea or topic the recipient will understand. The speaker must translate these thoughts into spoken words. This isn't a simple task. The speaker must identify the appropriate words from his or her vocabulary and group them according to some grammatical rules. The speaker then verbalizes a sentence or a phrase that produces a series of airwaves that is ultimately received by the listener. The listener hears the sentence and, using the same rules, processes it into a syntactic structure of recognizable words, interprets the semantic meaning and eventually duplicates the speaker's thought.
We probably perform this simple communication task a thousand times a day. All of us take these simple acts of speaking and listening for granted. What we don't consider is the standard infrastructure in place that allows us to make verbal communication. What are these standards? The green boxes in Figure 1 represent an implied standard.
If speakers and listeners don't have agreements on all the green boxes, communication will be impossible. For example, if the speaker is addressing one topic and the listener expects to hear a different one, the listener won't be able to put the speaker's sentences into context. I'm sure all of us have heard the phrase "What are you talking about?" Similarly, if the participants have different sets of vocabulary and grammar, the meaning of the original thought will be lost.
The Role of XML
In the growing world of electronic commerce, common standards are needed, especially in an environment in which machines talk to machines. Figure 2 illustrates where EDI and XML fit in the world of standards. You can see that the role of XML is smaller than that of EDI. Before you protest, allow me to explain. XML is a standard that governs how data is to be represented. It has provisions for defining data elements plus extending and customizing data structures. The power of XML is its flexibility to define an arbitrary data structure for both machines and people. A data structure defined in XML can be validated and easily parsed by using readily accessible, standard parsers. Its standards are predominantly applied to data schemas. What ASCII is to character encoding, XML is to data structures. In summary, XML gives you the power to specify the vocabulary but it doesn't impose or attempt to standardize the individual elements of the vocabulary.
XML isn't a dictionary, only a means of formulating one. Using the example of human communication, you should be able to see that XML considered as a standard is simply not enough for meaningful communication. This is why, in Figure 2, the XML covers only part, not all, of the vocabulary section.
The Role of EDI
What is required is a standard that can embody a business dictionary in the context of business processes. This is where EDI comes in. With its long history, EDI provides common meaning to business transactions through the use of standard business documents. These documents purchase orders, invoices, etc. represent the contents of day-to-day business transactions. The set of business documents encapsulates business events and processes. Typically, a three-digit number is used to represent the document type. In the case of a purchase order, the number 850 is used. There are many standard bodies associated with EDI. The common ones are EDIFACT (EDI For Administration, Commerce and Transport), used primarily in international circles, and ANSI X.12, widely used in North America. EDI embodies more than just data definition, as it also dictates the transporting and administering of the documents.
A traditional EDI player is probably also a member of a Value Added Network. A VAN is like a private Internet hooking up businesses through modems. In addition to the network services, a VAN will also provide services along the lines of guarantee receipt, reporting, auditing and security. It's not cheap to obtain a membership in a VAN, which is generally more expensive than the Internet. In short, the VAN creates a virtual business community by acting as a hub for businesses to communicate using the EDI document standards.
Figure 3 shows a typical EDI transaction. A vendor creates an order document by populating fields in the document with information derived from its back-office systems, typically some form of ERP (Enterprise Resource Planning) system. Integration is required to extract the relevant values from this system. The values are then stored in the appropriate fields within the document via a piece of EDI software known as a Translator. The order document is sent along the VAN to be received by the supplier. The supplier, using a similar Translator, strips the relevant information from the order document and transfers it to its back-office system. During this transaction the VAN can provide various security and audit controls; it can also provide an acknowledgment to the vendor that the supplier has received the order. The supplier processes the order and in so doing sends an invoice document back to the vendor in a similar manner.
While the EDI documents provide a rich platform for business communication across different industries, from retail to government, they're sometimes viewed as being too rigid for certain businesses. Although the EDI documents provide optional capabilities, the documents can't be easily extended like XML. As business processes change, the demand for new fields arises. Users of EDI begin to tweak the standards by placing information where it doesn't belong in the documents. Data that didn't fit often ends up in unused fields. The semantic meaning of the fields then deteriorates, because now it represents information other than its original specification. This ad hoc solution works as long as all the trading partners are aware of the tweaks.
The concept of EDI is a good one. However, its implementation of a rigid document set sent over a proprietary network infrastructure and expensive translator software for back-office integration tends to inhibit the participation of new players in the world of electronic commerce. The XML technology opens the door for companies that didn't have the opportunity to participate in EDI in the past.
XML and Industry Standards
The XML community is offering a more effective solution. First, the coverage area of the VAN is a far cry from the coverage area provided by the Internet. The Internet also lessens the need for a proprietary network like VAN. Second, publicly available XML parsers are making it extremely easy to read and integrate with XML documents. Although this solves many technical issues of communication, the major part of the problem is still defining a set of standard business definitions that would include common grammar and vocabulary. It's worth noting that there's an XML/EDI Group trying to marry the flexibility of the data definitions of XML with the business language and practices of EDI.
Other major forces, such as RosettaNet, CommerceNet and OAG (Open Applications Group), are also trying to leverage the extensibility nature of XML to fill the grammar and vocabulary gap. These are organizations with big players that are undertaking the daunting task of specifying the business dictionary using XML. Within these organizations you'll find EDI standard bodies such as ANSI ASC X.12 and UCC (Uniform Code Council). There are also companies, such as Ariba, that are defining cXML, a set of XML schemas for procurement and catalog operations. New XML schemas are being created every day, which creates a new problem. Which definition should I use? Which dialect should I speak?
To tackle part of this problem, organizations such as Microsoft's Biztalk.org and OASIS's XML.org are beginning to take shape. Their purpose is to act as a clearinghouse for XML documents by soliciting business partners to collectively create a vocabulary repository. Different XML schemas are published in these clearinghouses for others to consume and use. They represent a hub for the business community of business dictionaries specified in XML.
The EDI experience has taught the electronic-commerce community about the need to customize and extend. An order document in the auto industry will be different from one in the electronic industry. The health-care industry will have business processes substantially different from processes in the retail industry. Each vertical industry will demand its own set of business documents. A horizontal process, such as order entry, will be different for each industry, resulting in different business documents to be transacted. The combination of the expressive power of XML and the development of big organizations to produce common business dictionaries is finally beginning to bridge the gap of our communication stack.
Is This Enough?
In the age of the Internet, XML offers an opportunity to rethink the implementation of EDI but it can't replace it by itself. The standard business dictionaries stemming from standard organizations are crucial to the success of business-to-business communications. The extensibility of XML will ease the traditional EDI pain of being too rigid in definition. The pace of competition is extreme and this means businesses need to be as agile as ever. This competitive environment forces businesses to change and upgrade their processes frequently. These changes in processes may lead to changes in messages. How well will XML, along with the armies of standard bodies, keep pace? Only time will tell.
Open Applications Group:
Data Interchange Standards Association (DISA):
Kang Lu, a software development manager at Ironside Technologies Inc., Markham, Ontario, is a Sun Certified Java programmer with 11 years of programming experience. A graduate of the University of Toronto with a B.A.Sc degree, Kang Lu is responsible for the delivery of
e-commercebased architectures and infrastructures at Ironside.
Kang can be contacted at [email protected].