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.
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.
ebMS is being used around the world. See ebXML deployments for more information.