Overview of the ebXML Architectures

As noted in the first article in this series, ebXML started its work program with the overall solution and its high level architecture already decided. The task of the Architecture project team was therefore not to develop the architecture from a set of requirements, but to describe the chosen architecture (based on what the other project teams were doing) and flesh out its details. They had quite a difficult time doing this, evidenced by the fact that the Technical Architecture Specification was approved in February 2001, very near to the May 2001 completion of the ebXML work program. One of the main difficulties in describing the ebXML architecture is that, in conventional software architecture terms, there is not one ebXML architecture but instead there are two. One of these is the architecture for the software comprising the technical infrastructure, often referred to as a product architecture. The other is the architecture for performing systems analysis and development, often referred to as a process architecture. The Architecture Specification somewhat alludes to this in its "Recommended Modeling Methodology" section when discussing the Business Operational View and Functional Service View (two concepts taken from the ISO Open-EDI Reference Model). However, it does not explicitly identify two separate architectures.

The latest academic thinking about software architectures holds that six attributes are required to fully describe an architecture. These are:

1. Elements (components/parts) from which systems are built
2. Interactions (connections/connectors/glues/relationships) between the elements
3. Patterns - The layout of the elements and their interactions, guiding their composition. For example, the number of elements, the number of connectors, order, topology, directionality
4. Constraints - On the patterns. For example, temporal, cardinality, concurrency, etc.
5. Styles - Abstraction of architectural components from various specific architectures (Sometimes used interchangeably with patterns). For example: Layered (as in Unix OS, OSI stack), pipe & filter, object oriented
6. Rationale - Describe why the particular architecture was chosen

The ebXML Architecture Specification does a fairly good job in defining the elements and interactions of the ebXML Architecture (although the picture is somewhat muddled by trying to describe the product and process architectures as a single architecture). It also offers fairly good rationale in several cases. However, it doesn't address patterns, constraints, or styles in any detail. The other technical specifications likewise give further detail on elements, interactions, and in some cases rationale, but also deal very little with patterns, constraints, and style. For that reason, I won't address those attributes either, but will limit the overview to elements and interactions. To keep this article fairly short, I also won't address rationale but direct the reader to the Architecture Specification and the other specifications. Let's look at the product architecture first, than the process architecture, then finally how they are related to each other.

Product Architecture

The technical infrastructure is composed of the following major elements:

• Messaging Service - This provides a standard way to exchange business messages between organizations. It provides for means to exchange a payload (which may or may not be an XML business document) reliably and securely. It also provides means to route a payload to the appropriate internal application once an organization has received it. The messaging service specification does not dictate any particular file transport mechanism (such as SMTP, HTTP, or FTP) or network for actually exchanging the data, but is instead protocol neutral.
• Registry - The registry is a database of items that support doing business electronically. Technically speaking, a registry stores information about items that actually reside in a repository. The two together can be thought of as a database. Items in the repository are created, updated, or deleted through requests made to the registry. The particular implementation of the registry/repository database is not specified, but only how other applications interact with the registry (registry services interfaces) and the minimum information model (the types of information that is stored about registry items) that the registry must support. Examples of items in the registry might be XML schemas of business documents, definitions of library components for business process modeling, and trading partner agreements. An original goal of the ebXML registry was to support a fully distributed, networked set of interacting registries that would provide transparent interaction to any ebXML compliant registry by interfacing with only one of them. Time ran out for this and instead only a single registry is specified. A supplemental report offers a way to locate ebXML registries using UDDI.
• Trading Partner Information - The Collaboration Protocol Profile (or CPP) provides the definition (DTD and W3C XML schema) of an XML document that specifies the details of how an organization is able to conduct business electronically. It specifies such items as how to locate contact and other information about the organization, the types of network and file transport protocols it uses, network addresses, security implementations, and how it does business (a reference to a Business Process Specification). The Collaboration Protocol Agreement (or CPA) specifies the details of how two organizations have agreed to conduct business electronically. It is formed by combining the CPPs of the two organizations. A CPA can be used by a software application to configure the technical details of conducting business electronically with another organization. The CPA/CPP specification discusses the general tasks and issues in creating a CPA from two CPPs. However, for various reasons (which are discussed) it doesn't specify an actual algorithm for doing it.
• Business Process Specification Schema (BPSS) - The Specification Schema provides the definition (in the form of an XML DTD) of an XML document that describes how an organization conducts its business. While the CPA/CPP deals with the technical aspects of how to conduct business electronically, the Specification Schema deals with the actual business process. It identifies such things as the overall business process, the roles, transactions, identification of the business documents used (the DTDs or schemas), document flow, legal aspects, security aspects, business level acknowledgments, and status. A Specification Schema can be used by a software application to configure the business details of conducting business electronically with another organization.

