wsmc-1.0-spec-cs-01 11 April 2007 Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 1 of 27

1

Web Services Make Connection (WS-2

MakeConnection) Version 1.0 3

Committee Specification 4

11 April 2007 5

Specification URIs: 6 This Version: 7

http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cs-01.pdf 8 http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cs-01.html 9 http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cs-01.doc 10

Previous Version: 11 http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cd-05.pdf 12 http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cd-05.html 13 http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cd-05.doc 14

Latest Version: 15 http://docs.oasis-open.org/ws-rx/wsmc/v1.0/wsmc.pdf 16 http://docs.oasis-open.org/ws-rx/wsmc/v1.0/wsmc.html 17 http://docs.oasis-open.org/ws-rx/wsmc/v1.0/wsmc.doc 18

Technical Committee: 19 OASIS Web Services Reliable Exchange (WS-RX) TC 20

Chairs: 21 Paul Fremantle <paul@wso2.com> 22 Sanjay Patil <sanjay.patil@sap.com> 23

Editors: 24 Doug Davis, IBM <dug@us.ibm.com> 25 Anish Karmarkar, Oracle <Anish.Karmarkar@oracle.com> 26 Gilbert Pilz, BEA <gpilz@bea.com> 27 Steve Winkler, SAP <steve.winkler@sap.com> 28 Ümit Yalçinalp, SAP <umit.yalcinalp@sap.com> 29

Declared XML Namespaces: 30 http://docs.oasis-open.org/ws-rx/wsmc/200702 31

Abstract: 32 This specification (WS-MakeConnection) describes a protocol that allows messages to be transferred 33 between nodes implementing this protocol by using a transport-specific back-channel. The protocol is 34 described in this specification in a transport-independent manner allowing it to be implemented using 35 different network technologies. To support interoperable Web services, a SOAP binding is defined 36 within this specification. 37

The protocol defined in this specification depends upon other Web services specifications for the 38 identification of service endpoint addresses and policies. How these are identified and retrieved are 39 detailed within those specifications and are out of scope for this document. 40

By using the XML [XML], SOAP [SOAP 1.1], [SOAP 1.2] and WSDL [WSDL 1.1] extensibility model, 41 SOAP-based and WSDL-based specifications are designed to be composed with each other to define 42 a rich Web services environment. As such, WS-MakeConnection by itself does not define all the 43

wsmc-1.0-spec-cs-01 11 April 2007 Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 2 of 27

features required for a complete messaging solution. WS-MakeConnection is a building block that is 44 used in conjunction with other specifications and application-specific protocols to accommodate a 45 wide variety of requirements and scenarios related to the operation of distributed Web services. 46

Status: 47 This document was last revised or approved by the WS-RX Technical Committee on the above date. 48 The level of approval is also listed above. Check the "Latest Version" or "Latest Approved Version" 49 location noted above for possible later revisions of this document. 50

Technical Committee members should send comments on this specification to the Technical 51 Committee's email list. Others should send comments to the Technical Committee by using the "Send 52 A Comment" button on the Technical Committee's web page at http://www.oasis-53 open.org/committees/ws-rx/. 54

For information on whether any patents have been disclosed that may be essential to implementing 55 this specification, and any offers of patent licensing terms, please refer to the Intellectual Property 56 Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ws-57 rx/ipr.php). 58

The non-normative errata page for this specification is located at http://www.oasis-59 open.org/committees/ws-rx/.60

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 3 of 27

Notices 61

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. 62

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

