This is the second article in a series that discuss ebXML, a global standard for electronic business. This article reviews the main working groups within ebXML and how they relate to each other.
As I explained last month, ebXML is an all-encompassing initiative to develop a set of specification for electronic business. ebXML specifically focuses on the business-to-business (B2B) market. To appreciate the breadth of the initiative, one only needs to look at the working groups that developed and maintain the standard.
You will remember the ebXML is a joint initiative of OASIS (Organization for the Advancement of Structured Information Standards) and the UN/CEFACT (United Nations Center for Trade Facilitation and Electronic Business).
Depending on the nature of their work, the working groups are hosted either by OASIS or by the UN/CEFACT. OASIS is responsible for the technical infrastructure and XML-related matters. The more analytical work is done within the UN/CEFACT. This plays on the strengths of each organization: OASIS expertise in markup languages and the UN/CEFACT experience with UN/EDIFACT and EDI standards.
For completeness, I should add that throughout the initial development periods (from 1999 to 2001), the two organizations worked in parallels and held joint meetings.
The working groups are: Messaging Services; Registries and Repositories; Collaborative Protocol Profile; Implementation, Interoperability and Conformance; Core Components; Business Process Models and a Joint Marketing Team.
The marketing team is responsible for the promotion of ebXML. It organizes events and all forms of communication to raise awareness on the ebXML specifications. As the name implies, the Joint Marketing Team is common is not specific to any of the two organizations.
OASIS Working Groups
Business transactions may need a more robust channel than regular email or web surfing. For example it may be crucial to know whether an order has been delivered or not, e.g. because work would stop on a building site if the materials were not delivered on time. Also it is often desirable to sign or encrypt business documents electronically.
Within OASIS, the Messaging Service working group has developed extensions to SOAP, HTTP (for synchronous communication) and SMTP (for asynchronous communication) to enable robust, reliable and secure communication between sites.
The next issue that ebXML addresses is the distribution of business and technical information between partners. For two or more organizations to work together electronically, they have to communicate on a myriad of technical details that range from legal contracts to the actual names of their servers, it also includes XML schemas, cryptographic keys, banking details and much more.
If there’s only a handful of partners, it might be possible to exchange the technical information via email or (God-forbid) the good old fax. ebXML encourages the use of online repositories and registries instead.
For some reason, repositories and registries have achieved an almost mystical status. They need not be if you remember that they are merely a convenience to share technical and commercial information between business partners.
Web sites and search engines are a good analogy for repositories and registries respectively. To learn about another business, you might want to consult its web site. How to find the site? Through a search engine! Likewise an ebXML client will check the company repository for technical information. It would have found the repository through a registry.
The protocol between the ebXML clients and the ebXML Registries and Repositories is maintained by OASIS. OASIS also maintains a initial registry at xml.org.
One of the most important concepts in ebXML is the Collaborative Protocol Profile (CPP). Simply put, a CPP describes how a business implements ebXML.
Again, let’s use an analogy. Suppose you want to order a book. Do you have to go to the bookstore, can you phone your order, do you have to fax a confirmation? How to pay? Check, credit card? Can they mail the book to you? The answers define the bookstore profile.
In ebXML, the CPP lists the technical information needed to do business electronically. Which XML schemas to use, which email address, what is the public key, and more? OASIS maintains the XML schema for Collaborative Protocol Profile.
Finally a standard is only as good as its implementations. The implementation group lays down the groundwork for testing, interoperability tests, thereby assuring that ebXML competing solutions work together.
UN/CEFACT Working Groups
ebXML recognizes that different communities might have different needs. Therefore ebXML aims to build a framework for electronic business but it does not develop standard XML schemas for the familiar business documents, such as the invoice, the order, the bill of lading, the check and others.
Indeed it suffices to compare local invoices with international ones to appreciate the difficulty of defining standard versions of those documents. Differences in the legal environments mean that some fields will appear in one document, not in the other (e.g. European invoices mention a VAT number that is unknown in the US).
Still despite the differences, there are commonalities. All invoices include lines with product descriptions, product references and prices. The Core Component working group analyzes and document the commonalities.
Finally the Business Process Models working group goes one step further. It analyses the workflow of operations (when to send the order, what to respond, when to send the invoice, etc.). The working group provides modeling tools to analyze and describe those business process.
More to Come
In the next articles, we will study a typical ebXML transaction and review tools and implementations of ebXML.
Benoît Marchal is a Belgian developer. He is the author of XML by Example and other XML books. Benoît is available to help you with your projects.