ebXML Core Components

Contact    

  Welcome to the core components team site. The initial phase of ebXML is now complete and you can download the Core Component Technical Reports from this page. Comments regarding contents and layout of this site should be sent to the editor/web developer James Whittle.


What follows is an overview of the Core Components problem space, to read in more detail please download
this zipped file which contains all the Technical Reports.

Introduction

Business partners collaborate to do business with each other by linking their operational business processes. Business processes are linked by the exchange of business information, in agreed sequences and within agreed timeframes, between business partners.

The discovery of business processes builds a picture of requirements, identifying the sequence, timing and purpose of each exchange. Detailed examination of the business processes reveals the individual pieces of business information (entities) that need to be exchanged and at what stage.

The discovery activity is conducted within each industry sector by specialists within that sector. When the results of discovery are analysed across the different industries, a pattern of common process and common information component requirements can be detected.

The papers covered by this overview describe the activities of business information discovery and analysis, and describe the concepts of re-using common components to meet specific business needs.

Background

The objective of the ebXML Core Components Project Team is to define a process, by which information components can be discovered, catalogued in sufficient detail and analysed to identify which components are core components. The creation of such a catalogue will enable interoperability across industries that utilize electronic commerce.

To achieve this goal it is necessary to recognize that:

Many business processes are fundamental in that they are used in many, if not all, industries. Procurement, Payment, and Shipping are examples of common business processes.

In many cases, detailed business information requirements, for example those used when identifying a product, are the same, similar or analogous across industries.

Within the progression of a business process, for the same trading partners/trading community, there is again significant commonality in the information requirements. What is considered product, how it is identified and described, etc., remains consistent across the duration of that business process.

Overview

The business process determines characteristics of the business document payload. For example, if the business process is ordering then the order information must specify details about the order itself (payment, delivery, references to external business agreements, etc.). There are certain characteristics of the Order Document, which typically do not vary across industries, while other details (such as those required because of product type) will vary dramatically.

Business documents, by their very nature, communicate a semantically complete business thought: who, what, when, where and why. The what in electronic business terms is typically the product. It is widely recognized that products are goods or services. Goods are manufactured, shipped, stored, purchased, inspected, etc., by parties. Services are performed by parties, and may involve goods and/or parties. Parties can be either organizations or individuals, and can be associated with other parties, and products. And these products have events associated with them, inspections, transportation, building, sale, etc.

Within ebXML this problem is addressed in the Core Component architecture by a combination of structured information and the use of context. This structure uses a series of layers, designed to take into account commonality across industry business process. Further the structure is designed to support specialization based on the specific use of contexts. Context is the description of the environment within which use will occur. For example, if one was to say that "someone was pounding on my car with a hammer", the response is very different depending whether it is a repair shop or a neighbourhood youth. Context is what is used to direct interpretation.

Conceptual Picture of Core Components

A component is a 'building block' that contains pieces of business information, which go together because they are about a single concept. An example would be bank account identification, which consists of account number and account name.

Core components are components, which appear in many different circumstances of business information and in many different areas of business. A core component is a common or "general" building block that basically can be used across several business sectors. It is therefore context free.

Re-use is the term given to the use of common core components when they are used for a specific business purpose. The purpose is defined by the combination of contexts in which that business purpose exists. Each context specific re-use of a common component is catalogued under a new business information name 'that uses core component X'.

A domain component is specific to an individual industry area and is only used within that domain. It may be re-used by another domain if it is found to be appropriate and adequate for their use, and it then becomes a core or common component.

Components can be built together into aggregates.

As described above for components, aggregated components can be common components. These are generic and can be used across several business sectors. They can be re-used for a specific business purpose, defined by a combination of contexts. Each context specific re-use of a common aggregate component is catalogued under a new business informant name 'that uses core component X'.

There are also domain specific aggregated components.

Aggregates and components can be gathered into 'document parts'. These are useful assemblies which can individually satisfy a business process's requirement for information, or which may be 'sewn together' in a structured way to achieve the same. For example, the structured combination may be to satisfy a business process's need for information presented in a particular way for efficiency of processing.

An individual document part and the 'sewn together' parts, come at increasingly domain-specific and context-specific levels. They form documents or partial documents that satisfy a business process or a part of a business process.

This figure illustrates how core components can be built into business documents by explicitly linking components with the ebXML Business Process Worksheets, and the underlying modelling approach. The top right-hand corner of the figure comes from figure 8.4-1 in the Business Process Overview document.

Note that in this instance document parts are pieces of business information required to satisfy a particular business process, from a specific contextual viewpoint.