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.