Web services has the potential to transform e-business into a plug-and-play affair. Not only will Web services simplify how businesses interconnect, they will also enable businesses to find each other.

One reason for the increased interest in Web services is the promise of interoperability. However, complex standards are needed to achieve true interoperability, not only at the messaging and transport layer, but also at the business (application) layer. The success of Web services will depend on how easily businesses are able to engage interoperability at all levels.

There have been many efforts at standardizing Web services, but none of them provides the required features for e-business transactions. Web services standards only address the infrastructure side, but ebXML can provide the standards for interoperability at the business layer, making it the standard solution for Web business services. In other words, ebXML is the missing ingredient for Web services.

ebXML: What Is It?
In the summer of 1999 the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and the international technology business consortium called Organization for the Advancement of Structured Information Standards (OASIS) joined forces to produce a global XML framework for electronic business, called ebXML. At the start more than 120 companies and standards bodies signed up for the "ebXML Initiative." Over the next 18 months more than 2,500 participants across the globe worked on the development of several interrelated specifications. At the final ebXML Phase One meeting in May 2001, they ratified the first generation of ebXML specifications.

The reason for the successful creation and approval of the ebXML infrastructure specifications was that nothing new was invented. The project teams evaluated proven technology to be used as the baseline for all specifications. The editing teams leveraged as much existing technology as possible, including the World Wide Web Consortium's XML Schema, XML Linking Language, and the XML Signature Syntax and Processing specification. In addition, several references from the Internet Engineering Task Force's Request for Comments were considered. New initiatives that were launched well after the ebXML project started were carefully examined, including Security Services Markup Language (SSML), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and Integration (UDDI). SOAP was successfully incorporated into the ebXML Message Service Specification.

The ebXML infrastructure as documented in the suite of approved specifications provides the only open, out-of-the-box, standards-based solution ready for use. So what sets ebXML's solution apart from the rest? Many commercial solutions are available, however, none simultaneously supports all the business verticals. Enterprises electing to use one of these commercial solutions may not be able to participate in a truly global business environment.

ebXML Infrastructure Elements
The ebXML framework comprises five major work areas, three of which are infrastructure support services that facilitate registration of a business entity, discovery of business partners, configuration of business partner trading agreements, and exchange of business information.

The Registry/Repository component supports all of these functions, making it a major piece of the infrastructure. The ebXML registry provides a set of distributed services that enables the sharing of information. This simplifies business process integration between business parties. The Registry provides the interfacing access services by means of the registry information model and reference system implementation, while a repository provides the physical back-end information storage. For example, an ebXML registry may retrieve configuration information for a particular business entity from the Repository in response to a query, or the repository may contain document type definitions or schemas that are retrieved by a registry query.

Collaborative Protocol Profiles (CPP) are another key element of the infrastructure. The CPP specification is based on the Trading Partner Agreement Markup Language (tpaML) work begun by IBM. The IBM work was enhanced by the efforts of the ebXML Trading Partner Agreement project team to produce a method for defining the transport, messaging, and security environment of a specific business entity. Also, the team defined methods for dynamically exchanging the CPP data between business entities and negotiating message-exchange agreements between the parties. These profiles may be maintained by the individual business entities within the ebXML business domain or may be stored within an ebXML repository.

Information packaging and transport mechanisms, specified in the ebXML Message Service Specification, are the third critical component of the ebXML infrastructure. A protocol-neutral method for exchanging electronic business messages is defined in this specification. Enveloping constructs are specified that support reliable, secure delivery of business information. These flexible enveloping techniques permit ebXML-compliant messages to contain payloads of any format type. This versatility ensures that legacy systems using traditional syntaxes (i.e., United Nations Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT); ANSI X12; or Health Level 7 (HL7)) can leverage the advantages of the ebXML infrastructure along with users of emerging technologies. Interestingly, both IBM and Microsoft were instrumental in persuading ebXML to adopt SOAP as the foundation for its message services.

The other two areas of work contributing to the ebXML framework are Business Process and Information Modeling (BPIM) and Core Components; both relate to the content and context area. The business process team defined a metamodel that described business transaction patterns used to achieve business goals. In simple terms, these atomic business processes prescribe the detailed interaction of business documents and business signals among parties, called choreographies. ebMXL processes define activities such as "order goods" or "deliver goods," as compared with traditional EDI documents that are electronic versions of paper documents such as purchase order or ship notice.

Core components are reusable data elements found in business documents. They're semantically neutral objects; their actual meaning in business documents depends on their context, provided by the business domain and industry in which they are applied. Core components can be single elements or aggregates, defined as natural collections of core elements. A telephone number, for example, may contain a country code, city or area code, and number that when strung together constitute an aggregate. Core components provide the means for industries to continue using their own terminology in business documents, and at the same time relate their terminology to common business processes and neutral identifiers provided by ebXML. As long as trading partners can relate their own terminology to neutral ebXML core components, businesses have a basis for achieving interoperability.

ebXML: Phase Two
After the completion of the infrastructure specification, UN/CEFACT and OASIS signed an agreement to continue the ebXML work by assigning the infrastructure support services to OASIS and placing the business components within UN/CEFACT. This enables each organization to advance the work within its own area of expertise, ensuring continuing rapid progress.