The ebXML infrastructure is modular and with few exceptions these infrastructure components may be used somewhat independently. They are therefore only loosely related. The elements of the infrastructure may interact with each other, but in most cases are not required to. The messaging services may be used completely independently, although a message header may contain a reference to a CPA. The CPA and CPP provide means to identify a Business Process Specification governing how the parties do business and parameters for using the ebXML messaging service, but these are both optional and are not required. The Business Process Specification may specify how services offered by the messaging service (such as signaling acknowledgments or requesting digital signatures) are used in the conduct of a business process, but these also are not required. The CPP, CPA, and Business Process Specifications may be stored in an ebXML compliant registry, but this is not required. An ebXML compliant Registry may store any type of object, including non-XML objects. However, all communications with the registry must use the ebXML messaging service.

Process Architecture

The ebXML process architecture is based on UN/CEFACT's Unified Modeling Methodology (UMM) and it's Meta Model. UMM prescribes a specific way to perform business process and information modeling for electronic commerce using Unified Modeling Language (UML). The Meta Model specifies all of the items that must be produced from the analysis and describes their relationships. The Business Process Specification Schema, described in the product architecture, represents a subset of the information in the meta model. Ideally, it might be developed by going through the full UMM process. However, ebXML developed worksheets that enable analysts and perhaps even non-technical business people to document the information necessary for the BPSS without needing to follow the UMM. In addition, ebXML developed several other contributions related to analysis. The major ones are listed here.

• Business Process Analysis Worksheet & Guidelines - A set of worksheets and guidelines for using them, designed to assist an analyst in gathering the data necessary to describe a business process. The information can then be used to create a BPSS XML document describing the business process. The worksheets can be used as a basis for developing Business Process Editors that can guide the user in collecting the information and automatically generate the XML business process specification.
• Catalog of Common Business Processes - Preliminary cross-listing and description of business processes which may be common to several industries
• E-Commerce Patterns - Examples and descriptions of common business patterns. The only one listed to date is for simple contract formation. NOTE: This is one of the only areas where ebXML addressed patterns.
• Core Components - These are intended to be the basic information elements used in business messages. They are similar to what are referred to as "common business objects" in some methodologies. However, they provide an additional aspect, termed context, that recognizes that different elements (such as party or part), may be composed of different types of information in different industries, geographies, or even specific companies. The major parts of the core components work are:
  • Methodology - Methodologies for discovering core components from existing business documents or new business processes, analyzing them for harmonization and re-use, and extending core components into domain components for use in specific industries and situations.
  • Naming Conventions - Description of the parts of a core component name, based on ISO 11179, and rules for developing the names.
  • Catalog of Core Components - An initial catalog of core components that may be used "as is" or extended to build definitions of business messages.
  • Catalog of Context Drivers - An initial catalog of the types of information describing the contexts in which core components may be extended. These include such things as geographic region, industry, role, and product.

The relationships between the business process components should be fairly obvious from these descriptions. The analysis worksheets draw on the catalog of common business processes and e-commerce patterns to develop a specification document that covers the essential set of data specified by the UMM meta model. The relationships of the core component specifications to each other are similar. However, the relationship between the BP work and the Core Components work is not so well developed. The only link is a mention that business documents exchanged as part of a business process are composed of "business information objects" that are themselves composed of other business information objects, domain components, or core components. Left unspecified in any great detail is exactly how context and core component extension relate to the top down business process analysis methodology of UMM. Even though a section of the BP Overview Technical Report deals with the relationship, it is still unclear. Specifically, it is unclear how a business information object differs from a core or domain component, since aggregate core and domain components, like business information objects, may also be composed of other core or domain components. The BP work seems inconsistent with the CC work on this point. The BP Overview also has an interesting statement that "The role of Context with respect to business process models has not been formally addressed by ebXML as it is out of scope for the ebXML effort." This raises more questions than it answers. I trust that these are areas that will be worked out as the BP and CC work are further developed by UN/CEFACT.

Similar to the modular nature of the technical infrastructure, the parts of the process architecture may be used independently. It is quite possible to develop XML schemas for business documents in a bottom up fashion strictly from core and domain components without doing any formal business process analysis. Conversely, it is also quite possible to generate XML document schemas from UML business process models using invented business information objects or objects from a source other than ebXML Core Components.

The Interactions between Product and Process Architectures

It should be apparent from the descriptions here that there is only one strong link between the process architecture and the product architecture. That link is the Business Process Specification Schema, which is a machine interpretable encoding of a business process. It is compliant with the UMM meta model, but does not necessarily need to be developed using the full UMM process. Instead, as noted above, it can be generated from a business process editor that implements the Business Process Analysis Worksheets. It is true that schema documents, core component descriptions, CPPs, and other such ebXML things may be hosted by an ebXML registry, but the ebXML registry was designed to host anything that can be encoded in a binary form and has little direct knowledge of ebXML artifacts.

Now that you have an overall understanding of what ebXML is, we have a foundation for taking a critical look at it. The next article will review how well ebXML achieved its primary goal of enabling interoperability.

July 19, 2001

© Michael C. Rawlins

About  |  Services  |  Resources  |  Contact

©Rawlins EC Consulting 2007