ebXML Gathers Pace

May 24, 2000

Alan Kotok

The Electronic Business XML initiative (ebXML) to create a global XML business specification became more visible at its week-long meeting in Brussels, May 8-12. By the end of the week, the group showed off a prototype of its early business process and messaging concepts and voted on a set of business and technical requirements. But concerns remain about ebXML's ability to deliver on all of its promises in the 12 months remaining in its self-imposed timetable.

The joint initiative of OASIS and UN/CEFACT began in November 1999, seeking to develop specifications for exchanging business messages worldwide using XML. Like other business frameworks, such as BizTalk and eCo, ebXML defines a common structure for interoperable messages sent between companies and among industries. Unlike most other messaging frameworks, however, ebXML is creating an end-to-end architecture that includes not only messaging but also generic business process models, a core set of common data components, and distributed repositories for storing industry or company requirements. The group hopes its work will stimulate development of inexpensive solutions that any company anywhere can use.

First Proof of Concept Test

An early proof-of-concept test demonstrated by Nick Kassem of Sun Microsystems at the closing plenary session showed how some of the ebXML specifications could work, but it also highlighted the extent of the work that lies ahead. In the test, fictitious companies that had never done business before achieve a desired outcome, in this case have a travel agency update a customer preference profile residing at an airline and car rental company.

The test began with a download of a business model written in UML from a simulated repository. An XML document type definition based on a UML class diagram from that model provided a set of sample request, response, and acknowledgment messages for updating the customer's travel profile. The customer, interacting through a portal, entered the new data for the profile, and the choreographed message flow took over from there. The message structure in the test used a series of envelopes for transport (HTTP for the airline, and SMTP for the car rental company), message (MIME), and message header (XML).

While the prototype offered the first concrete evidence of ebXML's efforts so far, it also showed the lengths that ebXML still needs to go. The test covered only the business process and packaging-routing-transport specifications. The payload content used in the test came from the Open Travel Alliance's XML specification, and while it reflected travel industry needs, it did not have any ebXML core components for interoperability. The repository exchanges were likewise created for the demo and did not reflect any ebXML repository specifications.

Requirements Specifications Approved

With one-third of its 18-month timetable completed, ebXML began to roll out its specifications at the Brussels meeting. Attendees approved a comprehensive requirements specification at the closing plenary, but only after ironing out late details during the week, and giving the new attendees (about half of the 200 that registered) time to read over the 30-page document authored by a team headed by Mike Rawlins of Rawlins Consulting.

The requirements document covers both business and technical needs, as well as a generalized list of deliverables. The technical requirements read like wish-lists from the various project teams doing the detail work. The business requirements, however, provide a better look at the outcomes that ebXML needs to achieve, and criteria on which the specifications will be judged.

A section on conducting electronic business using ebXML explains how the specification aims to support a wide range of business environments with varying degrees of sophistication. The document says that exchanges

may either be completely without human intervention, as is the case with traditional EDI, [or] with some level of human intervention to correct missing or erroneous data. Because a majority of businesses do not have sophisticated IT architectures, business applications will need exchange structured business documents with trading partners who will be limited to viewing and manually processing both inbound and outbound transactions

(electronic business XML Requirements Specification, p. 11)

All XML framework specifications claim interoperability as one of their key objectives, and ebXML is no exception. The requirements document spells out eight features of interoperability that the ebXML architecture should provide:

1. Common business processes that execute the same transaction in the context of a business process

2. Common semantics, defined as a common meaning, distinguished from the verbal expression or presentation of that meaning

3. Common vocabulary that connects words to the common meaning expressed in the semantics

4. Common character encoding; the document indicates Unicode provides this feature

5. Common expression, as presented in a common set of XML elements and attributes, specified uses of those data items, and a common document structure

6. Common security implementations

7. Common data transfer protocol

8. Common network layer

