The ebXML Messaging Service
by Pim van der Eijk | Pages: 1, 2

Let's walk through the structure of a specific message, sent on 23 January 2003 from a prototype ebMS implementation developed by Seeburger, one of the participants in a European ebXML interoperability pilot project. This message corresponds to test case 101 from the test set defined for this project. The full message includes three payload documents: a small XML document, a 20 MB EDIFACT message, and a 14 MB PDF file.

The following listing shows the first part of the MIME container, which contains a <SOAP:Envelope> element with ebXML extensions. We've omitted the content of the <SOAP:Header> and <SOAP:Body> elements for clarity; we'll get back to them shortly. We've also omitted all MIME content after the content separator for the first payload element.

This listing has been wrapped for readability. The original listing is available here: listing1.txt

SOAPAction: "ebXML"
Content-Type: multipart/related; type="text/xml"; 
boundary="--20030121-144231102-0017----"; start="ebXMLHeader"

----20030121-144231102-0017----
Content-Type: text/xml
Content-Transfer-Encoding: 7bit
Content-ID: ebXMLHeader
Content-Length: 2757

<SOAP:Envelope xmlns:xlink="http://www.w3.org/1999/xlink" 
   xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd">
   <SOAP:Header xmlns:eb="http://www.oasis-open.org/committees/
ebxml-msg/schema/msg-header-2_0.xsd" 
     xsi:schemaLocation="http://www.oasis-open.org/committees/
ebxml-msg/schema/msg-header-2_0.xsd http://www.oasis-open.org/
committees/ebxml-msg/schema/msg-header-2_0.xsd">
      <!-- ... SOAP header content, see below ... -->
   </SOAP:Header>
   <SOAP:Body xmlns:eb="http://www.oasis-open.org/committees/
ebxml-msg/schema/msg-header-2_0.xsd" 
     xsi:schemaLocation="http://www.oasis-open.org/committees/
ebxml-msg/schema/msg-header-2_0.xsd http://www.oasis-open.org/
committees/ebxml-msg/schema/msg-header-2_0.xsd">
      <!-- ... SOAP body content, also see below ... -->
   </SOAP:Body>
</SOAP:Envelope>

----20030121-144231102-0017----

The <SOAP:Header> element must contain an <eb:MessageHeader> element that provides the main routing information. The <eb:MessageHeader> has subelements which identify the message's sender (<eb:From>) and recipient (<eb:To>). ebXML does not define its own party identification scheme; it's designed to leverage identification schemes such as EAN.UCC Global Location Numbers, which provides a unique, unambiguous, and efficient identification of locations. The following examples uses a simple, ad hoc identification scheme.

Listing wrapped for readability, original: listing2.txt.

<SOAP:Header 
   xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/
schema/msg-header-2_0.xsd" 
   xsi:schemaLocation="http://www.oasis-open.org/committees/
ebxml-msg/schema/msg-header-2_0.xsd 
     http://www.oasis-open.org/committees/ebxml-msg/schema/
msg-header-2_0.xsd">
   <eb:MessageHeader eb:id="messageHeader" eb:version="2.0" 
      SOAP:mustUnderstand="1">
      <eb:From>
         <eb:PartyId>http://ebxml.seeburger.de:80/ebXMLMSH?async?
response</eb:PartyId>
         <eb:PartyId eb:type="name">SEEBURGER AG, Christopher 
           Frank (c.frank@seeburger.de)</eb:PartyId>
         <eb:Role>Requestor</eb:Role>
      </eb:From>
      <eb:To>
         <!-- eb:PartyID omitted, similar to preceding eb:From -->
         <eb:Role>Responder</eb:Role>
      </eb:To>
      <!-- continuation follows ... -->

The optional <eb:Role> element identifies the role of the sender and participant in an <eb:Action> invoked on a <eb:Service>. In ebXML, the semantics of this service and action can be defined in a Collaboration Protocol Agreement (CPA), which sender and recipient and have agreed to and which is identified here in the <eb:CPAId> element. CPAs are XML documents defined in a separate ebXML-related OASIS Standard, Collaboration Protocols and Agreements. A CPA in turn references a separate business process specification document (expressed in a Business Process Specification Schema) that provides partner-independent descriptions of e-business collaborations.

We don't need to understand these other ebXML specifications here: the test service of the receiving ebXML message handler (urn:services:ipp:tcipp101) is instructed to return a message containing exact copies of the payload documents contained in this message (Reflector). That reply message will have the same <eb:ConversationId> and can use the value 20030121-144230993-0016 in a <eb:RefToMessageId> element to allow the original sender to correlate request and response.

      <!-- continued from preceding ... -->
      <eb:CPAId>cpa_00</eb:CPAId>
      <eb:ConversationId>cpa_00-20030121-144230993-0015</eb:ConversationId>
      <eb:Service>urn:services:ipp:tcipp101</eb:Service>
      <eb:Action>Reflector</eb:Action>
      <eb:MessageData>
         <eb:MessageId>20030121-144230993-0016</eb:MessageId>
         <eb:Timestamp>2003-01-21T13:42:30</eb:Timestamp>
         <eb:TimeToLive>2003-01-26T13:42:30</eb:TimeToLive>
      </eb:MessageData>
      <eb:Description xml:lang="en-US">Initial ebXML message for 
	     initialization of Test Step 1 in IPP Test Case TCIPP101.</eb:Description>
   </eb:MessageHeader>
