ebXML: Introducing the Vision
By Benoît Marchal

Original article at http://www.developer.com/xml/article.php/2204681

Electronic Business

Electronic business is an all-encompassing term. It could mean online shopping, electronic marketplaces, electronic banking or even emailing your business partners! What about marketing web site or eBay, isn't that electronic business?

Well, not for ebXML. ebXML concentrates mostly on so-called back-end operations, business-to-business transactions. ebXML is not so much concerned with the online store (business-to-consumer operations) but with what happens behind the storefront. ebXML aims to streamline buying, transporting, invoicing of the goods but it also covers all the legal fillings, the insurance, and more. Essentially any activity needed to fill the warehouse, ship the goods or keep the factory busy are relevant to ebXML.

One of the visible difference between business-to-business operations, in the context of ebXML, and more consumer-oriented activities is the role of human.

When shopping online, the shopper sits in front of its computer and clicks its way through. This is not necessarily the case for back-office operations. Indeed it is common for a business management system (SAP, Peoplesoft and the like) to re-order automatically when the stock reaches a certain level. Shipping, ordering, invoicing, and even payments can be largely automated. They may take place with little or even no human intervention.

ebXML aims to automate as much of the commercial and administrative operations as possible.

ebXML Ancestry

To compare ebXML with other standards, it is essential to understand its lineage. There are many technical similarities between ebXML, SOAP, the Semantic Web and Web Services. At time the similarities between those projects can be confusing unless you keep in mind who is in charge of what.

OASIS is the Organization for the Advancement of Structured Information Standards. It is an international consortium of vendors and users of markup languages. OASIS was formerly known as SGML Open (XML was derived from SGML) which reflects on its experience with markup languages.

The UN/CEFACT is the United Nations Center for Trade Facilitation and Electronic Business. I find the acronym confusing but it reflects the former name of UN/CEFACT (United Nations Centre for the Facilitation of Procedures & Practices for Administration, Commerce & Transport). Anyway the UN/CEFACT is an international body, supported by the United Nations, that aims to simplify international trade, notably through electronic means.

The UN/CEFACT is best known for the development of UN/EDIFACT, a legacy EDI standard. EDI, which stands for Electronic Data Interchange, is a set of standards to exchange of business and administrative information between business management systems. UN/EDIFACT was originally developed in the 1986.

ebXML Vision

In 1999, the two groups joined on the development of a next-generation standard for electronic business. OASIS brought the technical expertise with XML (and markup languages in general). The UN/CEFACT brought its experience in developing solutions for electronic business. The partner skills were largely complimentary.

For the next 18 months they worked to develop a complete solution for electronic business. If you visit the ebXML web site at www.ebxml.org, you will be surprised by the size of the effort. There are ebXML specifications covering technical infrastructure, business processes, registries, analysis, security, communication (transport) and more. The aim clearly is to offer a one-stop solution for every aspect of electronic business.

Bear its legacy in mind when you compare ebXML to other specifications, such as web services. Although, at time, it seems that ebXML overlaps with other specifications (for example, ebXML transport is based on SOAP, the registry mechanism is very similar to UDDI), ebXML is unique because of its special focus on business-to-business transactions.

ebXML Transaction

This article reviews a typical ebXML transaction. It helps illustrate the key benefits of ebXML.

Without

Figure 1 is an electronic business scenario without ebXML. ACME Manufacturing and one of its largest supplier, Coyote Industries, want to implement an electronic relationship. The goal is to streamline ACM procurement, reducing costs and increasing competitiveness.



Click here for larger image

Let's assume that business issues have been dealt with: ACME wants to buy from Coyote, they have agreed on terms and payments (otherwise there's little point in implementing an electronic relationship anyway).

ACME and Coyote add an XML connector to their business management system (such as SAP, Peoplesoft, Sage or QuickBooks). That should be easy, right? Wrong!

There are many technical issues to be dealt with: which XML schema to use, what security to put in place, how to chain electronic messages (e.g. does Coyote invoice ACME for every order or does it issue a monthly invoice), what communication protocols to adopt. There are also many parameters to get right: the address of the server, time-outs, and more.

Currently setting up an XML connector is a lengthy and costly business. It requires many back and forth, meetings/phone calls between trained professionals and, generally speaking, it's not very efficient.

With

Figure 2 is the ebXML equivalent of figure 1. The only difference, but it's a significant one, is that the slow, costly process of setting up the connector has been automated.

It starts (step 1) with ACME looking up Coyote information in a registry. A registry is an open directory where companies list a very detailed description of their electronic capabilities.

In ebXML lingo, the description is known as a CPP (Collaboration Protocol Profile). The CPP contains the answer to the questions discussed in the previous section: which XML schemas Coyote recognizes, the security mechanisms it has put in place, the address of its server and much more.

In a second step, ACME matches Coyote description with its own to find commonalities. In the process it creates a CPA (Collaborative Partner Agreement) that describes how to establish the electronic relationship. In essence, the CPA is the answer to all the questions put forward in the previous section.

How to build the CPA? In most cases, the choices are simple and can be automated. For example, if Coyote supports HTTPS or S/MIME but ACME supports S/MIME and PGP, the only practical option is S/MIME. Some issues might not be so clean cut and would be reviewed by the operator installing the software.