UN/CEFACT is continuing the work started under ebXML Phase One, that is, to advance ebXML development as related to business processes, core components, and e-business architecture.

UN/CEFACT has adopted a business process and information modeling methodology, referred to as the UN/ CEFACT Modeling Methodology (UMM), that provides the framework under which the ebXML project teams concurrently develop technical specifications that fit seamlessly together with sufficient detail for ebXML-conformant implementation. An ebXML business process and information model draws from reusable components such as

Core components specialized for business context.

The business process and information modeling and core components work carried over from ebXML Phase One has come to fruition in Phase Two with the benefit of much iteration of revisions and comments. The modeling information required to enter and determine successful execution of a business collaboration or transaction, i.e., states of business entities, is benefiting from the CC library as a reference for conceptual information entities. Business entities are then elaborated in the model of "on-the-wire" business documents as normalized business information entities.

The UN/CEFACT e-business Architecture provides the umbrella specification that covers the work of all the UN/CEFACT e-business projects. As such, it elaborates on the Phase Two ebXML projects and shows how they relate to the other e-business activity in UN/CEFACT.

Future of ebXML: What's Required for Its Success?
As with any standard, success is measured by its acceptance and implementations based upon it. We're seeing both. To succeed we must complete the work and not get sidetracked by other activities that may seem like they are competing. Remember also that on the content and context side (UN/CEFACT's ebXML responsibility) there is no dependency on technology. In other words, it could be called ebWS (e-business Web services) since the business process and information specifications can sit on top of any infrastructure, not just ebXML's messaging service. This technology and protocol-neutral work will survive many different infrastructure solutions. However, for it to be accepted as such, implementers must have the vision and patience to complete the work. Rushing it will lead to failure since it takes extra time to develop a framework with future-proof details, i.e., not tied to any specific technology. The past has shown that it's simpler and quicker to develop proprietary solutions based on a single technology. However, as technology changes, technology-specific specifications become obsolete and implementers are forced to migrate to new solutions. UN/CEFACT's content and context work (BPIM and CC) promises that businesses won't have to translate their interactions (collaboration) as the infrastructure solutions progress over time.

ebXML and Web Services Standardization
Many deficiencies must be addressed in order to standardize Web services. From the ebXML perspective, Web services do not have the features required for e-business transactions; its standards only address the transport layer. However, ebXML provides the standards for interoperability at the business layer, making it the standard solution for Web business services.

As pointed out, there are some business-critical functionalities (collaboration, security, etc.) missing from the current narrow definition of Web services (SOAP, WSDL). Without this functionality, Web services won't be used for industrial-strength and mission-critical applications. Efforts are currently under way in organizations, consortiums, and standards bodies to fill these gaps with specifications that use the same language from and are aligned with the current Web services definition. Most of those efforts compete directly with various components of ebXML. It is perplexing that some organizations start new efforts such as WS-I immediately after having contributed to a similar effort in ebXML Phase One. WS-I's founding companies were key players in that phase, but instead of acknowledging that ebXML solved most of the problems, they're trying to readdress them, ignoring their own prior work.

Since the ebXML framework is a neutral technology, why not provide mappings from the ebXML specifications to Web services technologies? Why not use the ebXML content and context work as a standard way to define the business semantics in Web services to achieve interoperability at all layers?

The ebXML framework is the missing ingredient for Web services. The ebXML development effort could fail to seize this collaborative opportunity, and Web services vendors could "standardize" on one of their preferred proprietary solutions. However, if ebXML does grab this opportunity, its vision for a global economic exchange standard will be brightened indeed. Current Web services are just a stopgap measure. However, if the ebXML work can engage Web services initiatives in a tactical alliance, the broader UN/ CEFACT objective of Web resources as business entities engaged in collaborations will be realized. Remember, the XML implementation aspect of ebXML is just the next generation of EDI. The following generation (within five years?) will likely be different from both the current Web services and ebXML.

Published Jun. 19, 2002— Reads 14,890
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

About Klaus-Dieter Naujok
Chief Scientific Officer
IONA Technologies Inc.

As Chief Scientific Officer for IONA Technologies, Inc., Mr. Naujok is responsible for the companyís overall standardization efforts and technical leadership of its B2Bi direction, and leads IONA's involvement in OASIS and inclusion of ebXML technology within its Orbix E2A Web Services Integration Platform.
He works with customers and potential customers to gain insights into how IONAís products should evolve and heads up an advanced technology group that engages in early experimental developments to evaluate new concepts. Mr. Naujok was educated in Braunschweig, Germany, receiving a degree in Electrical Engineering from the Fach Hochschule (Technical University).

Mr. Naujok has held numerous leadership roles in the international standards arena for the past fourteen years. Most recently, he helped found and chair ebXML, a joint international initiative between UN/CEFACT (Center for Electronic Business and Trade) and OASIS. Currently he is the Chairman of UN/CEFACTís Techniques & Methodologies Working Group and eBusiness Transition Working Group (Phase 2 of ebXML). He is also a member of the UN/CEFACT Steering Group.