ebms
2_0
http://www.oasis-open.org/commitees/ebxml-msg
OASIS ebXML Message Service Specification, Version 2.0
21 February 2002
2002
The Organization for the Advancement of Structured Information
Standards [OASIS]
This specification focuses on defining a communications-protocol neutral
method for exchanging electronic business messages. It defines specific
enveloping constructs supporting reliable, secure delivery of business
information. Furthermore, the specification defines a flexible enveloping
technique, permitting messages to contain payloads of any format type. This
versatility ensures 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.
Status
This document specifies an ebXML Message Specification for the eBusiness
community. Distribution of this document is unlimited.
Implementers of this specification should consult the OASIS ebXML Messaging
Services Technical Committee web site for current status and revisions to
the specification (http://www.oasis-open.org/committees/ebxml-msg/ ).
Version 1.0 of this Technical Specification document was approved by
the ebXML Plenary in May 2001.
Version 2.0 of this Technical Specification document was approved by
the OASIS Messaging Team as a Technical Committee(TC) Specification,
January 22, 2002.
Version 2.0 of this Technical Specification document is presented to the
ASIS membership for consideration as an OASIS Technical Specification,
April 2002.
Introduction
This specification is one of a series of specifications realizing the vision of creating a single global
electronic marketplace where enterprises of any size and in any geographical location can meet and
conduct business with each other through the exchange of XML based messages. The set of
specifications enable a modular, yet complete electronic business framework.
This specification focuses on defining a communications-protocol neutral method for exchanging
electronic business messages. It defines specific enveloping constructs supporting reliable, secure
delivery of business information. Furthermore, the specification defines a flexible enveloping technique,
permitting messages to contain payloads of any format type. This versatility ensures 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.
Summary of Contents of this Document
This specification defines the ebXML Message Service Protocol enabling the secure and reliable
exchange of messages between two parties. It includes descriptions of:
The ebXML Message structure used to package payload data for transport between parties.
The behavior of the Message Service Handler sending and receiving those messages over a data
communications protocol.
This specification is independent of both the payload and the communications protocol used. Appendices
to this specification describe how to use this specification with HTTP [RFC2616] and SMTP [RFC2821].
This specification is organized around the following topics:
Core Functionality
Packaging Specification – A description of how to package an ebXML Message and its associated parts
into a form that can be sent using a communications protocol such as HTTP or SMTP (section 2.1),
ebXML SOAP Envelope Extensions – A specification of the structure and composition of the information
necessary for an ebXML Message Service to generate or process an ebXML Message (section 2.3),
Error Handling – A description of how one ebXML Message Service reports errors it detects to another
ebXML Message Service Handler (section 4.2),
Security – Provides a specification of the security semantics for ebXML Messages (section 4.1),
SyncReply – Indicates to the Next MSH whether or not replies are to be returned synchronously
(section 4.3).
Additional Features
Reliable Messaging – The Reliable Messaging function defines an interoperable protocol where any two
Message Service implementations can reliably exchange messages sent using once-and-only-once delivery
semantics (section 6),
Message Status Service – A description of services enabling one service to discover the status of another
Message Service Handler (MSH) or an individual message (section 7 and 8),
Message Order – The Order of message receipt by the To Party MSH can be guaranteed (section 9),
Multi-Hop – Messages may be sent through intermediary MSH nodes (section 10).
Appendices to this specification cover the following:
Appendix A Schema – This normative appendix contains XML schema definition [XMLSchema] for the
ebXML SOAP Header and Body Extensions,
Appendix B Communications Protocol Envelope Mappings – This normative appendix describes how to
transport ebXML Message Service compliant messages over HTTP and SMTP,
Appendix C Security Profiles – a discussion concerning Security Service Profiles.
Terminology
The key words must, must
not, required,
shall, shall not,
should, should not,
recommended, may, and
optional in this document are to be
interpreted as described in .
Notices
Copyright © The Organization for the Advancement of Structured Information Standards
[OASIS] 2001, 2002. All Rights Reserved.
OASIS takes no position regarding the validity
or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation
or use of the technology described in this document
or the extent to which any license under such rights
might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on OASIS's procedures with respect to rights
in OASIS specifications can be found at the OASIS website.
Copies of claims of rights made available for publication
and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general
license or permission for the use of such proprietary
rights by implementors or users of this specification,
can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to
its attention any copyrights, patents or patent applications,
or other proprietary rights which may cover technology
that may be required to implement this specification.
Please address the information to the OASIS Executive
Director.
This document and translations of it may be copied
and furnished to others, and derivative works that comment
on or otherwise explain it or assist in its implementation
may be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph
are included on all such copies and derivative works.
However, this document itself may not be modified in
any way, such as by removing the copyright notice or
references to OASIS, except as needed for the purpose
of developing OASIS specifications, in which case the
procedures for copyrights defined in the OASIS Intellectual
Property Rights document must be followed, or as required
to translate it into languages other than English.
The limited permissions granted above are perpetual
and will not be revoked by OASIS or its successors or
assigns.
This document and the information contained herein
is provided on an AS IS
basis and OASIS DISCLAIMS
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS has been notified of intellectual property
rights claimed in regard to some or all of the contents
of this specification. For more information consult
the online list of claimed rights.
Committee Members
The following individuals were members of the committee during
the formulation of this document:
Ralph Berwanger, Individual Member
Dick Brooks, Individual Member
Doug Bunting, Sun Microsystems, Inc
David Burdett, Commerce One
Arvola Chan, TIBCO
Sanjay Cherian, Sterling Commerce
Cliff Collins, Sybase
Philippe DeSmedt, Individual Member
Colleen Evans, Sonic Software
Chris Ferris, Sun Microsystems, Inc
David Fischer, Drummond Group
Jim Galvin, Drummond Group
Brian Gibb, Sterling Commerce
Scott Hinkelman, IBM
Jim Hughes, Hewlett Packard
Kazunori Iwasa, Fujitsu Limited
Ian Jones, Individual Member
Brad Lund, Intel Corporation
Bob Miller, GE Global eXchange
Dale Moberg, Cyclone Commerce
Himagiri Mukkamala, Sybase
Bruce Pedretti, Hewlett-Packard
Yukinori Saito, Individual Member
Martin Sachs, IBM Research
Jeff Turpin, Cyclone Commerce
Aynur Unal, E2Open
Cedrec Vessell, DISA
Daniel Weinreb, eXcelon
Pete Wenzel, SeeBeyond
Prasad Yendluri, WebMethods
Sinisa Zimek, SAP
Intellectual Property Rights
For information on wether any patents have been disclosed that may be
essential to implementing this specification, and any offers of patent
licensing terms, please refer to the Intellectual Property Rights section
of the {technical-committee} web page
()
References
Normative
RFC 2119S. Bradner.
RFC 2119:
Key words for use in RFCs to Indicate Requirement Levels.
IETF (Internet Engineering Task Force). 1997.