ACME sends the CPA to Coyote for validation. When Coyote accepts it (which again can be automated), they're in business.

Step 3 and beyond is to exploit the business relationship.

The dotted line between Coyote and the registry in figure 2 indicates that Coyote will update its CPP as it adds or removes capabilities. E.g. if Coyote adds PGP support, it needs to say so in its CPP.

A fundamental difference

The fundamental difference between the two scenarios is that, with ebXML, the costly configuration is now automatic which means cheaper and faster.

Although on a larger scale, ebXML proposal is not unlike plug-and-play. Not so long ago, you needed a professional to add a device to a PC. He or she had to know about BIOS, jumpers, IRQ, DMA, and more. Thanks to small profiles that ships with cards, the computer has now largely taken over and automatically choose the best settings.

Obviously there is another difference between the scenarios with and without ebXML. If you can establish electronic relationships in minutes instead of weeks, then you can afford to build many more of those.

An Introduction to the ebXML CPP
This article follows up on the typical transaction aspect by taking a closer look at business processes and the Collaboration Protocol Profile (CPP), two of the cornerstones of ebXML.

Building a framework

As the ebXML transaction example from above clear, the focus of ebXML is on building a framework that makes it possible to automate the creation and the configuration of electronic relationships. If you missed last month's article, I suggest you have a look now.

This special focus of ebXML is in sharp contrast with previous electronic business standards, such as ANSI X12 and UN/EDIFACT, that would concentrate on the electronic transaction itself and left the configuration as an exercise to the user. Unfortunately the exercise proved to be an expensive one.

To achieve its goal of simplifying the configuration of electronic relationships, ebXML focuses on describing transactions through business processes and on describing an organization capabilities through the CPP.

On the CPP

The CPP is a formal description file that lists what an organization can do in terms of ebXML operations. Formal is the operative word because it means that software can decode it. More specifically, the CPP contains:

Since the CPP describes all the capabilities of an organization, it tends to be a fairly long document (20 pages or more). The CPP is written in XML and follows very strict conventions.

Listing 1 is a tiny excerpt from Coyote's CPP (following on last month example). This excerpt deals with the transport protocols that an organization supports. It contains two tp:Transport elements to indicate that the organization accepts messages either via HTTP (web) or via SMTP.

Listing 1: an excerpt from a CPP 

<tp:Transport tp:transportId="http_connection">
  <tp:TransportReceiver>
    <tp:TransportProtocol tp:version="1.1">HTTP</tp:Protocol>
    <tp:Endpoint tp:uri="https://www.coyote.com/ebxml"
                 tp:type="allPurpose"/>
    <tp:TransportServerSecurity>
      <tp:TransportSecurityProtocol tp:version="3.0">SSL
          </tp:TransportSecurityProtocol>
      <tp:ServerCertificateRef tp:certId="server_cert"/>
      <tp:ClientSecurityDetailsRef tp:securityId="tp_security"/>
    </tp:TransportServerSecurity>
  </tp:TransportReceiver>
</tp:Transport>
<tp:Transport tp:transportId="smtp_connection">
  <tp:TransportReceiver>
    <tp:TransportProtocol>SMTP</tp:Protocol>
    <tp:Endpoint tp:uri="mailto:ebxml@coyote.com"
                 tp:type="allPurpose"/>
  </tp:TransportReceiver>
</tp:Transport>

The transport elements specify the protocol in use (tp:TransportProtocol), the address of the server (tp:Endpoint) and optionally security information (tp:TransportServerSecurity). In the above example, the HTTP connection is secured through SSL, the SMPT connection is not.

The virtues of a formal description

Every organization has a CPP. Coyote has one but its business partner, ACME Manufacturing also has one. To establish the electronic relationship between the two, it suffices to look up the commonalities in the two CPP. Software can very easily establish the match.

Suppose ACME's CPP states that ACME supports HTTP, then the software has found a match and it can configure itself for HTTP. Since the CPP contains the address of the server and the security parameter, the configuration requires no human intervention.

Thanks to this level of automation, Coyote and ACME are in business in minutes instead of days. Also the relationship was very cheap to setup.

For simplicity, the above example has concentrated on transport protocols because that's where you need the fewest parameters. Bear in mind that the CPP lists every possible option, including which XML schemas to use (through the business process). A complete CPP is a very long document.

Yes but...

One question that often arises at this point in the discussion is: it all sounds great but what the ACME's CPP is incompatible with Coyote. Say ACME supports FTP only. As we have seen, Coyote does not support FTP.

Should that happen, it means that two parties cannot establish an electronic relationship. At least one of the two must upgrade its system to make it compatible with the other.

Unfortunately software does not magically grow capabilities. That was true before ebXML and that very much remains true.

Still the benefits of ebXML remains. Look at this analogy: I recently upgraded to a new laptop. The old laptop connected to my mobile phone (and ultimately to the Internet) through an IrDA port. The new laptop has no such IrDA port. Not willing to loose Internet access, I bought a Bluetooth dongle for the laptop.

What matters is that, thanks to plug-and-play, the laptop was reconnected within minutes of receiving the Bluetooth package.

Likewise with ebXML. If ACME buys an HTTP package, it will only take minutes to establish the connection with Coyote.