ebXML Messaging Services Version 3.0

This specification defines a communications-protocol neutral method for exchanging electronic business messages. It defines specific Web Services-based 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.

This document was last revised or approved by the TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

For information on whether 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 OASIS ebXML Messaging Services TC web page (http://www.oasis-open.org/committees/ebxml-msg/ipr.php ).

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, 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 OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

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' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on 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 implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The names "OASIS", "ebMXL", "OASIS ebXML Messaging Services", "ebMS" are trademarks of OASIS , the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

1. Introduction 9

1.1. Background and Objectives 9

1.2. Scope 9

1.3. Web Services and Their Role in an eBusiness Messaging Framework 10

1.4. Caveats and Assumptions 10

1.5. General Rules for Normative Interpretation 11

1.6. XML Notation 11

1.7. Namespace Prefixes 11

1.8. Example Domains 12

1.9. Normative References 12

1.10. Non-Normative References 13

2. Messaging Model 14

2.1. Terminology and Concepts 14

2.1.1. Components of the Model 14

2.1.2. Message Terminology 15

2.1.3. Messaging Roles 15

2.1.4. Abstract Messaging Operations 16

2.2. Message Exchange Patterns 16

2.2.1. Rationale 16

2.2.2. General Definition 16

2.2.3. MEP Bindings 17

2.2.4. Relationship to SOAP MEPs 18

2.2.5. The One-Way/Push MEP 19

2.2.6. The One-Way/Pull MEP 19

2.2.7. The Two-Way/Sync MEP 20

2.2.8. Other Transport-Channel-Bound MEPs 21

3. Message Pulling and Partitioning 22

3.1. Objectives 22

3.2. Supporting Message Pulling 22

3.3. Combining Pulling with Security and Reliability 23

3.4. Message Partition Channels 24

3.4.1. Concept and Purpose 24

3.4.2. Some Use Cases 26

3.4.3. Definition and Usage Requirements 28

4. Processing Modes 29

4.1. Messaging Service Processing Model 29

4.2. Processing Mode Features 30

4.3. Default Features for Processing Mode 31

5. Message Packaging 33

5.1. Message Envelope and Message Parts 33

5.1.1. MIME Structure and SOAP Profile 33

5.1.2. MIME and XML Considerations 36

5.1.3. ebXML SOAP Envelope Extension 36

5.1.4. ebMS Header 38

5.1.5. Payload Containers 38

5.2. The eb:Messaging Container Element 39

5.2.1. eb:Messaging Element Specification 40

5.2.2. eb:Messaging/eb:UserMessage 41

5.2.3. eb:Messaging/eb:SignalMessage 46

5.2.4. Message Unit Bundling 46

5.3. Examples of ebMS Messages 47

5.3.1. UserMessage Example 47

5.3.2. PullRequest Message Example 49

5.3.3. Error Message Example 49

5.3.4. Receipt Message Example 50

5.3.5. "Bundled" Message Example 50

6. Error Handling 52

6.1. Terminology 52

6.2. Packaging of ebMS Errors 52

6.2.1. eb:Error Element 52

6.2.2. eb:Error/@origin 53

6.2.3. eb:Error/@category 53

6.2.4. eb:Error/@errorCode 53

6.2.5. eb:Error/@severity 53

6.2.6. eb:Error/@refToMessageInError 53

6.2.7. eb:Error/@shortDescription 53

6.2.8. eb:Error/Description 53

6.2.9. eb:Error/ErrorDetail 53

6.3. ebMS Error Message 53

6.4. Extensibility of the Error Element 54

6.4.1. Adding new ebMS Errors 54

6.5. Generating ebMS Errors 54

6.6. Error Reporting 54

6.7. Standard ebMS Errors 55

6.7.1. ebMS Processing Errors 55

6.7.2. Security Processing Errors 56

6.7.3. Reliable Messaging Errors 56

7. Security Module 57

7.1. Security Element 57

7.2. Signing Messages 57

7.3. Signing SOAP with Attachments Messages 58

7.4. Encrypting Messages 58

7.5. Encrypting SOAP with Attachments Messages 58

7.6. Signing and Encrypting Messages 58

7.7. Security Token Authentication 58

7.8. Security Policy Errors 58

7.9. Secured Message Examples 59

7.9.1. Digitally Signed and Encrypted ebXML Message 59

7.9.2. Digitally Signed and Encrypted ebXML SOAP with Attachments Message 61

7.9.3. Digitally Signed Receipt Signal Message 63

7.10. Message Authorization 64

7.11. Securing the PullRequest Signal 66

7.11.1. Authentication 66

7.11.2. Authorization 66

7.11.3. Preventing Replay Attacks 66

7.12. Countermeasure Technologies 66

7.12.1. Persistent Digital Signature 66

7.12.2. Persistent Signed Receipt 66

7.12.3. Non-Persistent Authentication 67

7.12.4. Non-Persistent Integrity 67

7.12.5. Persistent Confidentiality 67

7.12.6. Non-Persistent Confidentiality 67

7.12.7. Persistent Authorization 67

7.12.8. Non-Persistent Authorization 67

7.13. Security Considerations 67

8. Reliable Messaging Module 69

8.1. The Reliable Messaging Model 69

8.1.1. Message Processing 69

8.1.2. The Reliable Messaging Processor in the MSH 69

8.2. Reliable Delivery of ebMS Messages 71

8.2.1. Reliability Contracts for the RMP 71

8.2.2. Reliability Contracts for the MSH 72

8.2.3. Reliability for Signal Messages 73

8.2.4. Handling of Delivery Failures 73

8.3. Reliability of ebMS MEPs 74

8.3.1. Reliability of the One-Way/Push MEP 74

8.3.2. Reliability of the One-Way/Pull MEP 75

8.3.3. Reliability of the Two-Way/Sync MEP 76

8.3.4. Reliability of Other Transport-Channel-Bound MEPs 77

APPENDIX A. The ebXML SOAP Extension Element Schema 78

APPENDIX B. Reliable Messaging Bindings 82

B.1. WS-Reliability Binding 82

B.1.1. Operations and Contracts Binding 82

B.1.2. Complement to the Reliability of the One-Way/Push MEP 82

B.1.3. Complement to the Reliability of the One-Way/Pull MEP 82

B.1.4. Complement to the Reliability of the Two-Way/Sync MEP 83

B.2. WS-ReliableMessaging Binding 85

B.2.1. Operations and Contracts Binding 85

B.2.2. Complement to the Reliability of the One-Way/Push MEP 86

B.2.3. Complement to the Reliability of the One-Way/Pull MEP 87

B.2.4. Complement to the Reliability of the Two-Way/Sync MEP 87

APPENDIX C. SOAP Format and Bindings 89

C.1. Using SwA with SOAP-1.1 89

C.2. Using SwA with SOAP-1.2 90

C.3. SMTP Binding 91

APPENDIX D. Processing Modes 92

D.1. Objectives and Usage 92

D.2. Model for Processing Modes 93

D.2.1. Notation 94

D.3. Processing Mode Parameters 95

D.3.1. General P-Mode Parameters 95

D.3.2. PMode[1].Protocol 96

D.3.3. PMode[1].BusinessInfo 96

D.3.4. PMode[1].ErrorHandling 96

D.3.5. PMode[1].Reliability 97

D.3.6. PMode[1].Security 98

APPENDIX E. P-Mode Values and ebMS MEP Bindings 100

E.1. P-Mode Values and the One-Way/Push MEP 100

E.2. P-Mode Values and the One-Way/Pull MEP 101

E.3. P-Mode Values and the Two-Way/Sync MEP 102

APPENDIX F. Compatibility Mapping to ebMS 2.0 103

F.1. Objectives and Approach 103

F.2. Compatibility Mapping Rules 103

F.2.1. (CM1) Header Mapping Rules 103

F.2.2. (CM2) Payload Mapping Rules 104

F.2.3. (CM3) Reliability Mapping Rules 104

F.2.4. (CM4) MEP Mapping Rules 105

F.2.5. (CM5) Signal Mapping Rules 107

F.2.6. (CM6) Processing Mode Mapping Rules 108

APPENDIX G. Conformance 109

APPENDIX H. Acknowledgments 110

APPENDIX I. Revision History 111

Table of Figures

This specification describes a communication-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 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 the ebXML Messaging Service (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 this 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.

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.

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 ebXML Messaging protocol is to be capable of being carried over any available transfer protocol. This version of 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.

The ebXML infrastructure is composed of several independent, but related, components. Some references and bindings to other ebXML specifications in this document should be interpreted as aids to integration, rather than as a requirement to integrate or to use in combination. For example, ebMS may refer to the [ebCPPA] specification, rather than require its use. The ebMS relies on a concept of "Agreement", the concrete representation of which (e.g. CPA or other configuration information) is left for implementers to decide.

The ebMS defines messaging functions, protocol and envelope intended to operate over SOAP (SOAP 1.1 or SOAP 1.2, and SOAP with Attachments). Binding to lower transport layers such as HTTP and SMTP relies on standard SOAP bindings when these exist, and ebMS only specifies some complement to these, as required.

This document, Part 1: Core Features, supports networking topologies in which there are limitations on initiating message transfer, but with only a point-to-point MSH topology, in which no intermediaries are present. A forthcoming Part 2, containing Advanced Features, may take into account topologies that contain intermediaries (e.g. hub, multi-hop), as well as those in which the ultimate MSH acts as a SOAP intermediary.

This version of ebMS leverages established SOAP-based specifications that handle quality of service in the domains of reliability and security. The ebMS specification defines how these are composed in the ebMS context. The design of this composition takes into account the reuse of existing implementations of these standards, not just the reuse of these standards themselves.

The concept for an ebMS implementation is of an ebXML Messaging Service Handler (MSH), that is abstractly defined as implementing the specified messaging functions. Any interface to the MSH is out of scope of this specification. Although it is clearly helpful in many cases to define a standard API, such an interface should not exclude other ways applications may want to interact with an MSH. Such an interface definition should rather belong to an implementation guideline companion document. An implementation of this specification could be delivered as a wholly independent software component or as an embedded component of a larger system.

A major design choice in ebMS 3, is the specification of the MSH and its associated processing rules using Web Services standards. The intent is to make use of other relevant Web Services specifications that fulfill certain messaging requirements, and build upon that base by adding what is necessary for a complete and coherent eBusiness messaging service. ebMS 3 brings this all together into a single, coherent framework.

In order to achieve this, message security and reliability requirements are met through the use of other Web Services standards and their implementations. The message SOAP body has been freed for business payload. The ebMS header is just a SOAP extension among others. As a result, ebMS 3 is significantly more compliant than ebMS 2 with the SOAP processing model, and apt at composing Web services standards that are defined as SOAP extensions. Compliance of ebMS 3 implementations with the latest version of WS-I profiles - once approved as final material by the organization - will be addressed in the definition of conformance profiles that are adjunct to this specification (see Appendix G).

Compliance with Web services standards does not remove the rationale behind an Internet-based messaging middleware. Often, document-centric eBusiness and eGovernment exchanges need to clearly dissociate messaging functions from the way these messages are consumed on the back-end. Such consumption may take place according to various models, as mentioned in 1.1. The use of [SOAP] message header elements that represent standard business metadata (user or company ID, business conversation, business service and action, etc.), is a key feature for supporting a decoupled binding with back-end business processes. At the same time, experience has demonstrated that the messaging layer must be more supportive of business transactions: messages are parts of basic choreographies that map to higher-level business exchanges between partners. To this end, ebMS 3 supports a notion of message exchange pattern (MEP) the properties of which (reliability, security, binding to underlying transport, error handling, and other quality of service aspects such as timing, etc.) are controlled in a contract-based manner by the message producer and consumer layers.

The target audience for this specification is the community of software developers who will implement the ebXML Messaging Service.

It is assumed the reader has an understanding of communications protocols, MIME, XML, SOAP, SOAP Messages with Attachments and security technologies.

All examples are to be considered non-normative. If inconsistencies exist between the specification and the examples, the specification supersedes the examples.

Implementers are strongly advised to read and understand the Collaboration Protocol Profile & Agreement [ebCPPA] specification and its implications prior to implementation.

This specification presents some alternatives regarding underlying specifications (e.g. SOAP 1.1/1.2, WSS1.0/1.1, and Web Services specifications that support the reliability function). This does not imply that a conforming implementation must support them all, nor that it is free to support any option. The definition of conformance profiles - out of scope for this document, and to be described in an adjunct OASIS document - will complement this specification by asserting which option(s) must be supported in order to claim support for a particular conformance profile. Conformance to compatible profiles is a prerequisite to interoperability. See Appendix G for more details on conformance profiles.

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 [RFC2119].

For any given module described in this specification, an implementation MUST satisfy ALL of the following conditions to be considered a conforming implementation of that module:

When describing concrete XML schemas and information items, this specification uses a convention in which each XML element or attribute is identified using abbreviated [XPATH] notation (e.g., /x:MyHeader/x:SomeProperty/@attribute).

This table maps various prefixes that appear in XML examples to their intended corresponding namespaces.

Hostnames used in the examples are fictitious, and conform to [RFC2606]. The example.org domain is intended to refer generically to a relevant industry standards organization, while the example.com domain represents a participant in a message exchange (whether commercial, government, or other entity).

Prefix	Namespace
S11	http://schemas.xmlsoap.org/soap/envelope/
S12	http://www.w3.org/2003/05/soap-envelope
ds	http://www.w3.org/2000/09/xmldsig#
eb	http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/
enc	http://www.w3.org/2001/04/xmlenc#
wsr	http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd
wsrx	http://docs.oasis-open.org/ws-rx/wsrm/200702
wsse	http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
wsu	http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
ebbpsig	http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0

[HTTP11] R. Fielding, et al,

Hypertext
Transfer Protocol -- HTTP/1.1

, 1999. <http://www.ietf.org/rfc/rfc2616.txt>

[IANAMEDIA] Various, MIME Media Types, Various. <http://www.iana.org/assignments/media-types/>

[RFC2045] N Freed, et al,

Multipurpose
Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies

, 1996. <http://www.ietf.org/rfc/rfc2045.txt>

[RFC2119] S. Bradner,

Key words for use
in RFCs to Indicate Requirement Levels

, 1997. <http://www.ietf.org/rfc/rfc2119.txt>

[RFC2387] E. Levinson,

The MIME
Multipart/Related Content-type

, 1998. <http://www.ietf.org/rfc/rfc2387.txt>

[RFC2392] E. Levinson,

Content-ID and
Message-ID Uniform Resource Locators

, 1998. <http://www.ietf.org/rfc/rfc2392.txt>

[RFC2396] T. Berners-Lee, et al,

Uniform
Resource Identifiers (URI): Generic Syntax

, 1998. <http://www.ietf.org/rfc/rfc2396.txt>

[RFC2822] P. Resnick, ed.,

Internet
Message Format

, 2001. <http://www.ietf.org/rfc/rfc2822.txt>

[SMTP] J. Klensin, ed.,

Simple Mail
Transfer Protocol

, 2001. <http://www.ietf.org/rfc/rfc2821.txt>

[SOAP11] D. Box, et al,

Simple Object
Access Protocol (SOAP) 1.1

, 2000. <http://www.w3.org/TR/2000/NOTE-SOAP-20000508/>

[SOAP12] M. Gudgin, et al,

SOAP Version
1.2 Part 1: Messaging Framework

, 2003. <http://www.w3.org/TR/soap12-part1/>

[SOAPATTACH] J. Barton, et al,

SOAP
Messages with Attachments

, 2000. <http://www.w3.org/TR/SOAP-attachments>

[UTF8] F. Yergeau,

UTF-8, a
transformation format of ISO 10646

, 1998. <http://www.ietf.org/rfc/rfc2279.txt>

[WSIAP10] Chris Ferris, et al, eds,

Attachments
Profile Version 1.0

, 2004. <http://www.ws-i.org/Profiles/AttachmentsProfile-1.0-2004-08-24.html>

[WSIBSP10] Abbie Barbir, et al, eds,

Basic
Security Profile Version 1.0

, 2005. <http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html>

[WSR11] Kazunori Iwasa, et al, eds,

WS-Reliability
1.1

, 2004. <http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf>

[WSRM11] D. Davis, et al, eds,

Web
Services Reliable Messaging (WS-ReliableMessaging) Version 1.1

, 2007. <http://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.pdf>

[WSRMP11] D. Davis, et al, eds,

Web
Services Reliable Messaging Policy (WS-RM Policy) Version 1.1

, 2007. <http://docs.oasis-open.org/ws-rx/wsrmp/v1.1/wsrmp.pdf>

[WSS10] Anthony Nadalin, et al, eds.,

Web
Services Security: SOAP Message Security 1.0

, 2004. <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf>

[WSS10-USER] P. Hallam-Baker, et al, eds.,

Web
Services Security UsernameToken Profile 1.0

, 2004. <http://docs.oasis-open.org/wss/2004/01/>

[WSS10-X509] P. Hallam-Baker, et al, eds.,

Web
Services Security X.509 Certificate Token Profile

, 2004. <http://docs.oasis-open.org/wss/2004/01/>

[WSS11] Anthony Nadalin, et al, eds.,

Web
Services Security: SOAP Message Security 1.1

, 2005. <http://docs.oasis-open.org/wss/v1.1/>

[WSS11-USER] A. Nadalin, et al, eds.,

Web
Services Security UsernameToken Profile 1.1

, 2006. <http://docs.oasis-open.org/wss/v1.1/>

[WSS11-X509] A. Nadalin, et al, eds.,

Web
Services Security X.509 Certificate Token Profile 1.1

, 2006. <http://docs.oasis-open.org/wss/v1.1/>

[XML10] Tim Bray, et al, eds.,

Extensible
Markup Language (XML) 1.0 (Third Edition)

, 2004. <http://www.w3.org/TR/2004/REC-xml-20040204/>

[XMLDSIG] Donald Eastlake, et al, eds,


XML-Signature Syntax and Processing

, 2002. <http://www.w3.org/TR/xmldsig-core/>

[XMLENC] D. Eastlake, et al,

XML
Encryption Syntax and Processing

, 2002. <http://www.w3.org/TR/xmlenc-core/>

[XMLNS] Tim Bray, et al, eds,

Namespaces
in XML

, 1999. <http://www.w3.org/TR/REC-xml-names/>

[XMLSCHEMA] Henry S. Thompson, et al, eds.,

XML
Schema Part 1: Structures Second Edition

, 2004. <http://www.w3.org/TR/xmlschema-1/>

[XPATH] James Clark, et al, eds.,

XML
Path Language (XPath) Version 1.0

, 1999. <http://www.w3.org/TR/xpath>

[ebBP-SIG] OASIS ebXML Business Process TC,

ebXML
Business Signals Schema

, 2006. <http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0>

[ebCPPA] OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee,

Collaboration-Protocol
Profile and Agreement Specification Version 2.0

, 2002. <http://www.oasis-open.org/committees/download.php/204/ebcpp-2.0.pdf>

[ebCPPA21] OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee,

Collaboration-Protocol
Profile and Agreement Specification Version 2.1

, 2005. <http://www.oasis-open.org/committees/download.php/12208/ebcpp-2.1-april-5-2005-draft.doc>

[ebRISK] ebXML Security Team,

ebXML
Technical Architecture Risk Assessment v1.0

, 2001. <http://ebxml.org/specs/secRISK.pdf>

[ISO6523] Unknown,

Identification of
organization identification schemes

, 1998. <http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=25773>

[ISO9735] Unknown, EDIFACT, 1988. <http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17592>

[QAFW] Karl Dubost, et al, eds,

QA
Framework: Specification Guidelines

, 2005. <http://www.w3.org/TR/qaframe-spec/>

[RFC2246] T. Dierks, et al,

The TLS
Protocol Version 1.0

, 1999. <http://www.ietf.org/rfc/rfc2246.txt>

[RFC2402] S. Kent, et al,

IP
Authentication Header

, 1998. <http://www.ietf.org/rfc/rfc2402.txt>

[RFC2606] D. Eastlake, et al,

Reserved
Top Level DNS Names

, 1999. <http://www.ietf.org/rfc/rfc2606.txt>

[RFC2617] J. Franks, et al,

HTTP
Authentication: Basic and Digest Access Authentication

, 1999. <http://www.ietf.org/rfc/rfc2617.txt>

[RFC3023] M. Murata, et al,

XML Media
Types

, 2001. <http://www.ietf.org/rfc/rfc3023.txt>

[SOAPEMAIL] H. M. Mountain, et al,

SOAP
Version 1.2 Email Binding

, 2002. <http://www.w3.org/TR/soap12-email>

[WSPOLICY] A. Vedamuthu, et al, eds,

Web
Services Policy 1.5: Framework

, 2007. <http://www.w3.org/TR/ws-policy/>

[WSSECPOL] A. Nadalin, et al, eds,

WS-SecurityPolicy
1.2

, 2007. <http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.pdf>

This section defines the messaging model and its main concepts, along with the related terminology in use throughout the specification.

In all figures, the arrows do not represent control flow, i.e. they do not represent a component invoking an operation on another component. They only represent data transfer under the control of an operation which may be implemented in either component.

Producer and Consumer are always MSH endpoints, and Submit and Deliver operations occur at the endpoints only once per message lifetime. Any actions performed by an intermediary will be defined in different terms.

An ebMS Message is a SOAP message that contains SOAP header(s) qualified with the ebMS namespace, and that conforms to this specification.

An ebMS Message Unit is a logical unit of data that is a subset of an ebMS Message. There are two types of Message Units:

An ebMS User Message is an ebMS message that contains a User Message unit (in other words, it contains an eb:UserMessage element as a child of eb:Messaging).

An ebMS Signal Message is an ebMS message that contains a Signal Message unit. A Signal Message that contains an eb:PullRequest element is also called a Pull Signal Message.

An ebMS Message may contain both a User Message Unit and a Signal Message Unit. In that case it is both a Signal Message and a User Message.

The transmission of an ebMS user message requires a pair of Sending and Receiving MSHs. Note that these roles are defined as only relevant to ebMS user messages, as are the abstract operations below.

An ebMS MSH supports the following abstract operations, depending on which role it is operating in:

This section introduces the notion of an ebMS Message Exchange Pattern (MEP), and how it relates to SOAP MEPs. Such ebMS MEPs represent atomic units of choreography, i.e. different styles of exchange as required by connectivity constraints or application requirements.

Two communicating partners may agree to conduct business transactions as message sequences that follow well defined patterns, or Message Exchange Patterns (MEP). Enforcing these patterns is usually done above the messaging layer. However it has proved useful to support some aspects of such MEPs in the messaging layer. In particular:

An ebMS MEP represents the part of such exchange patterns that is controlled and implemented by an MSH, thus making an abstraction of the business semantics. Although the notion of MEP was not explicitly supported by ebMS 2.0, it can be noted that it provided some informal support for MEPs, such as message referencing (RefToMessageId) and the SyncReply element that controls the use of the back-channel of the underlying protocol. In the following, the acronym "MEP" implicitly means ebMS MEP, unless otherwise qualified.

The goal of this specification is to introduce a model for ebMS MEPs, rather than a formal representation of them. This model is the basis for partners agreeing to which MEPs their exchanges will conform. Such agreements are manifested in Processing Modes, or P-Modes, the representation of which is outside the scope of this specification. The P-Mode also defines which message profile is associated with which MEP, and the role it plays in this MEP. Processing Modes are described in detail in Section 4.

An ebMS MEP defines a typical choreography of ebMS User Messages which are all related through the use of the referencing feature (RefToMessageId). Each message of an MEP instance refers to a previous message of the same instance, unless it is the first one to occur. Messages are associated with a label (e.g. "request", "reply") that precisely identifies their direction between the parties involved and their role in the choreography.

Note: Because RefToMessageId more accurately defines a referencing between User Message Units than between User Messages (SOAP messages), MEPs are preferably defined here as exchanges of Message Units, rather than of ebMS Messages.

The MEP definitions are primarily concerned with the transfer of ebMS User Message Units. Instances of such MEPs may involve or cause the transfer of additional messages or the piggy-backing of additional elements (e.g. ebMS signal messages or units such as errors, receipts, pull requests, and low-level Acknowledgments when using reliability), but these are not taken into account in the MEP definition. Instead, the different ways these additions can be associated with the MEPs defined here, are considered as part of the execution mode of the MEP, which is controlled by some agreement/configuration external to the MEP definition (see P-Modes in Section 4). Some extra messages (Signal messages) may also be mandated by the binding of an ebMS MEP (see channel-binding), but are not relevant to the ebMS MEP definition itself.

The previous definition of ebMS MEP is quite abstract, and ignores any binding consideration to the transport protocol. This is intentional, so that application-level MEPs can be mapped to ebMS MEPs independently from the transport protocol to be used. In addition to agreeing on MEP usage, the following notions of MEP bindings should be subject to agreements between partners:

A transport channel binding is a critical complement to an MEP, to be agreed on in order for partners to interoperate. The rationale in using different transport channel bindings for an ebMS MEP is to accommodate different connectivity constraints (e.g. firewall restrictions, intermittent availability, non-static IP address) by dictating how each message transfer is initiated over the underlying protocol. Because such connectivity constraints usually exist independently from the details of the transport protocol, the transport channel binding is the right level to address them. The transport channel bindings identified in this specification are:

An MEP that is associated with a particular transport channel binding is also called a transport-channel-bound MEP. A transport-channel-bound MEP is identified by a pair <MEP name / transport-channel-binding name>. For example, a Two-Way ebMS MEP that executes over a single request-response exchange of the underlying transport (e.g. HTTP), is called a Two-Way/Sync MEP.

A channel-bound MEP has an Initiating MSH, or Initiator, which is the one that triggers the execution of the MEP. The other MSH is called the Responding MSH, or Responder. These MSH roles do not change for the duration of the MEP, regardless of the number of messages exchanged and of their direction. Due to endpoint addressing or availability restrictions, some MSHs may be required to act only as initiator, and never as responder.

On the wire, the only method by which messages from the same MEP instance are associated, is through a referencing link (RefToMessageId). This referencing is decided above the MSH layer (by the Producer entity). A receiving MSH relies on both this referencing and the interpretation of the P-Mode for associating a message with a specific MEP and for validating this association.

In theory, the transport-channel-bindings previously defined could be expressed in terms of SOAP MEPs instead of channels of the underlying transport protocol. However, the notion of SOAP MEP has only been introduced with SOAP 1.2, and would need to be extended to SOAP 1.1.

Also, only the SOAP Request-Response MEP and Response MEP have been formally defined, as of the time this specification was written. A SOAP One-way MEP could also be defined, but how such an MEP may or may not bind to a two-way underlying protocol is yet to be determined.

Expressing the transport-channel-binding in terms of SOAP MEPs is only helpful if there is a published, non-ambiguous, standard way for these to map to the underlying protocol(s). This is currently only the case for some SOAP MEPs and some transport protocols. Consequently, this specification has chosen to express its transport-channel-bindings directly in terms of how to use the channels of the transport protocol, abstracting such a transport as either "One-Way" or "Two-Way".

This transport-channel-bound MEP involves the transfer of a single ebMS User Message unit (label: "oneway").

To conform to this MEP, the ebMS User Message unit that is exchanged MUST NOT relate to any other User Message unit (no eb:RefToMessageId element). Figure 2 illustrates the exchange pattern and MSH operations involved in this MEP.

In case the One-Way/Push MEP is performed over a Two-way underlying transport protocol, the response message MAY carry an ebMS Signal Message, such as an error message, or other SOAP headers. Such an option is controlled by the P-Mode (see Section 4). However, the response message MUST NOT carry an ebMS User Message that refers to the request message. If the P-Mode allows Faults to be reported on the Two-way protocol's back-channel, the MEP can be qualified as a robust MEP, but is still an ebMS One-Way/Push MEP.

This transport-channel-bound MEP transfers two ebMS User Message units over a single Request-Response exchange of the underlying 2-way transport protocol. The Initiator MSH sends the first User Message called the "request" . In the second leg of the MEP, a related User Message unit called the "reply" is sent back. To conform to this MEP, the request MUST NOT relate to any other User Message unit (no eb:RefToMessageId element), and the reply MUST refer to the request via the eb:RefToMessageId header element, as described in Section 5.2.2.1. Figure 4 illustrates this MEP.

So far, message exchanges conforming to either one of the three previous transport-channel-bound MEPs were only using one instance of an underlying transport protocol MEP for their binding. The following channel-bound ebMS MEPs are expected to be among the most common ebMS MEPs that use more than one underlying transport protocol MEP instance between the Initiating MSH and the Responding MSH. In this sense, they may be qualified as asynchronous.

In all the above MEPs, the messages labels are respectively "request" and "reply". The two last MEPs support asynchronous exchanges where one party is constrained in terms of addressing or connectivity capability.

Business partners may experience differences in their ability to handle message flow, intermittent connectivity, lack of static IP addresses or firewall restrictions. In addition, when a message is transferred and successfully acknowledged, the responsibility for its management shifts sides. For these reasons, a receiver may want (a) to retain control over the transfer procedure of the underlying protocol by initiati

Notices

Table of Contents

Table of Figures

Introduction

Background and Objectives

Scope

Web Services and Their Role in an eBusiness Messaging Framework

Caveats and Assumptions

General Rules for Normative Interpretation

XML Notation

Namespace Prefixes

Example Domains

Normative References

Non-Normative References

Messaging Model

Terminology and Concepts

Components of the Model

Message Terminology

Messaging Roles

Abstract Messaging Operations

Message Exchange Patterns

Rationale

General Definition

MEP Bindings

Relationship to SOAP MEPs

The One-Way/Push MEP

The One-Way/Pull MEP

The Two-Way/Sync MEP

Other Transport-Channel-Bound MEPs

Message Pulling and Partitioning

Objectives