During the first week of February 2000, almost 130 people met in Orlando, Florida for the second meeting of the Electronic Business XML Initiative (ebXML). This initiative is jointly sponsored by the United Nations body for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS) to produce a global standard for e-commerce. A primary objective of the initiative is to lower the barrier of entry to e-business for small- and medium-sized businesses and developing nations.
The structure of the ebXML project is fairly straightforward. There are eight project teams (or working groups): ebXML Requirements; Business Process Methodology; Technical Architecture; Core Components; Transport/Routing and Packaging; Registry and Repository; Technical Coordination & Support; and Marketing, Awareness, and Education. Worldwide experts from many different industry areas, including EDI, Internet technologies, XML, registry, business processes, e-commerce server intercommunications, and architecture were present. The participants established a uniform focus and made agreements in a number of areas, including directions in architecture, registries, modeling methodologies, and the approach for defining the core data elements. You can find further details at http://www.ebxml.org.
As chairperson of the Transport/Routing and Packaging team, which will produce the technical specifications for the e-commerce server intercommunications architecture, and as a member of the ebXML steering committee, I have some unique insights I'd like to share with you.
Many of us have been working on e-commerce standards for more than four years. I jointly led the effort in the United States for XML/EDI three years ago, and I've also led the IETF workgroup for Secure EDI over Internet. More recently, I led one of two groups in the eCo Framework effort sponsored by CommerceNet. Each of these was exhausting, yet we didn't solve the problem of establishing a global standard. Still, each brought us a level forward toward the goal. I'm excited about the ebXML effort because it's our only chance in this decade to establish an international e-commerce standard.
The vision of the Transport and Packaging team is to produce a specification for a set of services and protocols that will let an e-commerce client request services from e-commerce servers over any application-level transport protocol, including SMTP, HTTP, FTP, and many others.
Although the issues are technically and procedurally complex, the concept is simple. Our focus is to construct a general-purpose message, with a header that supports multiple payloads, while allowing sufficient digital signatures within and among related messages. The body will probably be a construct of XML and MIME. The headers will be XML. Conceptually, this looks like a very complex e-mail message using MIME types. In practice, it will be much more.
One of the key problems in e-commerce is the inability of existing protocols to support and invoke sufficient services as they arrive at the destination server. Services that we envision, but are not yet firm, include normal e-mail and EDI-type header fields such as: to, from, date, time, time stamp, digital signature, audit trails, encryption, and a transaction process description, which we call a "choreography," based on the RosettaNet specifications. A simple choreography might be where a message is sent to a server and a response is received. These two messages together form the choreography of the transaction.
The complexity rapidly increases as the choreographies that must be supported increase. The choreographies are often business sector- or application-specific so that the only people who know them well are the business process experts in that application and industry. The only way to support this is to make the headers extensible and expandable for industry-specific usage. We're evaluating headers from the automotive industry (E5 specifications), Business Quality Messaging (BQM), and XML messaging, as well as many others, to form a basis for recommending our header contents. Others who wish to participate should enroll in this open effort through the ebXML Web site.
We see choreographies all the time in information gathering on the Web. More sophisticated transaction choreographies need to be supported, such as those used in an Internet credit card purchase transaction, including, for example, issuing the request to buy, verifying the credit card, and confirming the purchase. The shipping facilities are contacted and the product shipped. However, the transaction isn't completed until all of the above steps have taken place -- possibly over an extended time period. This choreography involves the concept of two-phase commits in database technology, which is a complex transaction that ebXML must support. One of the most complex choreographies comes from the travel industry, where a single transaction may be composed of airline, car rental, hotel, and other bookings that occur across multiple industries and organizations.
The Transport/Routing and Packaging team started the process (figure 1) by looking at specifications from Business Quality Messaging (IBM MQSeries and Microsoft Server Message Queue are examples of implementations), E5 specifications from the North American auto industry, functionality specifications from the IETF's XML messaging work group, and others. We still need to evaluate headers from enterprise resource planning (ERP) vendors, as well as from applications based on Microsoft's BizTalk, Sun's Java Messaging Services, and HP's eSpeak, among others. We've also been communicating and coordinating efforts with other associations, such as the Open Application Group, RosettaNet, and the Uniform Code Council, to ensure that our header definitions are robust enough to support the needs of worldwide e-commerce in this decade and the next.
Figure 1: Team Architecture -- This represents the current thinking of the Transport/Routing and Packaging team, although this design is not confirmed.
A look ahead
At the next ebXML meeting, we'll have a straw-man paper on the components to test the waters on the directions and goals of ebXML. We also may be able to demonstrate the basic capabilities of the specifications.
Since this is an open group, we encourage anyone that's interested to participate. The group hopes to have specifications available in the summer of 2001, which will support generic e-commerce at the international level. These specifications will cover registries, data elements, transport protocols, and modeling techniques. When that's accomplished, the rapidly expanding non-interoperable standards in the e-commerce XML arena will have a way to interoperate within a common architecture.
E-Business Benefits
ebXML is intended to provide a globally developed, open XML standard designed for businesses of all sizes.
The emerging standard will provide a framework for a variety of shrink-wrapped solutions that complement and extend existing investments.
The goal of the ebXML initiative is to provide a single standard that combines existing and emerging XML standards.