Welcome to the third installment in our ebXML series. ebXML is an international initiative to develop and promote a set of standards for electronic business with XML.
This article reviews a typical ebXML transaction. It helps illustrate the key benefits of ebXML.
Without
Figure 1 is an electronic business scenario without ebXML. ACME Manufacturing and one of its largest supplier, Coyote Industries, want to implement an electronic relationship. The goal is to streamline ACM procurement, reducing costs and increasing competitiveness.
Click here for larger image
Let's assume that business issues have been dealt with: ACME wants to buy from Coyote, they have agreed on terms and payments (otherwise there's little point in implementing an electronic relationship anyway).
ACME and Coyote add an XML connector to their business management system (such as SAP, Peoplesoft, Sage or QuickBooks). That should be easy, right? Wrong!
There are many technical issues to be dealt with: which XML schema to use, what security to put in place, how to chain electronic messages (e.g. does Coyote invoice ACME for every order or does it issue a monthly invoice), what communication protocols to adopt. There are also many parameters to get right: the address of the server, time-outs, and more.
Currently setting up an XML connector is a lengthy and costly business. It requires many back and forth, meetings/phone calls between trained professionals and, generally speaking, it's not very efficient.
With
Figure 2 is the ebXML equivalent of figure 1. The only difference, but it's a significant one, is that the slow, costly process of setting up the connector has been automated.
It starts (step 1) with ACME looking up Coyote information in a registry. A registry is an open directory where companies list a very detailed description of their electronic capabilities.
In ebXML lingo, the description is known as a CPP (Collaboration Protocol Profile). The CPP contains the answer to the questions discussed in the previous section: which XML schemas Coyote recognizes, the security mechanisms it has put in place, the address of its server and much more.
In a second step, ACME matches Coyote description with its own to find commonalities. In the process it creates a CPA (Collaborative Partner Agreement) that describes how to establish the electronic relationship. In essence, the CPA is the answer to all the questions put forward in the previous section.
How to build the CPA? In most cases, the choices are simple and can be automated. For example, if Coyote supports HTTPS or S/MIME but ACME supports S/MIME and PGP, the only practical option is S/MIME. Some issues might not be so clean cut and would be reviewed by the operator installing the software.
ACME sends the CPA to Coyote for validation. When Coyote accepts it (which again can be automated), they're in business.
Step 3 and beyond is to exploit the business relationship.
The dotted line between Coyote and the registry in figure 2 indicates that Coyote will update its CPP as it adds or removes capabilities. E.g. if Coyote adds PGP support, it needs to say so in its CPP.
A fundamental difference
The fundamental difference between the two scenarios is that, with ebXML, the costly configuration is now automatic which means cheaper and faster.
Although on a larger scale, ebXML proposal is not unlike plug-and-play. Not so long ago, you needed a professional to add a device to a PC. He or she had to know about BIOS, jumpers, IRQ, DMA, and more. Thanks to small profiles that ships with cards, the computer has now largely taken over and automatically choose the best settings.
Obviously there is another difference between the scenarios with and without ebXML. If you can establish electronic relationships in minutes instead of weeks, then you can afford to build many more of those.
Benoît Marchal is a Belgian developer. He is the author of XML by Example and other XML books. Benoît is available to help you with your projects.
IE 7
Firefox 2.0
