Next: 3.3 ebXML Registry/Repository
Up: 3 ebXML
Previous: 3.1 ebXML by example
  Contents
The goal of ebXML is to provide a framework to enable the vision of a global electronic marketplace.
ebXML relies on business processes. ebXML provides the framework which allows companies to register and to discover potential trading partners. Companies describe their business processes in a defined manner and register the resulting XML documents at the registry. The business processes display the public interface of the given company. The ebXML framework provides a mechanism to match companies with the same business processes. Once two companies are matched they know already the business processes they can follow.
As the name implies the message flow between the ebXML registry and any companies which are XML based (see 2.8.2 for more info on XML). Further are business processes, business documents, business partners, core components etc all implemented in XML.
An important goal of ebXML is to enable Small to Medium Enterprises (SME) to do electronic business and to be part of the global electronic marketplace.
Picture 2 shows ebXML in action. The example is taken from the technical architecture specification [14].
Figure 2:
ebXML Overview (Adapted from the ebXML Technical Architecture specification
|
|
The example shows how two companies involved in ebXML find each other and start electronic business.
- Company A finds out about the electronic business opportunities based on ebXML. Company A browses the registry to see what is already available in the registry. Among the most important information available will be the industry wide common business processes. ebXML promotes the ideas of reusing predefined business processes. Company A will most likely find their core business processes defined in the repository. In the case of missing common business processes the company can define new ebXML business processes according to the ebXML Business Process Specification Schema [7] and the Business Process Analysis Worksheets & Guidelines [5]. Section 3.4 goes into more detail of the ebXML business process aspects. The best case for company A would be, if all the business processes of its industry are already stored in the ebXML Registry/Repository and company A just reuses the necessary business processes.
- So company A decides to do electronic business the ebXML way and considers implementing a local ebXML compliant application called the Business Service Interface (BSI). In this case the company has to define itself in an ebXML compliant way. This means the company has to create a Collaboration Protocol Profile (CPP, the business profile). Basically a document which represents the supported business process capabilities, constraints and technical ebXML information of company A.
- Company A submits its CPP to the registry. From that point on, company A is publicly listed in the repository and is likely to be discovered by other companies looking for new trading partners.
- Company B is looking for new trading partners. Company B is already registered at the ebXML registry/repository. It starts a new query and receives the CPP of company A. Company B has then two CPP's: Company A's CPP and company B's CPP. ebXML then derives a third document from the intersection of the two CPP's called Collaboration Protocol Agreement (CPA).
- Company B contacts company A directly and sends the newly created CPA for acceptance to company A. Upon agreement of the CPA by company A both companies are ready for electronic business.
- Company B and company A then do electronic business directly according to the CPA. This means that both companies follow the business processes defined in the CPA.
This short example shows some important individual parts of ebXML, which will be described in the further chapters.
In ebXML there are three different functional phases.
- The implementation phase
As mentioned in the example the ebXML registry/repository has to be filled with common business processes. Industries, organisations and companies have to come together and to define (or convert from older business process projects like EDI) the common business processes. A business process has many different business documents and those documents have fields like date, place, name, street, quality, quantity etc. All those data has to be defined and converted to XML documents to be stored in the ebXML repository. When, the business process are defined then companies can reuse those business processes. A bottom-up approach is possible as well as a top-down approach. At the bottom we have the smallest entities. Probably integers, booleans, strings and the kind. A level higher we already might have date, time, street, etc. The next level could be address which reuses street, zip, country etc. All the way up elements reference other elements and at the top we get the CPA's.
- The discovery and retrieval phase
After the first phase the repository will have a number of companies and new companies will start to query the repository and most likely find matching CPP's.
- The run time phase
After the second phase and the derivation of Collaboration Protocol Agreements the involved companies can finally engage in electronic business in a defined way according to the CPA. The idea of ebXML is that the Business Service Interface gets configured with a Collaboration Protocol Agreement.
The main parts of the ebXML architecture are the ebXML Registry/Repository, the ebXML Business Processes, the ebXML Collaboration Protocol Profiles and Collaboration Protocol Agreements, the ebXML Core Components and the ebXML Messaging Service. The following chapters are based on the specifications of ebXML and they are regarded as an introduction and overview of the different major parts of ebXML. The content might not be deep enough for implementors. It is highly suggested to study the specifications instead.
Next: 3.3 ebXML Registry/Repository
Up: 3 ebXML
Previous: 3.1 ebXML by example
  Contents
author: Sacha Schlegel