Messaging Services

The ebXML Messaging Services (ebMS) OASIS Standard (ISO 15000-2) defines the transport, routing and packaging of e-business transactions using standard Internet technologies. The specification is advanced by the OASIS ebXML Messaging Services Technical Committee, a group that remains open to new participation.

ebMS describes a communication-protocol neutral method for exchanging electronic business
messages. It defines specific enveloping constructs supporting reliable, secure delivery of business information. The specification defines a flexible enveloping technique, permitting messages to contain payloads of any format type. This versatility ensures that legacy electronic business systems employing traditional syntaxes (i.e. UN/EDIFACT, ASC X12, or HL7) can leverage the advantages of the ebXML infrastructure along with users of emerging technologies.

The prime objective of ebMS is to facilitate the exchange of electronic business messages within an XML framework that leverages common Internet standards, without making any assumption on the integration and consumption model these messages will follow on the back end. These messages may be consumed in different ways that are out of scope of the specification: they may bind to a legacy application, to a service, be queued, enter a message workflow process, be expected by an already-running business process, be batched for delayed processing, be routed over an Enterprise Service Bus before reaching their consumer application, or be dispatched based on header data or payload data, etc.

The ebXML messaging framework is not a restrictive one: business messages, identified as the 'payloads' of ebXML messages, are not limited to XML documents. Traditional EDI formats may also be transported by ebMS. These payloads can take any digital form–XML, ASC X12, HL7, AIAG E5, database tables, binary image files, etc. Multiple payloads, possibly of different MIME types, can be transported in a single ebMS message. An objective of the ebXML Messaging protocol is to be capable of being carried over any available transfer protocol. The specification provides bindings to HTTP and SMTP, but other protocols to which SOAP may bind can also be used. The choice of an XML framework rather reflects confidence in a growing XML-based Web infrastructure and development tools infrastructure, the components of which can be leveraged and reused by developers.

For more information, see the OASIS ebXML Messaging Service Technical Committee homepage and TC Charter.


Review answers to the frequently asked questions below on the ebXML Messaging Services specification. Post new questions and additional comments at the FAQ Forum. See also: ebXML FAQ, ebBP FAQ, ebCPPA FAQ, and ebXML Registry FAQ.

How does ebMS v3.0 differ from v2.0?

It is becoming critical for broad adoption among all partners – large or small - of a supply-chain, to handle differences in message flow capacity, intermittent connectivity, lack of static IP addresses or firewall restrictions. Such new capabilities played an important role in the motivation that led to ebMS 3.0, along with the need to integrate and profile the emerging SOAP-based QoS-supporting standards. The message header profiling that provided, in ebMS 2.0, a standard business-level header, has also been extended to better address the diversity of back-end binding models, as well as the emerging trend in business activity monitoring, the eBusiness side of which a message handler should be able to support.

Why is ebMS 3.0 being developed in two parts?

A number of OASIS members and supporters wanted the basic functionality as soon as possible (especially the pull functionality) as they have large user bases in the SME arena that need a lightweight intermittently connectable client to deal with major corporations. The OASIS ebMS Technical Committee decided to deliver the base mandatory functionality as soon as possible and to deliver the optional more complex/advanced/less-used functionality later.

Part 1 is mainly the mandatory functionality that we would expect all major vendor Gateway products to support (although some functionality will be optional on a relationship-by-relationship basis.

Part 2 will have all the more specialised functionality that will probably only be used in major organisations inter-trading e.g. large message handling, messaging routing/forwarding, multiple message bundling and additional transport level support. Although some of the functionality may be applied to the simpler trading environment such as the potential to ask for an individual message as part of a message pull request, this will likely be a special function to address a particular problem and not used as the normal general B2B solution.

Who uses ebMS?

ebMS is being used around the world. See ebXML deployments for more information.