ebxml article

[richard drummond <rvd2@worldnet.att.net>]

ebXML: Assembling the Rubik's 
Cube
by Alan Kotok

Table of Contents

•Architecture begins to hang together

•Can't we all just get along?

•Messaging specifications take the lead

•Repositories: More than just containers

•More functionality added

•Test of ebXML messaging demonstrates multiple trading-partner interactions

•Global Commerce Initiative chooses ebXML

•Are we there yet?

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.
Repositories: more than just containers
Another key 
feature in the ebXML architecture is the proposed set of distributed 
repositories, which will store all of the objects needed by trading partners to 
do business electronically. Nickull called the repository "the heart of the 
architecture", yet he also called it a black box--because its development lags 
somewhat behind some of the other ebXML features. In the week before the August 
meeting, the leader of the repository team announced he could not attend because 
of pressing business that required his presence elsewhere. David Webber of XML 
Global had to step in at the last minute to lead the repository development 
team. 
Repositories will provide trading partners with the process models, 
core components, predefined messages, model trading partner agreements, and any 
other objects to enable parties to exchange data electronically. The 
specifications will show how industries or companies can populate and update the 
repositories, as well as detail the features with which business users can 
access the repositories. Nickull said ebXML anticipates creation of a series of 
multiple distributed repositories; just one or even a few repositories would not 
likely scale sufficiently to handle anticipated message traffic. 
EbXML 
repositories will store the connections between an industry's own language and 
the core components. Nickull discussed a proposal for globally unique 
identifiers assigned to core components, to which industries could relate their 
specific terms, but the group had not yet decided which identifier to use. 
Industry repositories would also contain the industry specific components (those 
not covered by ebXML core components) needed to do business electronically. 
In the example of the single party in multiple contexts presented earlier, 
the same core component identifier would apply to the airline passenger, buyer 
of the gift, shipper of the package and guest at the hotel. Each industry's or 
company's repository would store the common identifier and relate it to its 
specific industry terminology--passenger, buyer, shipper, and guest. 
A 
registry serves as a repository's index and gateway to the outside world. An 
ebXML registry would contain an application program interface or API that 
governs how parties interact with the repository. In the ebXML architecture, 
businesses could query many repositories as long as they had ebXML-compliant 
registries. 
More functionality added
In the 
August meeting, ebXML added a new feature called the trading partner 
agreement. At the mid-week general session, Martin Sachs of IBM gave a 
presentation of the Trading Partner Agreement Markup Language (tpaML) developed 
by IBM earlier in the year. Trading partner agreements define the rules of 
engagement between entities that wish to do business electronically. The tpaML 
hopes to streamline the process of establishing electronic trading 
relationships, a process with earlier technologies that can take weeks or 
months. 
EbXML plans to integrate the trading partner agreement into the 
architecture, and created a separate work group, headed by Sachs, to develop 
that part of it. Sachs and his group will first write a UML model to describe 
the agreement process and write a specification based on that process. 
Test of ebXML messaging demonstrates multiple trading-partner 
interactions
In the mid-week general session, a proof-of-concept 
team, headed by Nick Kassem of Sun Microsystems, demonstrated the use of ebXML 
transport-routing-packaging specifications with a test of different 
message-exchange scenarios. The test involved systems from several companies: 
Fujitsu, Netfish Technologies, Viquity, Vitria, Sun Microsystems, and 
WebMethods. The tests also covered three message configurations: one-to-one, 
one-to-many, many-to-one. 
In each case, the scenario routed the message 
through a hub, provided by Viquity. The hub simulated a third party that could 
be employed to provide e-business services to smaller enterprises not able to 
support the entire ebXML architecture. Kassem said other tests by his team 
demonstrated point-to-point messaging, without the hub, but the session for the 
demonstration did not allow enough time to show it live. 
The team that 
designed the test based the messages on a RosettaNet Partner Interface Process 
for purchase order management. That process has a series of messages that 
include:

Purchase order request

Acknowledgment

Order acceptance

Receipt

The messages used ebXML headers, routing, and packaging, 
with the payload of the messages made up of content from the RosettaNet 
specification. In each case the tests followed the prescribed path, and each 
company's server showed either sending, routing, or receipt of the test messages 
as intended. 
Klaus-Dieter Naujok noted the value of these tests for ebXML. 
In a briefing after the session, Naujok said that proof of concept tests "make 
ebXML into its own customer, and turn theory into practice." He added that ebXML 
ideas are often implementable even before the final approvals of its 
specifications. 
At the previous ebXML meeting in May, a proof of concept 
test used one point-to-point exchange scenario. However that earlier test also 
simulated the download of a process model and message choreography from a 
repository. The August tests focused only on the transport-routing-packaging 
specifications. 
Global Commerce Initiative chooses 
ebXML
The ebXML effort got a big boost a week before the meeting 
when the Glocal Commerce Initiative (GCI) announced it would base its technical 
infrastructure on ebXML. GCI, composed of 40 manufacturers and retailers, 
includes such household names as Johnson & Johnson, Nestlé, Kraft Foods, 
Marks and Spencer, and Home Depot, with potential audience of 850,000 businesses 
worldwide, large and small. 
GCI on 31 July unveiled its Global Commerce 
Internet Protocol designed to overcome the rapid development of incompatible 
single-industry vocabularies and vertical exchanges. In order to achieve 
interoperability, the group's announcement noted that its "technical 
infrastructure standards have been developed by ebXML and form the basis of the 
GCI technical recommendation." According to a GCI announcement, four major 
exchanges in the consumer goods industry--Transora, the WorldWide Retail 
Exchange, GlobalNetXchange, and CPGmarket.com--voiced support for the GCI 
project. (See http://www.uc-council.org/news/ne_industry_issues_global_comm.html.) 
At the end of the week, the Open 
Travel Alliance, a current ebXML participant, offered its just-completed 
customer profile specifications to ebXML. It also offered to its align its 
specifications with related vocabularies, using ebXML as the vehicle. (See http://www.opentravel.org/opentravel/press_releases/pr081000.htm). 
Are we there 
yet?
Naujok noted at several points during the meeting that ebXML 
was now over the half-way point in its self-imposed 18 month timetable, and the 
group had to begin focusing more on delivery of specifications as well as 
development. To help with this task, ebXML formed a new team for project 
management and turned the technical coordination group into a quality assurance 
team. He asked all teams to plan on completing specifications within six months 
(by February 2001), saving the last meeting in Vienna in May 2001 for the 
finishing touches and plans for the future. 
While the organizational 
adjustments will help meet the challenge, there is no denying the extent of the 
job ahead. One participant called the overall architecture "the box top of the 
jigsaw puzzle." In fact, it more closely resembles a Rubik's Cube, with pieces 
of the puzzle fitting in multiple layers, all of which must work seamlessly. 
Much of the ebXML effort has so far gone into writing the individual 
specifications. If the development teams only had to write specifications, 
meeting the final deadline would not be an issue. As participants learned in San 
Jose, however, getting the pieces to fit together require as many people skills 
as technical ones. The eventual success of ebXML will probably depend more on 
these people skills than the UML models and angle brackets in the technology. 
Disclosure: Alan Kotok is Director of Education at Data Interchange 
Standards Association and a participant in the ebXML 
marketing-awareness-education team. In previous work he served as standards 
manager for the Open Travel Alliance.