The business requirements also point out the need for making good use of existing investments in EDI and XML vocabularies, recognizing that businesses will need to exchange data in more ways than just ebXML. The document calls for identifying common data items, defining them in a neutral syntax, and making them reusable. It specifies the use of business process models to define both the data items themselves as well as their context.

The neutral syntax for these common items is a key feature of the ebXML requirements, but also an elusive goal. In the closing session, representatives of the team proposing ebXML's overall technical architecture said its group remained split between using linguistically meaningful terms and non-significant codes. The requirements document, however, says that if ebXML cannot find a suitable existing set of terms, it should develop its own.

The approved document also includes security requirements. It acknowledges that security needs will vary from one application to the next, but still must address confidentiality, integrity, authentication of sender and receiver, non-repudiation of origin and receipt, and archiving to reconstruct the original intent of the message. It has a separate section on digital signatures that indicates their growing use and recognition in many jurisdictions as having the same force of law as traditional pen-and-ink signatures.

More Specifications Coming Soon

Most of the other ebXML technical teams also reported progress in Brussels in completing their draft specifications. The transport, routing, and packaging team (headed by Rik Drummond of the Drummond Group) had finished its first draft specifications before the Brussels meeting. However, during the meeting the team found itself answering questions about ebXML's relationship to the Simple Object Access Protocol (SOAP) version 1.1, submitted for consideration to the World Wide Web Consortium in the same week as the meeting. SOAP is designed for message exchanges and includes envelope specifications, as well as datatyping rules and conventions for remote procedure calls and responses. This team already had a review of SOAP on its agenda, but the announcement added new urgency to the task.

ebXML's business process team, headed by Paul Levine of Telcordia Technologies, completed most of its first specification and expects to have it out for comment by the end of May. Defined business processes identify message flows and enhance the interoperability between businesses exchanging messages. As part of the proof of concept demo in the closing plenary, the test downloaded a UML class diagram that specified the message flows needed to update the sample travel customer profile. This team will provide a meta-model that describes business semantics, defined as roles, interactions, messages, and data. The team borrowed from RosettaNet's and eCo framework's significant work on process modeling.

The registry and repository team, chaired by Scott Nieman of Norstand Consulting, has one of the more critical tasks: designing the storage and access functions with which companies wishing to exchange business messages will find the rules of the individual industries and companies. Klaus-Dieter Naujok of Harbinger, who chairs ebXML, calls the registry and repository work "the key to the whole initiative." Nieman's team completed its first draft of a business domain definition, based in large part on UML modeling as well. The group still has its e-business requirements, analysis, and design work to go. Nieman calls it a large and complex task.

The technical architecture team, chaired by Anders Grangard of EDI France, completed a first draft specification for its initial review. The architecture document identifies the important pieces of the ebXML puzzle and shows how they fit together. Architecture team members raised questions about the growing dependence on UML modeling, particularly if smaller companies with limited resources needed to first define these models in order to transact business with ebXML. Several participants in the closing plenary noted that models will be defined in advance, not written on the fly, and transparent to end-users.

The core components team, chaired by Lisa Shreve, consultant and leader in the X12 EDI committee, completed a draft of its paper with a methodology for identifying and describing these common objects found in electronic business messages. The team worked with tools that help capture core components, and tested their concepts in three business domains: travel-tourism-leisure, manufacturing, and international distribution. By the next meeting, the team plans to finish its definitions of core components and methodology specification, and begin work on its extensibility methods.

Show Me the Goods, Not Just the Documents!

Specifications make good documents, but a skeptical technology community needs more of these tangible results to prove that ebXML can meet its aggressive timetable. A Gartner Group report earlier in the year raised questions about the ability of ebXML to achieve its goals, especially in the limited time frame it has set for itself. Naujok, the ebXML Chair, reported that some industry groups have asked to partner with ebXML on joint projects to pilot test the specifications, and asked the ebXML marketing team to draw up the ground rules for these activities. The ebXML leadership also added a proof-of-concept team to design and conduct these tests.

The next ebXML meeting takes place August 7-11 in the San Francisco Bay area.