</SOAP:Header>

The <SOAP:Body> element contains <eb:Manifest> elements which reference MIME parts attached to the ebXML message or data elsewhere on the Web. In this case, there are three payload documents.

Listing wrapped for readability, original available as listing3.txt.

<eb:Manifest eb:id="manifest" eb:version="2.0">
   <eb:Reference eb:id="pl-0000" xlink:type="simple" 
      xlink:href="cid:mspld_00.xml">
      <eb:Description xml:lang="en-US">Simple 
        small XML file.</eb:Description>
   </eb:Reference>
   <eb:Reference eb:id="pl-0001" xlink:type="simple" 
      xlink:href="cid:mspld_02.edifact_ORDERS_UN_D93A_small">
      <eb:Description xml:lang="en-US">Large EDIFACT 
        file (20MB).</eb:Description>
   </eb:Reference>
   <eb:Reference eb:id="pl-0002" xlink:type="simple" 
      xlink:href="cid:mspld_03.pdf_papiNetVR200_small">
      <eb:Description xml:lang="en-US">Large binary 
        file (15MB)</eb:Description>
   </eb:Reference>
</eb:Manifest>

The following shows the very first part of the second one, with id <mspld_02.edifact_ORDERS_UN_D93A_small>, referenced from the <eb:Reference> element in the <eb:Manifest> that has the eb:id attribute set to the value pl-0001. This payload component is a fragment of a very large EDIFACT message.

Listing wrapped for readability, original available as listing4.txt.

----20030121-144231102-0017----
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-ID: <mspld_02.edifact_ORDERS_UN_D93A_small>
Content-Length: 368

UNB+UNOA:2+ABSENDER9012345678901234567890ABCDE:CD-A:
WEITERLEITNG-A+EMPFAENGER:CD-E:WEITERLEITNG-E+940812:
0235+T940812023504A++0026-Anwendung'
UNH+M940812023504A+ORDERS:D:93A:UN:EAN007'
BGM+220+5211229'
DTM+002:940815'
NAD+SU+4004353000000::9'
NAD+BY+4306517005214::9'
LIN+1++4004353054099:EN'
QTY+21:9'
UNS+S'
UNT+51+M940812023504A'
UNZ+3+T940812023504A'

This example shows how ebMS builds on SOAP with Attachments to transport arbitrary data between two ebXML Message Service handlers. It also shows how additional ebXML-related business information is encoded, allowing message associations, ongoing conversations, business partner agreements, and business process definitions. And yet ebMS is a self-contained specification that can be deployed without an additional ebXML infrastructure.

Security

One of the areas in which ebMS extends SOAP is security. The ebMS specification distinguishes nine different security features. Implementations of ebMS are required to implement one of these, persistent digital signatures, to provide non-repudiation of origin. The precise configuration of these features is partner-dependent and can be agreed between partners in a CPA or otherwise. These signatures are to be applied to the message by the sending message service handler and are constructed using a separate specification, the XML-Signature Sytax and Processing specification. This specification defines a <Signature> element that can be added to the <SOAP:Header>. The use of XML Digital Signatures in the ebXML messaging specification is similar to the use in the more recent draft Web Services Security (WSS) specification. As this has also recently been discussed at XML.com (by Rich Salz, again!), we will limit ourselves to pinpointing some differences:

• WSS only allows one <Signature>. EbMS allows multiple <Signature> elements and specifies that the first of these represents the digital signature as signed by the From Party MSH. However, it does not define the purpose of any other signatures.
• In WSS, the signature is applied to the <SOAP:Body>. The ebMS specification describes a way to sign the complete <SOAP:Envelope> and any relevant attached business documents, omitting the Signature element from the <SOAP:Header> and any information not intended for the final recipient but only for intermediate nodes.

All security features other than persistent digital signing by the sending MSH depend upon specifications that were still under development at the time of ebMS's completion. Thus, interoperability between parties using these features is not guaranteed. The specification describes the following security features.

• Non repudiation of receipt can be expressed by returning an acknowledgment message signed using the certificate of the recipient.
• XML encryption can be used to provide persistent confidentiality of payload containers and/or the SOAP header.
• Persistent authorization could leverage the Security Assertion Markup Language (SAML), recently adopted as an OASIS Open Standard.
• A secure network protocol like TLS (SSL) can be used to provide non-persistent authentication, confidentiality, and authorization.

Reliability