This document and translations of it may be copied and furnished to others, and derivative works that 65 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and 66 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and 67 this section are included on all such copies and derivative works. However, this document itself may not be 68 modified in any way, including by removing the copyright notice or references to OASIS, except as needed 69 for the purpose of developing any document or deliverable produced by an OASIS Technical Committee 70 (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or 71 as required to translate it into languages other than English. 72

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 73 or assigns. 74

This document and the information contained herein is provided on an "AS IS" basis and OASIS 75 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 76 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 77 OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 78 PARTICULAR PURPOSE. 79

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

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

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 90 might be claimed to pertain to the implementation or use of the technology described in this document or 91 the extent to which any license under such rights might or might not be available; neither does it represent 92 that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 93 rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 94 OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 95 to be made available, or the result of an attempt made to obtain a general license or permission for the use 96 of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 97 Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 98 information or list of intellectual property rights will at any time be complete, or that any claims in such list 99 are, in fact, Essential Claims. 100

The name "OASIS", WS-MakeConnection, WSMC, WSRM, WS-RX are trademarks of OASIS, the owner 101 and developer of this specification, and should be used only to refer to the organization and its official 102 outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the 103 right to enforce its marks against misleading uses. Please see http://www.oasis-104 open.org/who/trademark.php for above guidance. 105

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 4 of 27

Table of Contents 106

1 Introduction .......................................................................................................................................5 107

1.1 Terminology ....................................................................................................................................5 108

1.2 Normative ........................................................................................................................................6 109

1.3 Non-Normative ................................................................................................................................6 110

1.4 Namespace .....................................................................................................................................7 111

1.5 Conformance ...................................................................................................................................8 112

2 MakeConnection Model .....................................................................................................................9 113

2.1 Glossary ........................................................................................................................................ 10 114

2.2 Protocol Preconditions ................................................................................................................... 10 115

2.3 Example Message Exchange ......................................................................................................... 10 116

3 MakeConnection ............................................................................................................................. 13 117

3.1 MakeConnection Anonymous URI ................................................................................................. 13 118

3.2 MakeConnection Message ............................................................................................................ 13 119

3.3 MessagePending ........................................................................................................................... 15 120

3.4 MakeConnection Policy Assertion .................................................................................................. 15 121

4 Faults .............................................................................................................................................. 17 122

4.1 Unsupported Selection .................................................................................................................. 18 123

4.2 Missing Selection........................................................................................................................... 18 124

5 Security Considerations................................................................................................................... 20 125

Appendix A. Schema ............................................................................................................................... 21 126

Appendix B. WSDL .................................................................................................................................. 22 127

Appendix C. Message Examples ............................................................................................................. 23 128

Appendix C.1 Example use of MakeConnection ................................................................................... 23 129

Appendix D. Acknowledgments ............................................................................................................... 27 130

131

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 5 of 27

1 Introduction 132

The primary goal of this specification is to create a mechanism for the transfer of messages between two 133 endpoints when the sending endpoint is unable to initiate a new connection to the receiving endpoint. It 134 defines a mechanism to uniquely identify non-addressable endpoints, and a mechanism by which 135 messages destined for those endpoints can be delivered. It also defines a SOAP binding that is required 136 for interoperability. Additional bindings can be defined. 137

This mechanism is extensible allowing additional functionality, such as security, to be tightly integrated. 138 This specification integrates with and complements the WS-ReliableMessaging[WS-RM], WS-Security 139 [WS-Security], WS-Policy [WS-Policy], and other Web services specifications. Combined, these allow for a 140 broad range of reliable, secure messaging options. 141

1.1 Terminology 142

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 143 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described 144 in RFC 2119 [KEYWORDS]. 145

This specification uses the following syntax to define normative outlines for messages: 146

The syntax appears as an XML instance, but values in italics indicate data types instead of values. 147

Characters are appended to elements and attributes to indicate cardinality: 148

o "?" (0 or 1) 149

o "*" (0 or more) 150

o "+" (1 or more) 151

The character "|" is used to indicate a choice between alternatives. 152

The characters "[" and "]" are used to indicate that contained items are to be treated as a group 153 with respect to cardinality or choice. 154

An ellipsis (i.e. "...") indicates a point of extensibility that allows other child or attribute content 155 specified in this document. Additional children elements and/or attributes MAY be added at the 156 indicated extension points but they MUST NOT contradict the semantics of the parent and/or 157 owner, respectively. If an extension is not recognized it SHOULD be ignored. 158

XML namespace prefixes (see section 1.4) are used to indicate the namespace of the element 159 being defined. 160

Elements and Attributes defined by this specification are referred to in the text of this document using 161 XPath 1.0 [XPATH 1.0] expressions. Extensibility points are referred to using an extended version of this 162 syntax: 163

An element extensibility point is referred to using {any} in place of the element name. This 164

indicates that any element name can be used, from any namespace other than the wsmc: 165 namespace. 166

An attribute extensibility point is referred to using @{any} in place of the attribute name. This 167 indicates that any attribute name can be used, from any namespace other than the wsmc: 168

namespace. 169

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 6 of 27

1.2 Normative 170

[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 171 2119, Harvard University, March 1997 172 http://www.ietf.org/rfc/rfc2119.txt 173

[SOAP 1.1] W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000. 174 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ 175

[SOAP 1.2] W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework" June 176 2003. 177 http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ 178

[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): 179 Generic Syntax," RFC 3986, MIT/LCS, U.C. Irvine, Xerox Corporation, January 180 2005. 181 http://ietf.org/rfc/rfc3986 182

[UUID] P. Leach, M. Mealling, R. Salz, "A Universally Unique IDentifier (UUID) URN 183 Namespace," RFC 4122, Microsoft, Refactored Networks - LLC, DataPower 184 Technology Inc, July 2005 185 http://www.ietf.org/rfc/rfc4122.txt 186

[WSDL 1.1] W3C Note, "Web Services Description Language (WSDL 1.1)," 15 March 2001. 187 http://www.w3.org/TR/2001/NOTE-wsdl-20010315 188

[WS-Addressing] W3C Recommendation, “Web Services Addressing 1.0 - Core”, May 2006. 189 http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/ 190 W3C Recommendation, “Web Services Addressing 1.0 – SOAP Binding”, May 191 2006. 192 http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/ 193

[WS-RM] OASIS WS-RX Technical Committee Specification, "Web Services Reliable 194 Messaging (WS-ReliableMessaging)," April 2007. 195 http://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.pdf 196

[WS-RM Policy] OASIS WS-RX Technical Committee Specification, "Web Services Reliable 197 Messaging Policy Assertion( WS-RM Policy)" April 2007 198 http://docs.oasis-open.org/ws-rx/wsrmp/v1.1/wsrmp.pdf 199

[XML] W3C Recommendation, "Extensible Markup Language (XML) 1.0 (Fourth 200 Edition)", September 2006. 201 http://www.w3.org/TR/REC-xml/ 202

[XML-ns] W3C Recommendation, "Namespaces in XML," 14 January 1999. 203 http://www.w3.org/TR/1999/REC-xml-names-19990114/ 204

[XML-Schema Part1] W3C Recommendation, "XML Schema Part 1: Structures," October 2004. 205 http://www.w3.org/TR/xmlschema-1/ 206

[XML-Schema Part2] W3C Recommendation, "XML Schema Part 2: Datatypes," October 2004. 207 http://www.w3.org/TR/xmlschema-2/ 208

[XPATH 1.0] W3C Recommendation, "XML Path Language (XPath) Version 1.0," 16 November 209 1999. 210 http://www.w3.org/TR/xpath 211

1.3 Non-Normative 212

[RDDL 2.0] Jonathan Borden, Tim Bray, eds. “Resource Directory Description Language 213 (RDDL) 2.0,” January 2004 214 http://www.openhealth.org/RDDL/20040118/rddl-20040118.html 215

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 7 of 27

[RTTM] V. Jacobson, R. Braden, D. Borman, "TCP Extensions for High Performance", 216 RFC 1323, May 1992. 217 http://www.rfc-editor.org/rfc/rfc1323.txt 218

[SecurityPolicy] G. Della-Libra, et. al. "Web Services Security Policy Language (WS-219 SecurityPolicy)", July 2005 220 http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf 221

[SecureConversation] S. Anderson, et al, "Web Services Secure Conversation Language (WS-222 SecureConversation)," February 2005. 223 http://schemas.xmlsoap.org/ws/2004/04/sc/ 224

[Trust] S. Anderson, et al, "Web Services Trust Language (WS-Trust)," February 2005. 225 http://schemas.xmlsoap.org/ws/2005/02/trust 226

[WS-Policy] W3C Member Submission "Web Services Policy 1.2 - Framework", April 2006 227 http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/ 228 229 W3C Candidate Recommendation, "Web Services Policy 1.5 - Framework," 230 February 2007. 231 http://www.w3.org/TR/2007/CR-ws-policy-20070228 232

[WS-PolicyAttachment] W3C Member Submission "Web Services Policy 1.2 - Attachment", April 233 2006 234 http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment-20060425/ 235 236 W3C Candidate Recommendation, "Web Services Policy 1.5 - Attachment," 237 February 2007. 238 http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228 239

[WS-Security] Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS 240 Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", 241 OASIS Standard 200401, March 2004. 242 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-243 security-1.0.pdf 244

245 Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS 246 Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", OASIS 247 Standard 200602, February 2006. 248 http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf 249

1.4 Namespace 250

The XML namespace [XML-ns] URI that MUST be used by implementations of this specification is: 251

http://docs.oasis-open.org/ws-rx/wsmc/200702 252

Dereferencing the above URI will produce the Resource Directory Description Language [RDDL 2.0] 253 document that describes this namespace. 254

Table 1 lists the XML namespaces that are used in this specification. The choice of any namespace prefix 255 is arbitrary and not semantically significant. The assertions defined within this specification have been 256 designed to work independently of a specific version of WS-Policy and WS-Policy Attachment. Within this 257 specification the use of the namespace prefix "wsp" refers generically to the WS-Policy namespace, not a 258 specific version. 259

Table 1 260

Prefix Namespace

S (Either SOAP 1.1 or 1.2)

S11 http://schemas.xmlsoap.org/soap/envelope/

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 8 of 27

S12 http://www.w3.org/2003/05/soap-envelope

wsmc http://docs.oasis-open.org/ws-rx/wsmc/200702

wsrm http://docs.oasis-open.org/ws-rx/wsrm/200702

wsa http://www.w3.org/2005/08/addressing

wsam http://www.w3.org/2007/02/addressing/metadata

xs http://www.w3.org/2001/XMLSchema

The normative schema for WS-MakeConnection can be found linked from the namespace document that 261 is located at the namespace URI specified above. 262

All sections explicitly noted as examples are informational and are not to be considered normative. 263

1.5 Conformance 264

An implementation is not conformant with this specification if it fails to satisfy one or more of the MUST or 265 REQUIRED level requirements defined herein. A SOAP Node MUST NOT use the XML namespace 266 identifier for this specification (listed in section 1.4) within SOAP Envelopes unless it is conformant with this 267 specification. 268

Normative text within this specification takes precedence over normative outlines, which in turn take 269 precedence over the XML Schema [XML Schema Part 1, Part 2] descriptions. 270

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 9 of 27

2 MakeConnection Model 271

The WS-Addressing [WS-Addressing] specification defines the anonymous URI to identify non-272 addressable endpoints and to indicate a protocol-specific back-channel is to be used for any messages 273 destined for that endpoint. For example, when used in the WS-Addressing ReplyTo EPR, the use of this 274 anonymous URI is meant to indicate that any response message is to be transmitted on the transport-275 specific back-channel. In the HTTP case this would mean that any response message is sent back on the 276 HTTP response flow. 277

In cases where the connection is still available the WS-Addressing URI is sufficient. However, in cases 278 where the original connection is no longer available, additional mechanisms are needed. Take the situation 279 where the original connection that carried a request message is broken and therefore is no longer 280 available to carry a response back to the original sender. Traditionally, non-anonymous (addressable) 281 EPRs would be used in these cases to allow for the sender of the response message to initiate new 282 connections as needed. However, if the sender of the request message is unable (or unwilling) to accept 283 new connections then the only option available is for it to establish a new connection for the purposes of 284 allowing the response message to be sent. This specification defines a mechanism by which a new 285 connection can be established. 286

The MakeConnection model consists of two key aspects: 287

An optional anonymous-like URI template is defined that has similar semantics to WS-288 Addressing's anonymous, but also allows for each non-addressable endpoint to be uniquely 289 identified 290

A new message is defined that establishes a connection that can then be used to transmit 291 messages to these non-addressable endpoints 292

Figure 1 below illustrates the overall flow involved in the use of MakeConnection: 293

Figure 1 – Make Connection Model 294

The MakeConnection message is used to establish a new connection between the two endpoints. Within 295 the message is identifying information that is used to uniquely identify a message that is eligible for 296 transmission. 297

Establish Protocol Preconditions

Non-Addressable

Endpoint

(MC Initiator)

Optional sharing of MC-Anonymous EPR

MakeConnection( Connection Identifying Parameters )

Make Connection Protocol

Message destined for the Non-Addressable Endpoint

Addressable

Endpoint

(MC Receiver)

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 10 of 27

2.1 Glossary 298

The following definitions are used throughout this specification: 299

Back-channel: When the underlying transport provides a mechanism to return a transport-protocol 300 specific response, capable of carrying a SOAP message, without initiating a new connection, this 301 specification refers to this mechanism as a back-channel. 302

Endpoint: As defined in the WS-Addressing specification; a Web service Endpoint is a (referenceable) 303 entity, processor, or resource to which Web service messages can be addressed. Endpoint references 304 (EPRs) convey the information needed to address a Web service Endpoint. 305

MC Initiator The endpoint that transmits the MakeConnection message – the destination endpoint for the 306 messages being sent on the transport-specific back-channel. 307

MC Receiver: The endpoint that receives the MakeConnection message – the source endpoint for the 308 messages being sent on the transport-specific back-channel. 309

Receive: The act of reading a message from a network connection. 310

Transmit: The act of writing a message to a network connection. 311

2.2 Protocol Preconditions 312

The correct operation of the protocol requires that a number of preconditions MUST be established prior to 313 the processing of the initial sequenced message: 314

The MC Receiver MUST be capable of accepting new incoming connections. 315

The MC Initiator MUST be capable of creating new outgoing connections to the MC Receiver, and 316 those connections MUST have a back-channel. 317

If a secure exchange of messages is REQUIRED, then the MC Initiator and MC Receiver MUST 318 have a security context. 319

2.3 Example Message Exchange 320

Figure 2 illustrates a message exchange in which the response message is delivered using 321 MakeConnection. 322

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 11 of 27

Figure 2: Example WS-MakeConnection Message Exchange 323

1. The protocol preconditions are established. These include policy exchange, endpoint resolution, 324 and establishing trust. 325

2. The client (MC Initiator) sends a GetQuote request message to the service (MC Receiver). The 326 WS-Addressing wsa:ReplyTo EPR uses the MakeConnection Anonymous URI Template – 327

indicating that if the GetQuoteResponse message is not sent back on this connection's back-328 channel, then the client will use MakeConnection to retrieve it. 329

3. The service receives the request message and decides to close the connection by sending back 330 an empty response (in the HTTP case an HTTP 202 Accept is sent). 331

4. The client sends a MakeConnection message to the service. Within the MakeConnection element 332 is the wsmc:Address element containing the same MakeConnection Anonymous URI used in 333

step 2. 334

5. The service has not completed executing the GetQuote operation and decides to close the 335 connection by sending back an empty response (in the HTTP case an HTTP 202 Accept) 336 indicating that no messages destined for this MC Initiator are available at this time. 337

6. The client sends a second MakeConnection message to the service. Within the MakeConnection 338 element is the wsmc:Address element containing the same MakeConnection Anonymous URI 339

used in step 2. 340

7. The service uses this new connection to transmit the GetQuoteResponse message. 341

The service can assume that because the MakeConnection Anonymous URI Template was used in the 342 wsa:ReplyTo EPR the client will act as an MC Initiator for the purposes of retrieving messages destined 343

to that EPR (i.e. responses to the GetQuote). This allows the service the option of immediately releasing 344 resources used by the original connection – knowing that the client will, at some later point in time, 345 establish a new connection on which the GetQuoteResponse can be transmitted. Likewise, when the first 346 MakeConnection is received by the service, it again has the option of leaving the connection open until the 347 GetQuoteResponse is ready to be transmitted, or it can close the connection immediately knowing that the 348 MC Initiator will retransmit the MakeConnection message at some later point in time. Since the nature and 349 dynamic characteristics of the underlying transport and potential intermediaries are unknown in the general 350 case, the timing of re-transmissions cannot be specified. Additionally, over-aggressive re-transmissions 351 have been demonstrated to cause transport or intermediary flooding which are counterproductive. 352 Consequently, implementers are encouraged to utilize adaptive mechanisms that dynamically adjust re-353

Establish Protocol Preconditions

Non-Addressable

Endpoint

(MC Initiator)

GetQuote Request Message (wsa:ReplyTo=MCAnonURI?uuid=...123)

MakeConnection(wsmc:Address=MCAnonURI?uuid=...123)

Make Connection Protocol

Empty Response (HTTP 202)

Addressable

Endpoint

(MC Receiver)

Empty Response (HTTP 202)

MakeConnection(wsmc:Address=MCAnonURI?uuid=...123)

GetQuoteResponse

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 12 of 27

transmission time and the back-off intervals that are appropriate to the nature of the transports and 354 intermediaries envisioned. For the case of TCP/IP transports, a mechanism similar to that described as 355 RTTM in RFC 1323 [RTTM] SHOULD be considered. 356

Now that the basic model has been outlined, the details of this protocol are now provided in section 3. 357

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 13 of 27

3 MakeConnection 358

The following sub-sections define the various MakeConnection features, and prescribe their usage by a 359 conformant implementations. 360

3.1 MakeConnection Anonymous URI 361

When an Endpoint is not directly addressable (e.g. behind a firewall or not able to allow incoming 362 connections), an anonymous URI in the EPR address property can indicate such an Endpoint. The WS-363 Addressing anonymous URI is one such anonymous URI. This specification defines a URI template (the 364 WS-MC anonymous URI) which may be used to uniquely identify anonymous Endpoints. 365

http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id={unique-String} 366

The appearance of an instance of this URI template in the wsa:Address value of an EPR indicates a 367

protocol-specific back-channel will be established through a mechanism such as MakeConnection, 368

defined below. When using this URI template, “{unique-String}” MUST be replaced by a globally unique 369 string (e.g a UUID value as defined by RFC4122 [UUID]). This specification does not require the use of 370 one particular string generation scheme. This string uniquely distinguishes the Endpoint. A sending 371 Endpoint SHOULD Transmit messages at Endpoints identified with the URI template using a protocol-372

specific back-channel, including but not limited to those established with a MakeConnection message. 373 Note, this URI template is semantically similar to the WS-Addressing anonymous URI if a protocol-specific 374 back-channel is available. 375

3.2 MakeConnection Message 376

The MakeConnection element is sent in the body of a one-way message that establishes a 377 contextualized back-channel for the transmission of messages according to matching criteria (defined 378 below). In the non-faulting case, if no matching message is available then no SOAP envelope will be 379

returned on the back-channel. A common usage will be a client sending MakeConnection to a server for 380

the purpose of receiving asynchronous response messages. 381

The following exemplar defines the MakeConnection syntax: 382

<wsmc:MakeConnection ...> 383 <wsmc:Address ...> xs:anyURI </wsmc:Address> ? 384 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> ? 385 ... 386 </wsmc:MakeConnection> 387

The following describes the content model of the MakeConnection element. 388

/wsmc:MakeConnection 389

This element allows the sender to create a transport-specific back-channel that can be used to 390 return a message that matches the selection criteria. Endpoints MUST NOT send this element as 391 a header block. At least one selection criteria sub-element MUST be specified – if not a 392

MissingSelection fault MUST be generated. 393

/wsmc:MakeConnection/wsmc:Address 394

This element specifies the URI (wsa:Address) of the initiating Endpoint. Endpoints MUST NOT 395 return messages on the transport-specific back-channel unless they have been addressed to this 396 URI. This Address property and a message’s WS-Addressing destination property are considered 397 identical when they are exactly the same character-for-character. Note that URIs which are not 398

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 14 of 27

identical in this sense may in fact be functionally equivalent. Examples include URI references 399 which differ only in case, or which are in external entities which have different effective base URIs. 400

/wsmc:MakeConnection/wsmc:Address/@{any} 401

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to 402 the element. 403

/wsmc:MakeConnection/wsrm:Identifier 404

This element specifies the WS-RM Sequence Identifier that establishes the context for the 405 transport-specific back-channel. The Sequence Identifier should be compared with the Sequence 406 Identifiers associated with the messages held by the sending Endpoint, and if there is a matching 407 message it will be returned. 408

/wsmc:MakeConnection/wsrm:Identifier/@{any} 409

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to 410 the element. 411

/wsmc:MakeConnection/{any} 412

This is an extensibility mechanism to allow different (extensible) types of information, based on a 413 schema, to be passed. This allows fine-tuning of the messages to be returned, additional selection 414

criteria included here are logically ANDed with the Address and/or wsrm:Identifier. If an 415

extension is not supported by the Endpoint then it should generate an UnsupportedSelection 416 fault. 417

/wsmc:MakeConnection/@{any} 418

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to 419 the element. 420

If more than one selection criteria element is present, then the MC Receiver processing the 421 MakeConnection message MUST insure that any SOAP Envelope flowing on the back-channel satisfies 422

all of those selection criteria. 423

The management of messages that are awaiting the establishment of a back-channel to their receiving 424 Endpoint is an implementation detail that is outside the scope of this specification. Note, however, that 425 these messages form a class of asynchronous messages that is not dissimilar from “ordinary” 426 asynchronous messages that are waiting for the establishment of a connection to their destination 427 Endpoints. 428

This specification places no constraint on the types of messages that can be returned on the transport-429 specific back-channel. As in an asynchronous environment, it is up to the recipient of the 430

MakeConnection message to decide which messages are appropriate for transmission to any particular 431

Endpoint. However, the Endpoint processing the MakeConnection message MUST insure that the 432

messages match the selection criteria as specified by the child elements of the MakeConnection 433 element. 434

Since the message exchange pattern use by MakeConnection is untraditional, the following points need 435 to be reiterated for clarification: 436

The MakeConnection message is logically part of a one-way operation; there is no reply 437

message to the MakeConnection itself, and any response flowing on the transport back-channel 438

is a pending message. 439

Since there is no reply message to MakeConnection, the WS-Addressing specific rules in 440 section 3.4 "Formulating a Reply Message" are not used. Therefore, the value of any 441

wsa:ReplyTo element in the MakeConnection message has no effective impact since the WS-442

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 15 of 27

Addressing [reply endpoint] property that is set by the presence of wsa:ReplyTo is not 443

used. 444

In the absence of any pending message, there will be no message transmitted on the transport 445

back-channel. E.g. in the HTTP case just an HTTP 202 Accepted will be returned without any 446 SOAP envelope in the HTTP response message. 447

When there is a message pending, it is sent on the transport back-channel, using the connection 448 that has been initiated by the MakeConnection request. 449

3.3 MessagePending 450

When MakeConnection is used, and a message is returned on the transport-specific back-channel, the 451

MessagePending header SHOULD be included on the returned message as an indicator whether there 452 are additional messages waiting to be retrieved using the same selection criteria that was specified in the 453

MakeConnection element. 454

The following exemplar defines the MessagePending syntax: 455

<wsmc:MessagePending pending="xs:boolean" ...> 456 ... 457 </wsmc:MessagePending> 458

The following describes the content model of the MessagePending header block. 459

/wsmc:MessagePending 460

This element indicates whether additional messages are waiting to be retrieved. 461

/wsmc:MessagePending/@pending 462

This attribute, when set to "true", indicates that there is at least one message waiting to be 463 retrieved. When this attribute is set to "false" it indicates there are currently no messages waiting 464 to be retrieved. 465

/wsmc:MessagePending/{any} 466

This is an extensibility mechanism to allow different (extensible) types of information, based on a 467 schema, to be passed. 468

/wsmc:MessagePending/@{any} 469

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to 470 the element. 471

The absence of the MessagePending header has no implication as to whether there are additional 472 messages waiting to be retrieved. 473

3.4 MakeConnection Policy Assertion 474

The MakeConnection policy assertion indicates that the MakeConnection protocol (operation and the use 475 of the MakeConnection URI template in EndpointReferences) is required for messages sent from this 476 endpoint. This assertion has Endpoint Policy Subject [WS-PolicyAttachment]. 477

The normative outline for the MakeConnection assertion is: 478

<wsmc:MCSupported ...> ... </wsmc:MCSupported> 479

The following describes the content model of the MCSupported element. 480

/wsmc:MCSupported 481

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 16 of 27

A policy assertion that specifies that the MakeConnection protocol is required for messages sent 482 from this endpoint. 483

/wsmc:MCSupported/{any} 484

This is an extensibility mechanism to allow different (extensible) types of information, based on a 485 schema, to be passed. 486

/wsmc:MCSupported/@{any} 487

This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to 488 the element. 489

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 17 of 27

4 Faults 490

Entities that generate WS-MakeConnection faults MUST include as the [action] property the default fault 491 action IRI defined below. The value from the W3C Recommendation is below for informational purposes: 492

http://docs.oasis-open.org/ws-rx/wsmc/200702/fault 493

The faults defined in this section are generated if the condition stated in the preamble is met. Fault 494 handling rules are defined in section 6 of WS-Addressing SOAP Binding. 495

The definitions of faults use the following properties: 496

[Code] The fault code. 497

[Subcode] The fault subcode. 498

[Reason] The English language reason element. 499

[Detail] The detail element(s). If absent, no detail element is defined for the fault. If more than one detail 500 element is defined for a fault, implementations MUST include the elements in the order that they are 501 specified. 502

Entities that generate WS-MakeConnection faults MUST set the [Code] property to either "Sender" or 503 "Receiver". These properties are serialized into text XML as follows: 504

SOAP Version Sender Receiver

SOAP 1.1 S11:Client S11:Server

SOAP 1.2 S:Sender S:Receiver

The properties above bind to a SOAP 1.2 fault as follows: 505

<S:Envelope> 506 <S:Header> 507 <wsa:Action> 508 http://docs.oasis-open.org/ws-rx/wsmc/200702/fault 509 </wsa:Action> 510 <!-- Headers elided for brevity. --> 511 </S:Header> 512 <S:Body> 513 <S:Fault> 514 <S:Code> 515 <S:Value> [Code] </S:Value> 516 <S:Subcode> 517 <S:Value> [Subcode] </S:Value> 518 </S:Subcode> 519 </S:Code> 520 <S:Reason> 521 <S:Text xml:lang="en"> [Reason] </S:Text> 522 </S:Reason> 523 <S:Detail> 524 [Detail] 525 ... 526 </S:Detail> 527 </S:Fault> 528 </S:Body> 529 </S:Envelope> 530

The properties bind to a SOAP 1.1 fault as follows when the fault is generated as a result of processing a 531

MakeConnection message: 532

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 18 of 27

<S11:Envelope> 533 <S11:Body> 534 <S11:Fault> 535 <faultcode> [Subcode] </faultcode> 536 <faultstring> [Reason] </faultstring> 537 </S11:Fault> 538 </S11:Body> 539 </S11:Envelope> 540

4.1 Unsupported Selection 541

The QName of the unsupported element(s) are included in the detail. 542

Properties: 543

[Code] Receiver 544

[Subcode] wsmc:UnsupportedSelection 545

[Reason] The extension element used in the message selection is not supported by the MakeConnection 546 receiver 547

[Detail] 548

<wsmc:UnsupportedSelection> xs:QName </wsmc:UnsupportedSelection>+ 549

Generated by Condition Action Upon Generation

Action Upon Receipt

MakeConnection receiver

In response to a MakeConnection message containing a selection criteria in the extensibility section of the message that is not supported

Unspecified. Unspecified.

4.2 Missing Selection 550

The MakeConnection element did not contain any selection criteria. 551

Properties: 552

[Code] Receiver 553

[Subcode] wsmc:MissingSelection 554

[Reason] The MakeConnection element did not contain any selection criteria. 555

[Detail] 556

Generated by Condition Action Upon Generation

Action Upon Receipt

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 19 of 27

Generated by Condition Action Upon Generation

Action Upon Receipt

MakeConnection receiver

In response to a MakeConnection message that does not contain any selection criteria

Unspecified. Unspecified.

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 20 of 27

5 Security Considerations 557

It is strongly RECOMMENDED that the communication between Web services be secured using the 558 mechanisms described in WS-Security. In order to properly secure messages, the body and all relevant 559 headers need to be included in the signature. Specifically, any standard messaging headers, such as 560 those from WS-Addressing, need to be signed with the body in order to "bind" the two together. 561

Different security mechanisms may be desired depending on the frequency of messages. For example, for 562 infrequent messages, public key technologies may be adequate for integrity and confidentiality. However, 563 for high-frequency events, it may be more performant to establish a security context for the events using 564 the mechanisms described in WS-Trust [Trust] and WS-SecureConversation [SecureConversation]. It 565 should be noted that if a shared secret is used it is RECOMMENDED that derived keys be used to 566 strengthen the secret as described in WS-SecureConversation. 567

Requests for messages which are not available to anonymous parties are strongly RECOMMENDED to 568 require usage of WS-Security so that the requestor can be authenticated and authorized to access the 569 indicated messages. Similarly, integrity and confidentiality SHOULD be used whenever messages have 570 restricted access. 571

Recipients of messages are RECOMMENDED to validate the signature to authenticate and verify the 572 integrity of the data. Specifically, recipients SHOULD verify that the sender has the right to "speak" for the 573 message. 574

The following list summarizes common classes of attacks that apply to this protocol and identifies the 575 mechanism to prevent/mitigate the attacks: 576

Message alteration - Alteration is prevented by including signatures of the message information 577 using WS-Security. 578

Message disclosure - Confidentiality is preserved by encrypting sensitive data using WS-Security. 579

Key integrity - Key integrity is maintained by using the strongest algorithms possible (by comparing 580 secured policies - see WS-Policy and WS-SecurityPolicy [SecurityPolicy]). 581

Authentication - Authentication is established using the mechanisms described in WS-Security and 582 WS-Trust. Each message is authenticated using the mechanisms described in WS-Security. 583

Accountability - Accountability is a function of the type of and strength of the key and algorithms 584 being used. In many cases, a strong symmetric key provides sufficient accountability. However, in 585 some environments, strong PKI signatures are required. 586

Availability - All reliable messaging services are subject to a variety of availability attacks. Replay 587 detection is a common attack and it is RECOMMENDED that this be addressed by the 588 mechanisms described in WS-Security. Other attacks, such as network-level denial of service 589 attacks are harder to avoid and are outside the scope of this specification. That said, care should 590 be taken to ensure that minimal state is saved prior to any authenticating sequences. 591

Replay - Messages may be replayed for a variety of reasons. To detect and eliminate this attack, 592 mechanisms should be used to identify replayed messages such as the timestamp/nonce outlined 593 in WS-Security. Alternatively, and optionally, other technologies, such as sequencing, can also be 594 used to prevent replay of application messages. 595

Service endpoints SHOULD scope its searching of messages to those that were processed under the 596 same security context as the requesting MakeConnection message. 597

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 21 of 27

Appendix A. Schema 598

The normative schema that is defined for WS-MakeConnection using [XML-Schema Part1] and [XML-599 Schema Part2] is located at: 600

http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-schema-200702.xsd 601

The following copy is provided for reference. 602

<?xml version="1.0" encoding="UTF-8"?> 603 <!-- Copyright(C) OASIS(R) 1993-2007. All Rights Reserved. 604 OASIS trademark, IPR and other policies apply. --> 605 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 606 xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsmc="http://docs.oasis-607 open.org/ws-rx/wsmc/200702" targetNamespace="http://docs.oasis-open.org/ws-608 rx/wsmc/200702" elementFormDefault="qualified" 609 attributeFormDefault="unqualified"> 610 <xs:import namespace="http://www.w3.org/2005/08/addressing" 611 schemaLocation="http://www.w3.org/2006/03/addressing/ws-addr.xsd"/> 612 <!-- Protocol Elements --> 613 <xs:complexType name="MessagePendingType"> 614 <xs:sequence> 615 <xs:any namespace="##other" processContents="lax" minOccurs="0" 616 maxOccurs="unbounded"/> 617 </xs:sequence> 618 <xs:attribute name="pending" type="xs:boolean"/> 619 <xs:anyAttribute namespace="##other" processContents="lax"/> 620 </xs:complexType> 621 <xs:element name="MessagePending" type="wsmc:MessagePendingType"/> 622 <xs:element name="Address"> 623 <xs:complexType> 624 <xs:simpleContent> 625 <xs:extension base="xs:anyURI"> 626 <xs:anyAttribute namespace="##other" processContents="lax"/> 627 </xs:extension> 628 </xs:simpleContent> 629 </xs:complexType> 630 </xs:element> 631 <xs:complexType name="MakeConnectionType"> 632 <xs:sequence> 633 <xs:element ref="wsmc:Address" minOccurs="0" maxOccurs="1"/> 634 <xs:any namespace="##other" processContents="lax" minOccurs="0" 635 maxOccurs="unbounded"/> 636 </xs:sequence> 637 <xs:anyAttribute namespace="##other" processContents="lax"/> 638 </xs:complexType> 639 <xs:element name="MakeConnection" type="wsmc:MakeConnectionType"/> 640 <xs:element name="UnsupportedSelection"> 641 <xs:simpleType> 642 <xs:restriction base="xs:QName"/> 643 </xs:simpleType> 644 </xs:element> 645 </xs:schema> 646

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 22 of 27

Appendix B. WSDL 647

This WSDL describes the WS-MC protocol from the point of view of the endpoint that receives the 648 MakeConnection message. 649

Also note that this WSDL is intended to describe the internal structure of the WS-MC protocol, and will not 650 generally appear in a description of a WS-MC-capable Web service. See section 3.4 Policy for a higher-651 level mechanism to indicate that WS-MC is supported. 652

The normative WSDL 1.1 definition for WS-MakeConnection is located at: 653

http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-wsdl-200702.wsdl 654

The following non-normative copy is provided for reference. 655

<?xml version="1.0" encoding="utf-8"?> 656 <!-- Copyright(C) OASIS(R) 1993-2007. All Rights Reserved. 657 OASIS trademark, IPR and other policies apply. --> 658 <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 659 xmlns:xs="http://www.w3.org/2001/XMLSchema" 660 xmlns:wsa="http://www.w3.org/2005/08/addressing" 661 xmlns:wsam="http://www.w3.org/2007/02/addressing/metadata" 662 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 663 xmlns:tns="http://docs.oasis-open.org/ws-rx/wsmc/200702/wsdl" 664 targetNamespace="http://docs.oasis-open.org/ws-rx/wsmc/200702/wsdl"> 665 666 <wsdl:types> 667 <xs:schema> 668 <xs:import namespace="http://docs.oasis-open.org/ws-rx/wsmc/200702" 669 schemaLocation="http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-schema-670 200702.xsd"/> 671 </xs:schema> 672 </wsdl:types> 673 674 <wsdl:message name="MakeConnection"> 675 <wsdl:part name="makeConnection" element="wsmc:MakeConnection"/> 676 </wsdl:message> 677 678 <wsdl:portType name="MCAbstractPortType"> 679 <wsdl:operation name="MakeConnection"> 680 <wsdl:input message="tns:MakeConnection" wsam:Action="http://docs.oasis-681 open.org/ws-rx/wsmc/200702/MakeConnection"/> 682 <!-- As described in the WS-MakeConnection specification, the 683 MakeConnection operation establishes a connection. If a matching 684 message is available then the back-channel of the connection will 685 be used to carry the message. In SOAP terms the returned message 686 is not a response, so there is no WSDL output message. --> 687 </wsdl:operation> 688 </wsdl:portType> 689 690 </wsdl:definitions> 691

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 23 of 27

Appendix C. Message Examples 692

Appendix C.1 Example use of MakeConnection 693

To illustrate how a MakeConnection message exchange can be used to deliver messages to an 694

Endpoint that is not addressable, consider the case of a pub/sub scenario in which the Endpoint to which 695 notifications are to be delivered (the "event consumer") is not addressable by the notification sending 696 Endpoint (the "event producer"). In this scenario the event consumer must initiate the connections in order 697 for the notifications to be delivered. One possible set of message exchanges (using HTTP) that 698

demonstrate how this can be achieved using MakeConnection is shown below. 699

Step 1 – During a "subscribe" operation, the event consumer's EPR specifies the MC anonymous URI and 700 the WS-RM Policy Assertion [WS-RM Policy] to indicate whether or not RM is required: 701

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 702 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 703 xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702" 704 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 705 <S:Header> 706 <wsa:To> http://example.org/subscriptionService </wsa:To> 707 <wsa:MessageID> http://client456.org/id-a6d8-a7c2eb546813</wsa:MessageID> 708 <wsa:ReplyTo> 709 <wsa:To> http://client456.org/response </wsa:To> 710 </wsa:ReplyTo> 711 </S:Header> 712 <S:Body> 713 <sub:Subscribe xmlns:sub="http://example.org/subscriptionService"> 714 <!-- subscription service specific data --> 715 <targetEPR> 716 <wsa:Address>http://docs.oasis-open.org/ws-717 rx/wsrm/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsa:Address> 718 <wsa:Metadata> 719 <wsp:Policy wsu:Id="MyPolicy"> 720 <wsrmp:RMAssertion/> 721 </wsp:Policy> 722 </wsa:Metadata> 723 </targetEPR> 724 </sub:Subscribe> 725 </S:Body> 726 </S:Envelope> 727

In this example the subscribe and targetEPR elements are simply examples of what a subscription 728

request message might contain. Note: the wsa:Address element contains the MC anonymous URI 729 indicating that the notification producer needs to queue the messages until they are requested using the 730

MakeConnection message exchange. The EPR also contains the WS-RM Policy Assertion indicating the 731

RM must be used when notifications related to this subscription are sent. 732

733

Step 2 – Once the subscription is established, the event consumer checks for a pending message: 734

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 735 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 736 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 737 <S:Header> 738 <wsa:Action>http://docs.oasis-open.org/ws-739 rx/wsmc/200702/MakeConnection</wsa:Action> 740 <wsa:To> http://example.org/subscriptionService </wsa:To> 741

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 24 of 27

</S:Header> 742 <S:Body> 743 <wsmc:MakeConnection> 744 <wsmc:Address>http://docs.oasis-open.org/ws-745 rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsmc:Address> 746 </wsmc:MakeConnection> 747 </S:Body> 748 </S:Envelope> 749

Step 3 – If there are messages waiting to be delivered then a message will be returned back to the event 750 consumer. However, because WS-RM is being used to deliver the messages, the first message returned 751

is a CreateSequence: 752

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 753 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 754 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 755 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 756 <S:Header> 757 <wsa:Action>http://docs.oasis-open-org/ws-758 rx/wsrm/200702/CreateSequence</wsa:Action> 759 <wsa:To>http://docs.oasis-open.org/ws-rx/wsrm/200702/anonymous?id=550e8400-760 e29b-11d4-a716-446655440000</wsa:To> 761 <wsa:ReplyTo> http://example.org/subscriptionService </wsa:ReplyTo> 762 <wsa:MessageID> http://example.org/id-123-456 </wsa:MessagID> 763 <wsmc:MessagePending pending="true"/> 764 </S:Header> 765 <S:Body> 766 <wsrm:CreateSequence> 767 <wsrm:AcksTo> 768 <wsa:Address> http://example.org/subscriptionService </wsa:Address> 769 </wsrm:AcksTo> 770 </wsrm:CreateSequence> 771 </S:Body> 772 </S:Envelope> 773

Notice from the perspective of how the RM Source on the event producer interacts with the RM Destination 774

of those messages, nothing new is introduced by the use of the MakeConnection, the use of RM 775 protocol is the same as the case where the event consumer is addressable. Note the message contains a 776

wsmc:MessagePending header indicating that additional message are waiting to be delivered. 777

778

Step 4 – The event consumer will respond with a CreateSequenceResponse message per normal WS-779 Addressing rules: 780

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 781 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 782 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 783 <S:Header> 784 <wsa:Action>http://docs.oasis-open-org/ws-785 rx/wsrm/200702/CreateSequenceResponse</wsa:Action> 786 <wsa:To> http://example.org/subscriptionService </wsa:To> 787 <wsa:RelatesTo> http://example.org/id-123-456 </wsa:RelatesTo> 788 </S:Header> 789 <S:Body> 790 <wsrm:CreateSequenceResponse> 791 <wsrm:Identifier> http://example.org/rmid-456 </wsrm:Identifier> 792 </wsrm:CreateSequenceResponse> 793 </S:Body> 794 </S:Envelope> 795

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 25 of 27

Note, this message is carried on an HTTP request directed to the wsa:ReplyTo EPR, and the HTTP 796

response will be an HTTP 202. 797

798

Step 5 – The event consumer checks for another message pending: 799

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 800 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 801 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 802 <S:Header> 803 <wsa:Action>http://docs.oasis-open.org/ws-804 rx/wsmc/200702/MakeConnection</wsa:Action> 805 <wsa:To> http://example.org/subscriptionService </wsa:To> 806 </S:Header> 807 <S:Body> 808 <wsmc:MakeConnection> 809 <wsmc:Address>http://docs.oasis-open.org/ws-810 rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsmc:Address> 811 </wsmc:MakeConnection> 812 </S:Body> 813 </S:Envelope> 814

Notice this is the same message as the one sent in step 2. 815

816

Step 6 – Since there is a message pending for this destination then it is returned on the HTTP response: 817

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 818 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 819 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 820 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 821 <S:Header> 822 <wsa:Action> http://example.org/eventType1/</wsa:Action> 823 <wsa:To>http://docs.oasis-open.org/ws-rx/wsrm/200702/anonymous?id=550e8400-824 e29b-11d4-a716-446655440000</wsa:To> 825 <wsrm:Sequence> 826 <wsrm:Identifier> http://example.org/rmid-456 </wsrm:Identifier> 827 </wsrm:Sequence> 828 <wsmc:MessagePending pending="true"/> 829 </S:Header> 830 <S:Body> 831 <!-- event specific data --> 832 </S:Body> 833 </S:Envelope> 834

As noted in step 3, the use of the RM protocol does not change when using MakeConnection. The 835 format of the messages, the order of the messages sent and the timing of when to send it remains the 836 same. 837

838

Step 7 – At some later interval, or immediately due to the MessagePending header's "pending" 839 attribute being set to "true", the event consumer will poll again: 840

<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 841 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 842 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 843 <S:Header> 844 <wsa:Action> http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection 845 </wsa:Action> 846 <wsa:To> http://example.org/subscriptionService </wsa:To> 847 </S:Header> 848

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 26 of 27

<S:Body> 849 <wsmc:MakeConnection> 850 <wsmc:Address>http://docs.oasis-open.org/ws-851 rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsmc:Address> 852 </wsmc:MakeConnection> 853 </S:Body> 854 </S:Envelope> 855

Notice this is the same message as the one sent in steps 2 and 5. As in steps 3 and 6, the response to the 856 MakeConnection can be any message destined to the specified Endpoint. This allows the event 857

producer to send not only application messages (events) but RM protocol messages (e.g. 858

CloseSequence, TerminateSequence or even additional CreateSequence messages) as needed. 859

860

Step 8 – If at any point in time there are no messages pending, in response to a MakeConnection the 861 event producer returns an HTTP 202 back to the event consumer. The process then repeats (back to step 862 7) until the subscription ends. 863

wsmc-1.0-spec-cs-01 11 April 2007

Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 27 of 27

Appendix D. Acknowledgments 864

The following individuals have provided invaluable input into the initial contribution: 865

Keith Ballinger, Microsoft 866 Stefan Batres, Microsoft 867 Rebecca Bergersen, Iona 868 Allen Brown, Microsoft 869 Kyle Brown, IBM 870 Michael Conner, IBM 871 George Copeland, Microsoft 872 Francisco Curbera, IBM 873 Paul Fremantle, IBM 874 Steve Graham, IBM 875 Pat Helland, Microsoft 876 Rick Hill, Microsoft 877 Scott Hinkelman, IBM 878 Tim Holloway, IBM 879

Efim Hudis, Microsoft 880 David Ingham, Microsoft 881 Gopal Kakivaya, Microsoft 882 Johannes Klein, Microsoft 883 Frank Leymann, IBM 884 Martin Nally, IBM 885 Peter Niblett, IBM 886 Jeffrey Schlimmer, Microsoft 887 James Snell, IBM 888 Keith Stobie, Microsoft 889 Satish Thatte, Microsoft 890 Stephen Todd, IBM 891 Sanjiva Weerawarana, IBM 892 Roger Wolter, Microsoft 893

The following individuals were members of the committee during the development of this specification: 894

Abbie Barbir, Nortel 895 Charlton Barreto, Adobe 896 Stefan Batres, Microsoft 897 Hamid Ben Malek, Fujitsu 898 Andreas Bjarlestam, Ericsson 899 Toufic Boubez, Layer 7 900 Doug Bunting, Sun 901 Lloyd Burch, Novell 902 Steve Carter, Novell 903 Martin Chapman, Oracle 904 Dave Chappell, Sonic 905 Paul Cotton, Microsoft 906 Glen Daniels, Sonic 907 Doug Davis, IBM 908 Blake Dournaee, Intel 909 Jacques Durand, Fujitsu 910 Colleen Evans, Microsoft 911 Christopher Ferris, IBM 912 Paul Fremantle, WSO2 913 Robert Freund, Hitachi 914 Peter Furniss, Erebor 915 Marc Goodner, Microsoft 916 Alastair Green, Choreology 917 Mike Grogan, Sun 918 Ondrej Hrebicek, Microsoft 919 Kazunori Iwasa, Fujitsu 920 Chamikara Jayalath, WSO2 921 Lei Jin, BEA 922 Ian Jones, BTplc 923 Anish Karmarkar, Oracle 924

Paul Knight, Nortel 925 Dan Leshchiner, Tibco 926 Mark Little, JBoss 927 Lily Liu, webMethods 928 Matt Lovett, IBM 929 Ashok Malhotra, Oracle 930 Jonathan Marsh, Microsoft 931 Daniel Millwood, IBM 932 Jeff Mischkinsky, Oracle 933 Nilo Mitra, Ericsson 934 Peter Niblett, IBM 935 Duane Nickull, Adobe 936 Eisaku Nishiyama, Hitachi 937 Dave Orchard, BEA 938 Chouthri Palanisamy, NEC 939 Sanjay Patil, SAP 940 Gilbert Pilz, BEA 941 Martin Raepple, SAP 942 Eric Rajkovic, Oracle 943 Stefan Rossmanith, SAP 944 Tom Rutt, Fujitsu 945 Rich Salz, IBM 946 Shivajee Samdarshi, Tibco 947 Vladimir Videlov, SAP 948 Claus von Riegen, SAP 949 Pete Wenzel, Sun 950 Steve Winkler, SAP 951 Ümit Yalçinalp, SAP 952 Nobuyuki Yamamoto, Hitachi 953

954