The ebXML Technology

The ebXML technology is based on a set of building blocks designed to meet common business requirements and conditions. The ebXML technical architecture makes use of existing standards wherever possible, building on the experience of EDI while taking advantage of the increased flexibility of XML and ubiquity of the Internet. Because the architecture is modular, industries or companies can choose to implement parts of the ebXML technology rather than trying to do everything all at once.

Messaging

Most companies interested in ebXML will probably start with the messaging functions that enable companies to send and receive business data in a standard envelope-and-message format. The ebXML messages use a specification called the Simple Object Access Protocol ( SOAP ). SOAP is an XML application that defines a message format with headers to indicate sender, receiver, routing, and security details. A recent enhancement to SOAP allows for the attachment of any digitized content, which enables ebXML messages to send engineering drawings or patient X-rays, as well as business data.

Business Processes

A basic feature of the ebXML architecture, and one that separates it from other XML frameworks, is its emphasis on business processes. The use of modeling languages and charting tools such as the Unified Modeling Language (UML) offer ways of systematically capturing the flow of business data among trading partners and representing this business knowledge in a standard format, down to a fine level of detail and independent of technical implementation. Business processes that are defined systematically can be used as the basis for defining common message sequences across industry boundaries, and offer a basis for achieving interoperability.

Trading Partner Profiles and Agreements

Another important feature of ebXML is the systematic representation of company capabilities to conduct e-business in what ebXML calls the collaboration protocol profile ( CPP ). With CPPs, companies can use a common XML format to list the industries, business processes, messages, and data-exchange technologies that they support. Companies then use CPPs to agree upon the business processes, messages, and technologies used to exchange business messages, in a collaboration protocol agreement ( CPA ), also an XML document. Companies still may need a trading partner agreement ( TPA ) to cover non-technical business or legal issues, but the CPA provides the technical features of the agreement in an automated form.

Registries and Repositories

The part of ebXML with which most companies will have contact early on are the registries, which contain the industry processes, messages, and vocabularies used to define the transactions exchanged with trading partners. Companies also will use ebXML registries to register the CPPs that list their e-business capabilities for inspection by potential trading partners, as well as search the registries for companies with the capabilities desired in trading partners. Registries index these items, but they're actually stored in corresponding repositories. Because these functions are critical for companies new to ebXML or those seeking to expand into new industries or find new trading partners, registries and repositories are considered the key to making ebXML work successfully.

Core Components

As well as business processes, ebXML relies on core components to provide interoperability among industries and business functions, but core components work at the individual data-element level. Core components identify the data items that businesses use most often and across industries, assigning them neutral names and unique identifiers. With core components, companies can relate data used in one industry to counterparts in another industry, or from an XML vocabulary to previously defined EDI transactions. Core components, as of the time of this writing, are still a work in progress. While the ebXML team responsible for core components has identified some of these key data items, much work still remains. However, the EDI standards bodies have agreed to relate their data dictionaries to the ebXML core components. Once completed, core components will have a welcome reception .

What ebXML Is Not

It's important to note the limitations of ebXML. This effort will produce a set of specifications for software and services ”but not the software and services themselves , which will be generated by technology vendors . Also, at least as of spring 2001, ebXML will not produce standard message formats, say for purchase orders or invoices.The ebXML specifications will provide the building blocks and infrastructure to write those messages, but the actual development of standard messages will generally fall to industry groups and standards bodies.