ebXML: Assembling the Rubik's Cube

The fourth meeting of the Electronic Business XML (ebXML) initiative, 7-11 August 2000 in San Jose, California, saw the project consolidate some of its early progress, add new functionality, show off more of its messaging capabilities, and attract an important new industry partner to its cause. But despite the progress, participants at this latest meeting were bogged down fitting important pieces of its technology together to complete this comprehensive specification on time.

The ebXML initiative, started last November, is creating a global framework for the exchange of business data using XML across industries and among businesses of all sizes. And while at first glance it may look like another business framework using XML, ebXML hopes to combine the experience from 20 years of EDI with XML's capabilities to fix EDI's shortcomings, which has prevented all but the world's largest businesses from enjoying the productivity benefits and process improvements of exchanging data electronically. (See XML and EDI, Lessons Learned and Baggage to Leave Behind, XML.com, 15 August 1999).

The ebXML architecture combines message format specifications with business process models, a set of syntax-neutral core components, and distributed repositories with which businesses will interact. In their earlier meetings, ebXML's project teams wrote the requirements and outlined the various parts of the architecture (see ebXML Gathers Pace. XML.Com, 24 May 2000). In this meeting, the development teams continued defining the individual specifications, but also started to reconcile these various parts.

Architecture begins to hang together

In a general session at the mid-point of the week-long meeting, Duane Nickull of XML Global presented the most detailed discussion so far of the overall architecture to the participants, who numbered about 175. He defined the architecture in terms of layers: with business processes in one layer, and core components with the business information in another layer. A third layer in the architecture contains the discovery of trading partner requirements needed to do businesses electronically.

A key feature of ebXML, which separates it from most other XML business frameworks, is its emphasis on business processes rather than business documents (not to be confused with XML document instances). A business process team in ebXML defined a meta-model that describes patterns of processes used to achieve business goals. These processes contain the message sequences, called choreographies, and detail the data actually exchanged among parties. As a result, ebMXL processes define a series of actions such as "deliver a service" or "purchase a product," rather than electronic versions of paper documents such as purchase order, ship notice, or invoice.

Another critical feature, and one that also separates ebXML from most other vocabularies, is core components, the reusable data items found in business messages, designed by another ebXML team. While ebXML defines these components as semantically neutral objects, their actual meaning in business messages depends on their context, provided by the business domain and industry in which they are found. Core components can be single elements or aggregates, defined as natural collections of elements. A telephone number, for example, can contain a country code, city or area code, and number, which when strung together constitutes an aggregate.

To illustrate the use of core components, consider how different businesses and industries use different terminology to represent the same idea, and in some cases even the same person. Airlines call the person with an airplane ticket a passenger, while that same person can buy a gift at a store within minutes of landing and be called a buyer. He or she can send the gift home with a package delivery service who will call the party a shipper, from a hotel who calls the individual a guest. Each time this same individual, with the same set of identification data (street address, telephone, e-mail) may pay for these items with the same credit card.

Thus, the same person engages in several different transactions with several different businesses, and with much the same kind of data, but is called by a different name each time. A common set of data items can help bridge these semantic hurdles when the various processes and messages need to interact with each other. Yet each industry still talks in its own language, and it would be highly unrealistic to expect industries to change. Core components provide a way for the different industries to continue using their own terms in business messages, yet relate them to common business processes and neutral identifiers provided by ebXML. As long as trading partners can relate their own terminology to a neutral ebXML syntax, businesses have a basis for achieving interoperability.

Can't we all just get along?

Getting the business processes and core components to fit together in the architecture has proven more difficult than anticipated. The two teams formed a joint working group at an earlier session to iron out differences, but progress apparently came too slowly for the ebXML leadership. In the opening plenary session on Monday 7 August, ebXML chair Klaus-Dieter Naujok of Nextera Interactive pointedly instructed the two teams to settle their issues quickly. According to a number of team members, the ebXML leaders had by mid-week increased the pressure on the members to resolve their differences, a tactic that did not sit well with some participants. (Two members of the core components team complained openly in the closing plenary about the process. Members of the ebXML executive committee agreed to meet with the individuals to resolve their complaints.)

The pressure seemed to work, however. In the closing plenary, Lisa Shreve of Syscom Strategies and Karsten Reimer of Sun Microsystems -- leaders of their respective development teams -- described a unified field theory of ebXML that ties the core components more tightly to the business process meta-model itself, and gave a preview how the two elements would work together. Shreve and Reimer proposed a set of predefined rules as well as business processes to generate business message definitions, message sequences, core components, and the contexts that give the components meaning.

Messaging specifications take the lead

The transport-routing-packaging team, headed by Rik Drummond of the Drummond Group, has progressed further than the rest of the development teams. Much of its earlier work covered messaging services -- message structure and headers -- that the team has largely completed. During the previous ebXML meeting in May, Microsoft, IBM, and others announced submission of version 1.1 of the Simple Object Access Protocol (SOAP) to the W3C. SOAP offers a specification for XML messaging, and at the time seemed like a challenge to the messaging work done by ebXML.

In the opening plenary session on Monday 7 August, Drummond said that a review of SOAP suggested that its all-XML messaging in high production volumes could overwhelm most XML parsers, while the combination of MIME and XML headers in the ebXML messaging services specification provided more robust support. He noted as well that Microsoft's BizTalk 2.0 specification accepts MIME headers on messages.

In addition to headers and message structure, the transport-routing-packaging team began specifications for reliable messaging, a term used to describe the need to send a message only once and provide persistence in the face of server failure. The teams still needed to develop the security part of the specification, but anticipated no real problems in completing that part of it.

[1] [2] Next