The ebXML Messaging Service

March 18, 2003

Pim van der Eijk

The ebXML Messaging Service specification (ebMS) extends the SOAP specification to provide the security and reliability features required by many production enterprise and e-business applications. As an OASIS Open standard, ebMS is a mature specification, supported by a variety of commercial and open source software implementations. The interoperability of many of these implementations has been demonstrated in a number of ongoing projects internationally. This makes ebMS a strong complement or even alternative to other web service specifications.

Web Services and the ebXML Messaging Service

Concerns about security and reliability -- as Rich Salz's recent article, "Securing Web Services" made clear -- are among the biggest impediments to widespread adoption of web services. This is particularly true for business-to-business integration applications but also for application integration projects within the enterprise. Several ongoing efforts, in both industry standards organizations and ad hoc vendor consortia, are looking to create additional specifications beyond the core web services specifications to remedy this.

In this article we examine a specification that deserves serious attention in this context, namely, the the ebXML Messaging Service specification (ebMS). ebMS, endorsed in August 2002 as an OASIS standard, adds security and reliability extensions to SOAP and aligns e-business messaging with other e-business integration standards (like trading partner agreements and business process specification). After three years of development, ebMS has become a mature specification. While it is designed to support the ebXML framework, ebMS is a standalone specification that can be used independently of other ebXML specifications. Prospective users evaluating message service or web services technology have a choice of commerical and open source implementations of ebMS, many of which have been verified for interoperability in implementation pilots.

Web Services, ebXML and ebMS

The term "web services" is often defined narrowly as describing applications built using SOAP, WSDL and UDDI, but there are good reasons to interpret the term more broadly. Web services may include a larger range of applications which are built from a larger range of specifications and designed to meet a broader range of requirements. Taking this view, one way to classify web services applications is to distinguish the following types:

  • Integration web services that aim at exposing application interfaces or business services to remote systems. An integration web service may provide direct RPC-style, synchronous or asynchronous access to a single application. It may also provide access to several backend systems and provide simple routing and rule-based transformations, but even then it only implements some business logic. The majority of the business logic is still provided by the backend applications.
  • Collaborative web services that aim at managing shared business processes between business partners. A collaborative web service often needs to manage business transactions with many different business partners. These business transactions will be role-based, subject to sequencing rules (choreography), and tied to specific message formats. Choreography and message formats are often defined by vertical industry standards bodies. A collaborative web service will need a system to manage and validate these transactions and to maintain some state information to correlate asynchronous responses and check deadlines. It will often be configured for each specific partner according to service-level agreements.

Integration web services are a natural extension of RPC application access or Enterprise Application Integration (EAI) beyond an organization's boundary. They are often referred to as simple web services, although EAI is not necessarily a simpler problem than e-business integration. Similarly, collaborative web services are sometimes called complex Web Services. While simple web services -- like Google search, stock quote retrieval, or parcel tracking -- have either limited requirements for security and reliability or none at all, this is certainly not the case for other integration web services. For example, as web services start to be used for financial applications like credit card verification, security clearly becomes a major issue. The security and reliability features designed primarily for collaborative web services are becoming important for integration web services as well.

The ebXML framework for e-business was a joint initiative of UN/CEFACT and OASIS. The first phase of ebXML was executed as a joint project between 1999 and 2001. After successful delivery of a series of specifications, reports, and whitepapers in May 2001, further development of the ebXML specification has continued in the two organizations. The complete set of specifications in the ebXML framework is too complex to summarize in a few pages (see Professional ebXML Foundations for an introduction); fortunately, the specifications have been designed to be modular and independently useful. This is certainly true for the ebXML messaging specification, currently maintained by the OASIS ebXML Messaging Service Technical Committee. In August 2002, version 2.0 of this specification was endorsed by the OASIS members as an OASIS Open standard.

The collaborative web services category as defined here obviously covers the business-to-business integration scenarios that ebXML was designed for from the start. In fact, if the ebXML project were to start today rather than in 1999, it probably would have been called something like "ebWS", rather than ebXML. The various specifications that make up the ebXML framework and their implementations are of great potential interest to developers of collaborative web services applications and of integration web services with high-end security or reliability requirements. Taking this view, let's see how the ebXML Messaging Service builds on the core SOAP specification, and how it provides additional functionality.

Architecture and Requirements of ebMS

The ebXML Message Service defines both a message format and the behavior of software that exchanges ebXML messages. That software can be implemented as a standalone messaging software product, or it can be part of the functionality of e-business integration products or application servers. Conceptually, the ebXML messaging service can be thought of as having three layers:

  1. an abstract service interface, which applications use to access the messaging service;
  2. message service handler functions; and
  3. a mapping to underlying transport services (for example, HTTP or SMTP).

The following diagram provides an overview of the various functions provided by the message service handler.

Components in the ebXML Message Handler
Figure 1: Components in the ebXML Message Handler

Functional requirements for the message service include:

  • header processing (building a header from parameters passed from the invoking application);
  • header parsing (the reverse of header processing),
  • security services; (creating and verifying digital signatures, authentication and authorization);
  • reliable messaging (message persistence, retries, error notification, receipt acknowledgment);
  • packaging payloads into a SOAP with Attachments message package; and
  • error handling.

The ebMS specifies protocol bindings to HTTP and SMTP and allows implementations to support other protocols. For instance, one European car manufacturer uses ebMS over IBM MQSeries in an after-sales support application which exchanges information between a call center and dealer CRM systems. Interoperability is less crucial since this is an internal application.

The ebMS is also payload neutral: it imposes no restrictions on the content it carries, which can be based on any XML vocabulary, EDI, or binary data. Content can also be referenced by hyperlinks only and not transported itself, which is an important advantage that makes ebMS suitable for a very wide range of applications.

Anatomy of an ebXML message

The ebXML Message Service is layered over SOAP with Attachments. SOAP with Attachments (also discussed in another Rich Salz column) embeds a SOAP envelope as a first part of a MIME container, which contains all information needed for routing and thus allows for very efficient message processing. Other content (possibly multi megabyte EDI or UBL messages) can be appended as additional MIME parts and passed on to the receiving application. The general structure of an ebXML message is displayed in the following diagram:

Message anatomy
Figure 2: Message Anatomy

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"

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

<SOAP:Envelope xmlns:xlink="" 
   <SOAP:Header xmlns:eb="
      <!-- ... SOAP header content, see below ... -->
   <SOAP:Body xmlns:eb="
      <!-- ... SOAP body content, also see below ... -->


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.

   <eb:MessageHeader eb:id="messageHeader" eb:version="2.0" 
         <eb:PartyId eb:type="name">SEEBURGER AG, Christopher 
           Frank (</eb:PartyId>
         <!-- eb:PartyID omitted, similar to preceding eb:From -->
      <!-- 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:Description xml:lang="en-US">Initial ebXML message for 
	     initialization of Test Step 1 in IPP Test Case TCIPP101.</eb:Description>

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" 
      <eb:Description xml:lang="en-US">Simple 
        small XML file.</eb:Description>
   <eb:Reference eb:id="pl-0001" xlink:type="simple" 
      <eb:Description xml:lang="en-US">Large EDIFACT 
        file (20MB).</eb:Description>
   <eb:Reference eb:id="pl-0002" xlink:type="simple" 
      <eb:Description xml:lang="en-US">Large binary 
        file (15MB)</eb:Description>

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.

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


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.


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 (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 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.


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.


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.