About ebXML

Electronic Data Interchange (EDI) has given companies the ability to eliminate paper documents, reduce costs, and improve efficiency by exchanging business information with Trading Partners in electronic form. However, in the last few years, the Extensible Markup Language (XML) has rapidly become a first choice for defining data interchange formats for new eBusiness applications on the Internet.

EDI implementations represent substantial investments in encoding B2B Protocols (B2B Protocols). Companies with a large stake in EDI integration do not want to abandon EDI, for obvious cost reasons.

XML does enable more open, flexible business transactions than EDI, and XML might also allow more flexible and innovative business models. But there are still challenges in standardizing the semantics of message design and creating uniform B2B Protocol requirements. These problems are independent of the syntax in which messages are encoded.

ebXML specifications provide a framework in which EDI’s investments in business processes (B2B Protocols in ebXML Protocol Manager) can be preserved in an architecture that also maintains and extends XML’s technical capabilities.

For more information on ebXML, including the Requirements Specifications, see the following Web site:

http://www.ebxml.org

For more information on the Extensible Markup Language (XML), see the following Web site:

http://www.xml.com/

ebXML Overview

This model provides an example of the operations that may be required to configure and deploy ebXML applications and related components. These components can be implemented after initial system deployment, as needed.

Of course, there are more ebXML specifications than are shown in this simplified diagram. This model only provides a basic introduction to essential ebXML concepts. The numbers in the diagram call out steps in the process described under the next section.

Description of Model

The model operates as follows:

1. Company A has become aware of an ebXML registry accessible on the Internet.

2. Company A, after reviewing the contents of ebXML registry, decides to build and deploy its own ebXML-compliant application.

   Custom software development is not a necessary prerequisite for ebXML participation. ebXML-compliant applications and components that provide necessary solutions are commercially available and easily found.

3. Company A then submits its own business profile information (including implementation details and reference links) to ebXML registry.

   The business profile submitted to ebXML registry describes the company’s ebXML capabilities and constraints, as well as its supported business scenarios. These business scenarios are XML versions of the B2B Protocols and associated information bundles (for example, a sales tax calculation) in which the company is able to engage. After receiving verification that the format and usage of a business scenario is correct, ebXML registry sends an acknowledgment to Company A.

4. After additional communication is established, Company B accesses, in ebXML registry, the business scenarios supported by Company A.

   If they decide they want to, Company B sends a request to Company A stating they want to engage in a business scenario using ebXML. Company B acquires the necessary ebXML-compliant applications in the same way as Company A.

5. Before starting the scenario, Company B submits a proposed business arrangement directly to Company A’s ebXML-compliant software interface. The proposed business arrangement outlines the mutually agreed-upon business scenarios and specific agreements.

   The business arrangement also contains information pertaining to the messaging requirements for transactions to take place, contingency plans, and security-related requirements. Company A then accepts the business agreement.

6. Company A and B are now ready to engage in eBusiness transactions using ebXML.

Advantages of ebXML

As you can tell from this simple model, ebXML specifications provide the following advantages:

• Standardized way of describing B2B Protocols and their associated information models

• Registration and storing B2B Protocol and Information Meta Models so they can later be shared and reused

• Discovery and sharing of information about each participant including:

  • Supported B2B Protocols

  • Business service interfaces offered in support of each B2B Protocol

  • Business messages exchanged between their respective business service interfaces

  • Technical configuration of any supported transport, security, and encoding protocols

  Way to register the previously described information for later access and retrieval

• Way to describe the execution of mutually agreed-upon business arrangements derived from information provided by each participant from the discovery of information; these arrangements are called Collaboration Protocol Agreements (CPAs)

• Standardized business messaging service framework enabling interoperable, secure, and reliable exchanges of messages between Trading Partners

• Reliable way for configuring the respective messaging services to engage in agreed-upon B2B Protocols, in accordance with constraints defined in any predefined business arrangement

Design Conventions for ebXML Specifications

To ensure consistent capitalization and naming conventions across all ebXML specifications, use the Upper Camel Case (UCC) and Lower Camel Case (LCC) capitalization styles.

These styles employ the following conventions:

• UCC style capitalizes the first character of each word and compounds the name.

• LCC style capitalizes the first character of each word except the first word.

When you are producing ebXML documents that follow DTD, XML Schema, and XML instance conventions, use the following rules:

• Element names are in the UCC convention, for example:

  <UpperCamelCaseElement/>

• Attribute names are in the LCC convention, for example:

  <UpperCamelCaseElement lowerCamelCaseAttribute="Item"/>

When you use UML and Object Constrained Language (OCL) to specify ebXML naming capitalization, observe the following rules:

• For Class, Interface, Association, Package, State, Use Case, and Actor names, use the UCC convention, for example, ClassificationNode, Active, or InsertOrder.

• For Attribute, Operation, Role, Stereotype, Instance, Event, and Action names, use the LCC convention, for example, name, notifySender, or orderArrived.

General rules for all names are:

• Avoid acronyms, but in cases where you have to use them, keep the capitalization, for example, XMLSignature.

• Do not use underscores ( _ ), periods ( . ), or dashes ( - ). For example, instead of using title.document, stock_sale_6, or dollar-value, use TitleDocument, stockSale6, and DollarValue.