Reliability is a key ebMS extension of SOAP. The reliability module of ebMS is designed to guarantee a sending service handler can deliver a specific message once and only once to a recipient message service handler. The reliable messaging module consists of a number of extensions to the SOAP message format and a reliable messaging protocol that specifies behavior of ebMS handlers.

At the message format level, ebMS defines an optional <eb:AckRequested> extension element for the <SOAP:Header>. If specified, the responding message handler can send a message containing another <eb:Acknowledgment> extension element, with an <eb:RefToMessageId> element to specify which message is being acknowledged. The reliability module interacts with the security module: the eb:AckRequested has a signed attribute that can request the responding message handler to sign the acknowledgment digitally in order to provide non-repudiation of receipt.

The Reliable Messaging Protocol specifies a mechanism for resending lost messages or lost acknowledgments. The maximum number of times, or the maximum time interval, for resending these messages or acknowledgments may be configured differently for different business partners. The Collaboration Protocols and Agreements specification that accompanies ebMS provides a standard way to encode this type of message service configuration information rigorously.

Reliable messaging requires a message service handler to detect duplicate messages. For example, a sender may resend a message that has been delivered to a recipient and for which an acknowledgment message has been created and returned but not yet delivered to the original sender. Duplicate message elimination and the requirement of resilience to system failure generally require ebMS handlers to maintain persistent copies of sent messages.

Interoperability of ebMS Implementations

Before the ebXML messaging service, those of us who needed secure and reliable exchange of XML-based messages over the public Internet or an Intranet had few alternatives to message queuingsoftware. Although the Java Messaging Service (JMS) offers a standard programming interface to message queuing products, the message formats and wire protocols used by these products are proprietary, requiring sender and recipient to use implementations from the same vendor or to use JMS-to-JMS bridges. One promise of the ebXML Messaging Service is to provide some of the benefits of message queuing products, while offering users a choice of ebMS implementations, provided by different vendors, including open source implementations. Thus, the interoperability of those implementations needs to be verified. There are currently several ongoing projects addressing this topic. We will mention four of them here.

The OASIS Implementation, Interoperability and Conformance TC addresses the requirements for ebXML interoperability, with an initial practical focus on ebMS. The committee is chartered to provide a conformance plan, a set of reference implementation guidelines, a set of base line interoperability tests, and guidelines and direction for third-party creation of conformance laboratories. Many participants in this TC are also active in other interoperability projects. One of the deliverables of this TC is a test framework that allows automation of interoperability testing of ebMS implementations. The ebXML IIC is currently finalizing its Basic Interoperability test suite, which aims at bringing together the various ebMS interoperability test initiatives, thus providing a common interoperability platform. The IIC has also developed the concept of a Deployment Template, first developed for ebXML Messaging. This is an important tool in defining interoperability at the business or usage level. It has been used by EAN-UCC to specify its deployment and implementation guidelines (which include the use of GLN mentioned earlier) in a more systematic way, which is easier to map to ebMS requirements, for users and vendors.

The Drummond Group has been conducting a series of ebMS interoperability tests sponsored by the Uniform Code Council. The most recent series was recently concluded and involved ebMS implementations provided by bTrade, CDC, Cyclone Commerce, eXcelon, Fujitsu, GXS, IPNet Solutions, Sun Microsystems, Sybase, Sterling Commerce, Tibco, and XML Global.

The European ebXML Interoperability Pilot Project is an ongoing joint project of CEN ISSS and OASIS. The project tested the interoperability of ebMS implementations developed by some participants and developed a realistic demonstration scenario for ebXML applications. The project is to deliver a (partial) implementation of the demonstration scenario using software implementations developed by project participants, which will be demonstrated at the upcoming XML Europe 2003 ebXML conference. The demonstration scenario has been developed with input from people active in industry associations like CIDX, EAN International, and Eurofer. The demonstration uses steel industry e-business integration scenarios from an actual ebMS implementation by Steel 24-7, a marketplace for the steel industry that today uses a production implementation of ebMS version 1.0. The current design of the demonstration scenario involves steel and automotive business partners and messages drawn from two XML vocabularies and EDIFACT. OASIS members Seeburger, Software AG, Sonic Software (Excelon), and Sun Microsystems, as well as individuals, contribute to the interoperability effort.

Adoption of ebXML is very strong in Asia. A recent interoperability project involving Fujitsu Limited, Hitachi Limited, NEC Corporation, Infoteria Corporation, and Nippon Telegraph and Telephone Corporation was successfully completed in October 2002. Several similar projects are ongoing.

Conclusion

ebMS is a complete and mature specification that provides useful extensions to SOAP. It has been implemented by a wide range of vendors, and many of these implementations have been verified for interoperability. People looking for web services to provide a secure and reliable messaging service for e-business applications or enterprise application integration today should take a close look at the specification and its implementations.

Acknowledgments

The author wants to thank Jacques Durand, Monica Martin, and Christopher Frank for critical comments on an earlier version of this article. Special thanks to Christopher Frank (Seeburger AG) for providing sample test data.

---