- Enter ebXML
- ebXML Scenarios
- Technical Architecture
- For Further Information
Technical Architecture
The ebXML architecture is made up of several modular components, each of which is defined by a specific technical subcommittee and described individually in one or more technical specification documents. Each of these components is described in this section.
Business Processes
Business Processes are the fundamental activities of an organization. Examples of Business Processes are the purchase of goods or services, shipment of goods, bill payment, and contract negotiation. Organizations wishing to implement ebXML may define their own Business Processes, or use existing ones found in ebXML registries. Business Processes may be formally defined using a Business Process Specification Schema (BPSS) that may be expressed in Unified Modeling Language (UML) and as an XML document. A Business Process may involve one or more business documents, such as a purchase order or shipping notice, which will be exchanged as XML. The BPSS describes not just the structure of the XML business documents themselves, but also the roles of the organizations involved, the process flow between the trading partners, and other aspects of the transaction.
Core Components
Core Components are reusable building blocks that are used in Business Processes. They are generic data elements that are useful in a variety of scenarios, industries, business activities, or functional areas. Examples include Credit Card Expiration Date, Currency Code, Financial Account Identifier, and Person Middle Name. A Core Component might also be an aggregate information entity such as Financial Account Details, which consist of an account identifier, name, and a currency. ebXML specifies a library of Core Components that can be used as-is, or adapted to be used in a specific context (such as a specific industry or Business Process).
Collaboration Protocols
Collaboration Protocol Profiles (CPP) define both the functional and technical capabilities of an ebXML-enabled organization. On the functional side, it describes which Business Processes the organization is capable of participating in. On the technical side, it describes the security, network addresses, file transport protocol, and other parameters necessary to exchange messages. After two companies decide to exchange information using ebXML, a Collaboration Protocol Agreement (CPA) is drawn up, which spells out the business relationship, describing which Business Processes and technical protocols will be used.
Registry
An ebXML Registry stores the available Business Processes and Collaboration Profiles of various ebXML-enabled organizations. Having this information registered centrally allows companies to locate potential trading partners that provide the products or services they need, and that have a compatible ebXML implementation. A Registry of Business Processes is also beneficial in that it promotes sharing and reuse of common components. This reduces implementation time and increases interoperability. A Registry might be accessible publicly on the Web, or restricted to a group of trading partners. It is important to note that the Registry is used at "design-time," when defining Business Processes and collaboration profiles. It is not involved during the actual exchange of business documents.
Messaging
The messaging component of ebXML allows messages to be transmitted with security and reliability in a standard way. The ebXML messaging architecture specifically addresses topics such as notification, non-repudiation, security, and encryption. It is based on SOAP, and it is independent of any transport protocol such as HTTP or FTP.
Status of ebXML
Since the initial ebXML specifications were released in May, work continues on refining them. The ongoing ebXML work is split between OASIS and UN/CEFACT. OASIS has formed several technical subcommittees that address the Messaging, Collaboration Profile, and Registry components of ebXML. UN/CEFACT has taken over work on the Business Process and Core Components specifications, as part of its ebTWG (e-Business Technical Working Group).
In addition, a number of vendors are building software that complies with ebXML. So far, most of these implementations have been experimental at best, but they are maturing and multiplying gradually.