OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: ebxml article




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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC