This is the fourth article in the ebXML series here at developer.com. The first 2 articles introduced the organizations and history behind ebXML. The last article introduced a typical ebXML transaction.
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 last month made 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:
- the organization's name and contact information;
- the transport and security protocols it recognizes;
- the messaging protocols it recognizes;
- the business processes (and therefore ultimately the XML schemas) that the organization recognizes;
- all kind of technical information such as URLs, time-out, certificates, and more that are necessary to setup an ebXML relationship.
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.
What's next
The next article will feature an interview with David Webber, chair of the CEFACT/OASIS Joint Marketing Team for 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.
IE 7
Firefox 2.0
