ebXML Architecture

Within the world of ebXML there are two views that describe a business interaction:

The first is the Business Operational View (BOV), which addresses the semantics of business data transactions, as well as information interchange. This view includes operational conventions, agreements, and obligations between partners; thus, it relates to how we deal with trading partners and trading communities in general.

The second is the Functional Service View (FSV), which addresses the supporting services and deployment needs of ebXML. There are three major phases associated with the FSV: implementation, discovery and deployment, and runtime (see Figure 12.3).

Figure 12.3. Functional Service View.

The implementation phase deals with the procedures for creating and executing applications within the ebXML infrastructures. For example, a trading partner wishing to engage in an ebXML-compliant transaction would first obtain copies of the ebXML Specifications. After that, the trading partner would move to understand these specifications, perhaps obtaining additional information such as the trading partners' process information (existing within their business profile) for analysis. In some instances, the trading partner can also submit its own process information to an ebXML-compliant Registry Service. After that, the discovery and deployment phase discovers ebXML-related resources and they are self-enabled into the ebXML infrastructure. Next is the run-time phase, where the execution of an ebXML process takes place.

FSV leverages information technology aspects of functional capabilities, service interfaces, and protocols. These protocols include the ability for implementation, discovery, deployment and runtime; user application interfaces; data transfer infrastructure interfaces; and protocols for XML interoperability.

Both BOV and FSV (which make up the ebXML architecture) leverage the ebXML Registry to provide distributed services for the sharing of information between trading partners, which allow each entity to find each other and create processes between them. The repository leverages an API to expose its services, thus making the registry accessible from Java and Web-based applications, for example.

Thus, we can conclude that the registry and repository (defined above) are coupled. The registry offers access to services, as well as the information model and reference system. In contrast, the repository provides the physical storage for ebXML. The notion is that all information about all trading partners is contained here and is accessible to any partner (if authorized) looking to create common processes and formats between them.