The ebXML Messaging Service
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:
- an abstract service interface, which applications use to access the messaging service;
- message service handler functions; and
- 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.
|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 XML.com 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:
|Figure 2: Message Anatomy|
Pages: 1, 2