1

Web Services Make Connection

2

(WS-MakeConnection)

3

Committee Draft 05, February 1, 2007

4 Document identifier: 5 wsmc-1.0-spec-cd-05

6 Location: 7 http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.0-spec-cd-05.pdf

8 Editors:

9 Doug Davis, IBM <dug@us.ibm.com> 10 Anish Karmarkar, Oracle <Anish.Karmarkar@oracle.com> 11 Gilbert Pilz, BEA <gpilz@bea.com> 12 Steve Winkler, SAP <steve.winkler@sap.com> 13 Ümit Yalçinalp, SAP <umit.yalcinalp@sap.com>

14 Contributors: 15 See the Acknowledgments (Appendix D).

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

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

25 By using the XML [XML], SOAP [SOAP 1.1], [SOAP 1.2] and WSDL [WSDL 1.1] extensibility model, 26 SOAP-based and WSDL-based specifications are designed to be composed with each other to define a 27 rich Web services environment. As such, WS-MakeConnection by itself does not define all the features 28 required for a complete messaging solution. WS-MakeConnection is a building block that is used in 29 conjunction with other specifications and application-specific protocols to accommodate a wide variety of 30 requirements and scenarios related to the operation of distributed Web services.

31 Status: 32 This document was last revised or approved by the WS-RX on the above date. The level of approval is 33 also listed above. Check the current location noted above for possible later revisions of this document. 34 This document is updated periodically on no particular schedule. Technical Committee members should 35 send comments on this specification to the Technical Committee's email list. Others should send 36 comments to the Technical Committee by using the "Send A Comment" button on the Technical 37 Committee's web page at http://www.oasis-open.org/committees/ws-rx. For information on whether any 38 patents have been disclosed that may be essential to implementing this specification, and any offers of 39 patent licensing terms, please refer to the Intellectual Property Rights section of the Technical 40 Committee web page (http://www.oasis-open.org/committees/ws-rx/ipr.php. The non-normative errata 41 page for this specification is located at http://www.oasis-open.org/committees/ws-rx.

42

Table of Contents

43 1 Introduction..................................................................................................................................................3

44 1.1 Notational Conventions........................................................................................................................3

45 1.2 Namespace..........................................................................................................................................4

46 1.3 Conformance.......................................................................................................................................4 47 2 MakeConnection Model...............................................................................................................................5

48 2.1 Glossary...............................................................................................................................................5

49 2.2 Protocol Preconditions.........................................................................................................................6

50 2.3 Example Message Exchange..............................................................................................................6 51 3 MakeConnection.........................................................................................................................................8

52 3.1 MakeConnection Anonymous URI.......................................................................................................8

53 3.2 MakeConnection Message..................................................................................................................8

54 3.3 MessagePending...............................................................................................................................10

55 3.4 MakeConnection Policy Assertion.....................................................................................................10 56 4 Faults.........................................................................................................................................................11

57 4.1 Unsupported Selection ......................................................................................................................12

58 4.2 Missing Selection ..............................................................................................................................12 59 5 Security Considerations.............................................................................................................................14 60 6 References................................................................................................................................................15

61 6.1 Normative...........................................................................................................................................15

62 6.2 Non-Normative...................................................................................................................................16 63 Appendix A. Schema....................................................................................................................................18 64 Appendix B. WSDL.......................................................................................................................................20 65 Appendix C. Message Examples.................................................................................................................22 66 Appendix C.1 Example use of MakeConnection.....................................................................................22 67 Appendix D. Acknowledgments....................................................................................................................26 68 Appendix E. Revision History.......................................................................................................................27 69 Appendix F. Notices.....................................................................................................................................28

70

1 Introduction

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

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

80 1.1 Notational Conventions

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

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

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

86 • Characters are appended to elements and attributes to indicate cardinality:

87 o "?" (0 or 1)

88 o "*" (0 or more)

89 o "+" (1 or more)

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

91 • The characters "[" and "]" are used to indicate that contained items are to be treated as a group

92 with respect to cardinality or choice.

93 • An ellipsis (i.e. "...") indicates a point of extensibility that allows other child or attribute content

94 specified in this document. Additional children elements and/or attributes MAY be added at the

95 indicated extension points but they MUST NOT contradict the semantics of the parent and/or

96 owner, respectively. If an extension is not recognized it SHOULD be ignored.

97 • XML namespace prefixes (See Section 1.2) are used to indicate the namespace of the element

98 being defined.

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

102 • An element extensibility point is referred to using {any} in place of the element name. This 103 indicates that any element name can be used, from any namespace other than the wsmc: 104 namespace.

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

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 3 of 28

108 1.2 Namespace

109 The XML namespace [XML-ns] URI that MUST be used by implementations of this specification is: 110 http://docs.oasis-open.org/ws-rx/wsmc/200702 111 Dereferencing the above URI will produce the Resource Directory Description Language [RDDL 2.0]

112 document that describes this namespace.

113 Table 1 lists the XML namespaces that are used in this specification. The choice of any namespace prefix 114 is arbitrary and not semantically significant.

115 Table 1

Prefix Namespace
S (Either SOAP 1.1 or 1.2)
S11 http://schemas.xmlsoap.org/soap/envelope/
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
wsaw http://www.w3.org/2006/05/addressing/wsdl
wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
xs http://www.w3.org/2001/XMLSchema

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

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

119 1.3 Conformance

120 An implementation is not conformant with this specification if it fails to satisfy one or more of the MUST or 121 REQUIRED level requirements defined herein. A SOAP Node MUST NOT use the XML namespace 122 identifier for this specification (listed in Section 1.2) within SOAP Envelopes unless it is conformant with 123 this specification.

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

126

2 MakeConnection Model

127 The WS-Addressing [WS-Addressing] specification defines the anonymous URI to identify non128 addressable endpoints and to indicate a protocol-specific back-channel is to be used for any messages 129 destined for that endpoint. For example, when used in the WS-Addressing ReplyTo EPR, the use of this 130 anonymous URI is meant to indicate that any response message is to be transmitted on the transport131 specific back-channel. In the HTTP case this would mean that any response message is sent back on the 132 HTTP response flow.

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

142 The MakeConnection model consists of a two key aspects:

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

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

148

Optional sharing of MC-Anonymous EPR

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

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

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

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

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

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

167 2.2 Protocol Preconditions

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

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

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

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

175 2.3 Example Message Exchange

176 Figure 2 illustrates a message exchange in which the response message is delivered using 177 MakeConnection.

Non-Addressable Addressable

EndpointMake Connection Protocol Endpoint (MC Initiator) (MC Receiver)

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

Empty Response (HTTP 202)

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

Empty Response (HTTP 202)

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

GetQuoteResponse

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

181 2. The client (MC Initiator) sends a GetQuote request message to the service (MC Receiver). The 182 WS-Addressing wsa:ReplyTo EPR uses the MakeConnection Anonymous URI Template – 183 indicating that if the GetQuoteResponse message is not sent back on this connection's back184 channel, then the client will use MakeConnection to retrieve it.

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

187 4. The client sends a MakeConnection message to the service. Within the MakeConnection element is 188 the wsmc:Address element containing the same MakeConnection Anonymous URI used in step 2.

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

192 6. The client sends a second MakeConnection message to the service. Within the MakeConnection 193 element is the wsmc:Address element containing the same MakeConnection Anonymous URI 194 used in step 2.

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

196 The service can assume that because the MakeConnection Anonymous URI Template was used in the 197 wsa:ReplyTo EPR the client will act as an MC Initiator for the purposes of retrieving messages destined 198 to that EPR (i.e. responses to the GetQuote). This allows the service the option of immediately releasing 199 resources used by the original connection – knowing that the client will, at some later point in time, 200 establish a new connection on which the GetQuoteResponse can be transmitted. Likewise, when the first 201 MakeConnection is received by the service, it again has the option of leaving the connection open until the 202 GetQuoteResponse is ready to be transmitted, or it can close the connection immediately knowing that the 203 MC Initiator will retransmit the MakeConnection message at some later point in time. Since the nature and 204 dynamic characteristics of the underlying transport and potential intermediaries are unknown in the 205 general case, the timing of re-transmissions cannot be specified. Additionally, over-aggressive re206 transmissions have been demonstrated to cause transport or intermediary flooding which are 207 counterproductive. Consequently, implementers are encouraged to utilize adaptive mechanisms that 208 dynamically adjust re-transmission time and the back-off intervals that are appropriate to the nature of the 209 transports and intermediaries envisioned. For the case of TCP/IP transports, a mechanism similar to that 210 described as RTTM in RFC 1323 [RTTM] SHOULD be considered.

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

212

3 MakeConnection

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

215 3.1 MakeConnection Anonymous URI

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

220 http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id={unique-String} 221 The appearance of an instance of this URI template in the wsa:Address value of an EPR indicates a 222 protocol-specific back-channel will be established through a mechanism such as MakeConnection, 223 defined below. When using this URI template, “{unique-String}” MUST be replaced by a globally unique 224 string (e.g a UUID value as defined by RFC4122[UUID]). This specification does not require the use of 225 one particular string generation scheme. This string uniquely distinguishes the Endpoint. A sending 226 Endpoint SHOULD Transmit messages at Endpoints identified with the URI template using a protocol227 specific back-channel, including but not limited to those established with a MakeConnection message. 228 Note, this URI template is semantically similar to the WS-Addressing anonymous URI if a protocol-specific 229 back-channel is available.

230 3.2 MakeConnection Message

231 The MakeConnection element is sent in the body of a one-way message that establishes a 232 contextualized back-channel for the transmission of messages according to matching criteria (defined 233 below). In the non-faulting case, if no matching message is available then no SOAP envelope will be 234 returned on the back-channel. A common usage will be a client sending MakeConnection to a server for 235 the purpose of receiving asynchronous response messages.

236 The following exemplar defines the MakeConnection syntax:

237 <wsmc:MakeConnection ...> 238 <wsmc:Address ...> xs:anyURI </wsmc:Address> ? 239 <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> ? 240 ... 241 </wsmc:MakeConnection> 242 The following describes the content model of the MakeConnectionelement.

243 /wsmc:MakeConnection

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

248 /wsmc:MakeConnection/wsmc:Address

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

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 8 of 28

253 may in fact be functionally equivalent. Examples include URI references which differ only in case, or 254 which are in external entities which have different effective base URIs.

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

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

258 /wsmc:MakeConnection/wsrm:Identifier

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

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

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

266 /wsmc:MakeConnection/{any}

267 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 268 to be passed. This allows fine-tuning of the messages to be returned, additional selection criteria included 269 here are logically ANDed with the Address and/or wsrm:Identifier. If an extension is not supported 270 by the Endpoint then it should generate an UnsupportedSelection fault.

271 /wsmc:MakeConnection/@{any}

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

274 If more than one selection criteria element is present, then the MC Recever processing the 275 MakeConnection message MUST insure that any SOAP Envelope flowing on the back-channel satisfies 276 all of those selection criteria.

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

282 This specification places no constraint on the types of messages that can be returned on the transport283 specific back-channel. As in an asynchronous environment, it is up to the recipient of the 284 MakeConnection message to decide which messages are appropriate for transmission to any particular 285 Endpoint. However, the Endpoint processing the MakeConnection message MUST insure that the 286 messages match the selection criteria as specified by the child elements of the MakeConnection 287 element.

288 Since the message exchange pattern use by MakeConnectionis untraditional, the following points need 289 to be reiterated for clarification:

290 The MakeConnection message is logically part of a one-way operation; there is no reply 291 message to the MakeConnection itself, and any response flowing on the transport back-channel 292 is a pending message.

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

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 9 of 28

295 wsa:ReplyTo element in the MakeConnection message has no effective impact since the WS296 Addressing [reply endpoint] property that is set by the presence of wsa:ReplyTo is not 297 used.

298 In the absence of any pending message, there will be no message transmitted on the transport 299 back-channel. E.g. in the HTTP case just an HTTP 202 Accepted will be returned without any 300 SOAP envelope in the HTTP response message.

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

303 3.3 MessagePending

304 When MakeConnectionis used, and a message is returned on the transport-specific back-channel, the 305 MessagePending header SHOULD be included on the returned message as an indicator whether there 306 are additional messages waiting to be retrieved using the same selection criteria that was specified in the 307 MakeConnection element.

308 The following exemplar defines the MessagePending syntax:

309 <wsmc:MessagePending pending="xs:boolean" ...> 310 ... 311 </wsmc:MessagePending> 312 The following describes the content model of the MessagePendingheader block.

313 /wsmc:MessagePending

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

315 /wsmc:MessagePending@pending

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

318 /wsmc:MessagePending/{any}

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

321 /wsmc:MessagePending/@{any}

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

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

326 3.4 MakeConnection Policy Assertion

327 The MakeConnection policy assertion indicates that the MakeConnection protocol (operation and the use 328 of the MakeConnection URI template in EndpointReferences) is supported. This assertion has Endpoint 329 Policy Subject [WS-PolicyAttachment].

330 The normative outline for the MakeConnection assertion is:

331 <wsmc:MCSupported ...> ... </wsmc:MCSupported>332 The following describes the content model of the MCSupportedelement.

333 /wsmc:MCSupported

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 10 of 28

334 A policy assertion that specifies that the MakeConnection protocol is supported.

335 /wsmc:MCSupported/{any} 336 This is an extensibility mechanism to allow different (extensible) types of information, based on a schema, 337 to be passed.

338 /wsmc:MCSupported/@{any} 339 This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the 340 element.

341 Because this policy assertion expresses a capability of a receiver (rather than a requirement on the 342 sender), care should be taken to ensure that it is decorated with the appropriate WS-Policy artifacts to 343 indicate that use, support and understanding, of this assertion is optional to the sender.

344

4 Faults

345 Entities that generate WS-MakeConnection faults MUST include as the [action] property the default fault 346 action IRI defined below. The value from the W3C Recommendation is below for informational purposes: 347 http://docs.oasis-open.org/ws-rx/wsmc/200702/fault 348 The faults defined in this section are generated if the condition stated in the preamble is met. Fault 349 handling rules are defined in section 6 of WS-Addressing SOAP Binding. 350 The definitions of faults use the following properties: 351 [Code] The fault code. 352 [Subcode] The fault subcode. 353 [Reason] The English language reason element. 354 [Detail] The detail element(s). If absent, no detail element is defined for the fault. If more than one detail 355 element is defined for a fault, implementations MUST include the elements in the order that they are 356 specified. 357 Entities that generate WS-MakeConnection faults MUST set the [Code] property to either "Sender" or 358 "Receiver". These properties are serialized into text XML as follows:

SOAP Version Sender Receiver
SOAP 1.1 S11:Client S11:Server
SOAP 1.2 S:Sender S:Receiver

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

360 <S:Envelope> 361 <S:Header> 362 <wsa:Action> 363 http://docs.oasis-open.org/ws-rx/wsmc/200702/fault 364 </wsa:Action> 365 <!-- Headers elided for brevity. --> 366 </S:Header> 367 <S:Body> 368 <S:Fault> 369 <S:Code> 370 <S:Value> [Code] </S:Value> 371 <S:Subcode> 372 <S:Value> [Subcode] </S:Value> 373 </S:Subcode> 374 </S:Code> 375 <S:Reason> 376 <S:Text xml:lang="en"> [Reason] </S:Text> 377 </S:Reason> 378 <S:Detail> 379 [Detail] 380 ... 381 </S:Detail> 382 </S:Fault> 383 </S:Body> 384 </S:Envelope>

385 The properties bind to a SOAP 1.1 fault as follows when the fault is generated as a result of processing a 386 MakeConnection message:

387 <S11:Envelope>388 <S11:Body>

389 <S11:Fault> 390 <faultcode> [Subcode] </faultcode> 391 <faultstring> [Reason] </faultstring> 392 </S11:Fault> 393 </S11:Body> 394 </S11:Envelope>

395 4.1 Unsupported Selection 396 The QName of the unsupported element(s) are included in the detail. 397 Properties: 398 [Code] Receiver 399 [Subcode] wsmc:UnsupportedSelection 400 [Reason] The extension element used in the message selection is not supported by the MakeConnection

401 receiver 402 [Detail] 403 <wsmc:UnsupportedElement> xs:QName </wsmc:UnsupportedElement>+

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.

404 4.2 Missing Selection

405 The MakeConnection element did not contain any selection criteria. 406 Properties: 407 [Code] Receiver 408 [Subcode] wsmc:MissingSelection 409 [Reason] The MakeConnection element did not contain any selection criteria. 410 [Detail]

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.

411

5 Security Considerations

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

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

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

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

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

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

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

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

436 ● Authentication - Authentication is established using the mechanisms described in WS-Security 437 and WS-Trust. Each message is authenticated using the mechanisms described in WS-Security.

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

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

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

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

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 14 of 28

452 6 References

453 6.1 Normative 454 [KEYWORDS] 455 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, 456 March 1997 457 http://www.ietf.org/rfc/rfc2119.txt 458 [WS-RM] 459 OASIS WS-RX Technical Committee Draft, "Web Services Reliable Messaging (WS-ReliableMessaging)," 460 August 2005. 461 http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-05.pdf 462 [WS-RM Policy] 463 OASIS WS-RX Technical Committee Draft, "Web Services ReliableMessaging Policy Assertion( WS-RM 464 Policy)" February 2007 465 http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-cd-05.pdf 466 [SOAP 1.1] 467 W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000. 468 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ 469 [SOAP 1.2] 470 W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework" June 2003. 471 http://www.w3.org/TR/2003/REC-soap12-part1-20030624/ 472 [URI] 473 T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 3986, 474 MIT/LCS, U.C. Irvine, Xerox Corporation, January 2005. 475 http://ietf.org/rfc/rfc3986 476 [UUID] 477 P. Leach, M. Mealling, R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace," RFC 4122, 478 Microsoft, Refactored Networks - LLC, DataPower Technology Inc, July 2005 479 http://www.ietf.org/rfc/rfc4122.txt 480 [XML] 481 W3C Recommendation, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", September 2006. 482 http://www.w3.org/TR/REC-xml/ 483 [XML-ns] 484 W3C Recommendation, "Namespaces in XML," 14 January 1999.

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 15 of 28

485 http://www.w3.org/TR/1999/REC-xml-names-19990114/ 486 [XML-Schema Part1] 487 W3C Recommendation, "XML Schema Part 1: Structures," October 2004.

488 http://www.w3.org/TR/xmlschema-1/ 489 [XML-Schema Part2] 490 W3C Recommendation, "XML Schema Part 2: Datatypes," October 2004. 491 http://www.w3.org/TR/xmlschema-2/ 492 [XPATH 1.0] 493 W3C Recommendation, "XML Path Language (XPath) Version 1.0," 16 November 1999. 494 http://www.w3.org/TR/xpath 495 [WSDL 1.1] 496 W3C Note, "Web Services Description Language (WSDL 1.1)," 15 March 2001. 497 http://www.w3.org/TR/2001/NOTE-wsdl-20010315 498 [WS-Addressing] 499 W3C Recommendation, “Web Services Addressing 1.0 - Core”, May 2006. 500 http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/ 501 W3C Recommendation, “Web Services Addressing 1.0 – SOAP Binding”, May 2006. 502 http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/

503 6.2 Non-Normative

504 [BSP 1.0] 505 WS-I Working Group Draft. "Basic Security Profile Version 1.0," August 2006

506 http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html 507 [RDDL 2.0] 508 Jonathan Borden, Tim Bray, eds. “Resource Directory Description Language (RDDL) 2.0,” January 2004

509 http://www.openhealth.org/RDDL/20040118/rddl-20040118.html 510 [RFC 2617] 511 J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Loutonen, L. Stewart, "HTTP 512 Authentication: Basic and Digest Access Authentication," June 1999.

513 http://www.ietf.org/rfc/rfc2617.txt 514 [RFC 4346] 515 T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1," April 2006.

516 http://www.ietf.org/rfc/rfc4346.txt 517 [WS-Policy] 518 W3C Member Submission, "Web Services Policy Framework (WS-Policy)," April 2006.

519 http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/ 520 [WS-PolicyAttachment] 521 W3C Member Submission, "Web Services Policy Attachment (WS-PolicyAttachment)," April 2006.

522 http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment523 20060425/ 524 [WS-Security] 525 Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS Web Services Security: 526 SOAP Message Security 1.0 (WS-Security 2004)", OASIS Standard 200401, March 2004. 527 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf 528 Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS Web Services Security: 529 SOAP Message Security 1.1 (WS-Security 2004)", OASIS Standard 200602, February 2006. 530 http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf 531 [RTTM] 532 V. Jacobson, R. Braden, D. Borman, "TCP Extensions for High Performance", RFC 1323, May 533 1992. 534 http://www.rfc-editor.org/rfc/rfc1323.txt

535 [SecurityPolicy] 536 G. Della-Libra, et. al. "Web Services Security Policy Language (WS-SecurityPolicy)", July 2005

537 http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf 538 [SecureConversation] 539 S. Anderson, et al, "Web Services Secure Conversation Language (WS-SecureConversation)," February 540 2005.

541 http://schemas.xmlsoap.org/ws/2004/04/sc/ 542 [Trust] 543 S. Anderson, et al, "Web Services Trust Language (WS-Trust)," February 2005.

544 http://schemas.xmlsoap.org/ws/2005/02/trust

Appendix A. Schema

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

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

549 The following copy is provided for reference.

550 <?xml version="1.0" encoding="UTF-8"?> 551 <!-- 552 OASIS takes no position regarding the validity or scope of any intellectual 553 property or other rights that might be claimed to pertain to the 554 implementation or use of the technology described in this document or the 555 extent to which any license under such rights might or might not be available; 556 neither does it represent that it has made any effort to identify any such 557 rights. Information on OASIS's procedures with respect to rights in OASIS 558 specifications can be found at the OASIS website. Copies of claims of rights 559 made available for publication and any assurances of licenses to be made 560 available, or the result of an attempt made to obtain a general license or 561 permission for the use of such proprietary rights by implementors or users of 562 this specification, can be obtained from the OASIS Executive Director. 563 OASIS invites any interested party to bring to its attention any copyrights, 564 patents or patent applications, or other proprietary rights which may cover 565 technology that may be required to implement this specification. Please 566 address the information to the OASIS Executive Director. 567 Copyright (c) OASIS Open 2002-2007. All Rights Reserved. 568 This document and translations of it may be copied and furnished to others, 569 and derivative works that comment on or otherwise explain it or assist in its 570 implementation may be prepared, copied, published and distributed, in whole or 571 in part, without restriction of any kind, provided that the above copyright 572 notice and this paragraph are included on all such copies and derivative 573 works. However, this document itself does not be modified in any way, such as 574 by removing the copyright notice or references to OASIS, except as needed for 575 the purpose of developing OASIS specifications, in which case the procedures 576 for copyrights defined in the OASIS Intellectual Property Rights document must 577 be followed, or as required to translate it into languages other than English. 578 The limited permissions granted above are perpetual and will not be revoked by 579 OASIS or its successors or assigns. 580 This document and the information contained herein is provided on an "AS IS" 581 basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 582 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 583 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 584 FOR A PARTICULAR PURPOSE. 585 --> 586 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 587 xmlns:wsa="http://www.w3.org/2005/08/addressing" 588 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 589 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 590 targetNamespace="http://docs.oasis-open.org/ws-rx/wsmc/200702" 591 elementFormDefault="qualified" attributeFormDefault="unqualified"> 592 <xs:import namespace="http://www.w3.org/2005/08/addressing" 593 schemaLocation="http://www.w3.org/2006/03/addressing/ws-addr.xsd"/> 594 <xs:import namespace="http://docs.oasis-open.org/ws-rx/wsrm/200702" 595 schemaLocation="http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-schema596 200702.xsd"> 597 <!-- Protocol Elements --> 598 <xs:complexType name="MessagePendingType"> 599 <xs:sequence> 600 <xs:any namespace="##other" processContents="lax" minOccurs="0" 601 maxOccurs="unbounded"/>

602 </xs:sequence> 603 <xs:attribute name="pending" type="xs:boolean"/> 604 <xs:anyAttribute namespace="##other" processContents="lax"/> 605 </xs:complexType> 606 <xs:element name="MessagePending" type="wsmc:MessagePendingType"/> 607 <xs:element name="Address"> 608 <xs:complexType> 609 <xs:simpleContent> 610 <xs:extension base="xs:anyURI"> 611 <xs:anyAttribute namespace="##other" processContents="lax"/> 612 </xs:extension> 613 </xs:simpleContent> 614 </xs:complexType> 615 </xs:element> 616 <xs:complexType name="MakeConnectionType"> 617 <xs:sequence> 618 <xs:element ref="wsmc:Address" minOccurs="0" maxOccurs="1"/> 619 <xs:element ref="wsrm:Identifier" minOccurs="0" maxOccurs="1"/> 620 <xs:any namespace="##other" processContents="lax" minOccurs="0" 621 maxOccurs="unbounded"/> 622 </xs:sequence> 623 <xs:anyAttribute namespace="##other" processContents="lax"/> 624 </xs:complexType> 625 <xs:element name="MakeConnection" type="wsmc:MakeConnectionType"/> 626 <xs:element name="UnsupportedElement"> 627 <xs:simpleType> 628 <xs:restriction base="xs:QName"/> 629 </xs:simpleType> 630 </xs:element> 631 </xs:schema>

632

Appendix B. WSDL

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

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

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

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

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

641 <?xml version="1.0" encoding="utf-8"?>642 <!--643 OASIS takes no position regarding the validity or scope of any intellectual644 property or other rights that might be claimed to pertain to the645 implementation or use of the technology described in this document or the646 extent to which any license under such rights might or might not be available;647 neither does it represent that it has made any effort to identify any such648 rights. Information on OASIS's procedures with respect to rights in OASIS649 specifications can be found at the OASIS website. Copies of claims of rights650 made available for publication and any assurances of licenses to be made651 available, or the result of an attempt made to obtain a general license or652 permission for the use of such proprietary rights by implementors or users of653 this specification, can be obtained from the OASIS Executive Director.654 OASIS invites any interested party to bring to its attention any copyrights,655 patents or patent applications, or other proprietary rights which may cover656 technology that may be required to implement this specification. Please657 address the information to the OASIS Executive Director. 658 Copyright (c) OASIS Open 2002-2007. All Rights Reserved.659 This document and translations of it may be copied and furnished to others,660 and derivative works that comment on or otherwise explain it or assist in its661 implementation may be prepared, copied, published and distributed, in whole or662 in part, without restriction of any kind, provided that the above copyright663 notice and this paragraph are included on all such copies and derivative664 works. However, this document itself does not be modified in any way, such as665 by removing the copyright notice or references to OASIS, except as needed for666 the purpose of developing OASIS specifications, in which case the procedures667 for copyrights defined in the OASIS Intellectual Property Rights document must668 be followed, or as required to translate it into languages other than English.669 The limited permissions granted above are perpetual and will not be revoked by670 OASIS or its successors or assigns.671 This document and the information contained herein is provided on an "AS IS"672 basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT673 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 674 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 675 FOR A PARTICULAR PURPOSE. 676 --> 677 <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"678 xmlns:xs="http://www.w3.org/2001/XMLSchema"679 xmlns:wsa="http://www.w3.org/2005/08/addressing"680 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702"681 xmlns:rm="http://docs.oasis-open.org/ws-rx/wsrm/200702"682 xmlns:tns="http://docs.oasis-open.org/ws-rx/wsmc/200702/wsdl"683 targetNamespace="http://docs.oasis-open.org/ws-rx/wsmc/200702/wsdl">

684 <wsdl:types>685 <xs:schema>

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 20 of 28

686 <xs:import namespace="http://docs.oasis-open.org/ws-rx/wsmc/200702" 687 schemaLocation="http://docs.oasis-open.org/ws-rx/wsmc/200702/wsmc-1.1-schema688 200702.xsd"/> 689 </xs:schema> 690 </wsdl:types>

691 <wsdl:message name="MakeConnection"> 692 <wsdl:part name="makeConnection" element="rm:MakeConnection"/> 693 </wsdl:message>

694 <wsdl:portType name="MCAbstractPortType"> 695 <wsdl:operation name="MakeConnection"> 696 <wsdl:input message="tns:MakeConnection" wsaw:Action="http://docs.oasis697 open.org/ws-rx/wsmc/200702/MakeConnection"/> 698 <!-- As described in the WS-MakeConnection specification, the 699 MakeConnection operation establishes a connection. If a matching 700 message is available then the back-channel of the connection will 701 be used to carry the message. In SOAP terms the returned message 702 is not a response, so there is no WSDL output message. --> 703 </wsdl:operation> 704 </wsdl:portType>

705 </wsdl:definitions>

706 Appendix C. Message Examples

707 Appendix C.1 Example use of MakeConnection

708 To illustrate how a MakeConnection message exchange can be used to deliver messages to an 709 Endpoint that is not addressable, consider the case of a pub/sub scenario in which the Endpoint to which 710 notifications are to be delivered (the "event consumer") is not addressable by the notification sending 711 Endpoint (the "event producer"). In this scenario the event consumer must initiate the connections in order 712 for the notifications to be delivered. One possible set of message exchanges (using HTTP) that 713 demonstrate how this can be achieved using MakeConnectionis shown below.

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

716 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 717 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 718 xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702" 719 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 720 <S:Header> 721 <wsa:To> http://example.org/subscriptionService </wsa:To> 722 <wsa:MessageID> http://client456.org/id-a6d8-a7c2eb546813</wsa:MessageID> 723 <wsa:ReplyTo> 724 <wsa:To> http://client456.org/response </wsa:To> 725 </wsa:ReplyTo> 726 </S:Header> 727 <S:Body> 728 <sub:Subscribe xmlns:sub="http://exaaple.org/subscriptionService"> 729 <!-- subscription service specific data --> 730 <targetEPR> 731 <wsa:Address>http://docs.oasis-open.org/ws732 rx/wsrm/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsa:Address> 733 <wsa:Metadata> 734 <wsp:Policy wsu:Id="MyPolicy"> 735 <wsrmp:RMAssertion/> 736 </wsp:Policy> 737 </wsa:Metadata> 738 </targetEPR> 739 </sub:Subscribe> 740 </S:Body> 741 </S:Envelope> 742 In this example the subscribe and targetEPRelements are simply examples of what a subscription 743 request message might contain. Note: the wsa:Addresselement contains the MC anonymous URI 744 indicating that the notification producer needs to queue the messages until they are requested using the 745 MakeConnection message exchange. The EPR also contains the WS-RM Policy Assertion indicating 746 the RM must be used when notifications related to this subscription are sent.

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

748 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 749 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 750 xmlns:wsa="http://www.w3.org/2005/08/addressing">751 <S:Header> 752 <wsa:Action>http://docs.oasis-open.org/ws753 rx/wsmc/200702/MakeConnection</wsa:Action>754 <wsa:To> http://example.org/subscriptionService </wsa:To>

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 22 of 28

755 </S:Header> 756 <S:Body> 757 <wsmc:MakeConnection> 758 <wsmc:Address>http://docs.oasis-open.org/ws759 rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716760 446655440000</wsmc:Address> 761 </wsmc:MakeConnection> 762 </S:Body> 763 </S:Envelope>

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

767 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 768 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 769 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 770 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 771 <S:Header> 772 <wsa:Action>http://docs.oasis-open-org/ws773 rx/wsrm/200702/CreateSequence</wsa:Action> 774 <wsa:To>http://docs.oasis-open.org/ws775 rx/wsrm/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsa:To> 776 <wsa:ReplyTo> http://example.org/subscriptionService </wsa:ReplyTo> 777 <wsa:MessageID> http://example.org/id-123-456 </wsa:MessagID> 778 <wsmc:MessagePending pending="true"/> 779 </S:Header> 780 <S:Body> 781 <wsrm:CreateSequence> 782 <wsrm:AcksTo> 783 <wsa:Address> http://example.org/subscriptionService </wsa:Address> 784 </wsrm:AcksTo> 785 </wsrm:CreateSequence> 786 </S:Body> 787 </S:Envelope> 788 Notice from the perspective of how the RM Source on the event producer interacts with the RM 789 Destination of those messages, nothing new is introduced by the use of the MakeConnection, the use 790 of RM protocol is the same as the case where the event consumer is addressable. Note the message 791 contains a wsmc:MessagePending header indicating that additional message are waiting to be 792 delivered.

793 Step 4 – The event consumer will respond with a CreateSequenceResponse message per normal WS794 Addressing rules:

795 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 796 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 797 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 798 <S:Header> 799 <wsa:Action>http://docs.oasis-open-org/ws800 rx/wsrm/200702/CreateSequenceResponse</wsa:Action> 801 <wsa:To> http://example.org/subscriptionService </wsa:To> 802 <wsa:RelatesTo> http://example.org/id-123-456 </wsa:RelatesTo> 803 </S:Header> 804 <S:Body> 805 <wsrm:CreateSequenceResponse> 806 <wsrm:Identifier> http://example.org/rmid-456 </wsrm:Identifier> 807 </wsrm:CreateSequenceResponse> 808 </S:Body> 809 </S:Envelope>

wsmc-1.0-spec-cd-05 1 February 2007 Copyright © OASIS Open 2007. All Rights Reserved. Page 23 of 28

810 Note, this message is carried on an HTTP request directed to the wsa:ReplyTo EPR, and the HTTP 811 response will be an HTTP 202.

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

813 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 814 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 815 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 816 <S:Header> 817 <wsa:Action>http://docs.oasis-open.org/ws818 rx/wsmc/200702/MakeConnection</wsa:Action> 819 <wsa:To> http://example.org/subscriptionService </wsa:To> 820 </S:Header> 821 <S:Body> 822 <wsmc:MakeConnection> 823 <wsmc:Address>http://docs.oasis-open.org/ws824 rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716825 446655440000</wsmc:Address> 826 </wsmc:MakeConnection> 827 </S:Body> 828 </S:Envelope> 829 Notice this is the same message as the one sent in step 2.

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

831 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 832 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 833 xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702" 834 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 835 <S:Header> 836 <wsa:Action> http://example.org/eventType1 </wsa:Action> 837 <wsa:To>http://docs.oasis-open.org/ws838 rx/wsrm/200702/anonymous?id=550e8400-e29b-11d4-a716-446655440000</wsa:To> 839 <wsrm:Sequence> 840 <wsrm:Identifier> http://example.org/rmid-456 </wsrm:Identifier> 841 </wsrm:Sequence> 842 <wsmc:MessagePending pending="true"/> 843 </S:Header> 844 <S:Body> 845 <!-- event specific data --> 846 </S:Body> 847 </S:Envelope> 848 As noted in step 3, the use of the RM protocol does not change when using MakeConnection. The 849 format of the messages, the order of the messages sent and the timing of when to send it remains the 850 same.

851 Step 7 – At some later interval, or immediately due to the MessagePendingheader's "pending" 852 attribute being set to "true", the event consumer will poll again:

853 <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 854 xmlns:wsmc="http://docs.oasis-open.org/ws-rx/wsmc/200702" 855 xmlns:wsa="http://www.w3.org/2005/08/addressing"> 856 <S:Header> 857 <wsa:Action>http://docs.oasis-open.org/ws858 rx/wsmc/200702/MakeConnection</wsa:Action> 859 <wsa:To> http://example.org/subscriptionService </wsa:To> 860 </S:Header> 861 <S:Body>

862 <wsmc:MakeConnection> 863 <wsmc:Address>http://docs.oasis-open.org/ws864 rx/wsmc/200702/anonymous?id=550e8400-e29b-11d4-a716865 446655440000</wsmc:Address> 866 </wsmc:MakeConnection> 867 </S:Body> 868 </S:Envelope> 869 Notice this is the same message as the one sent in steps 2 and 5. As in steps 3 and 6, the response to 870 the MakeConnection can be any message destined to the specified Endpoint. This allows the event 871 producer to send not only application messages (events) but RM protocol messages (e.g. 872 CloseSequence, TerminateSequence or even additional CreateSequences) as needed.

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

876

Appendix D. Acknowledgments

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

878 Keith Ballinger(Microsoft), Stefan Batres(Microsoft), Rebecca Bergersen(Iona), Allen Brown 879 (Microsoft), Kyle Brown(IBM), Michael Conner(IBM), George Copeland(Microsoft), Francisco 880 Curbera(IBM), Paul Fremantle(IBM), Steve Graham(IBM), Pat Helland(Microsoft), Rick Hill 881 (Microsoft), Scott Hinkelman(IBM), Tim Holloway(IBM), Efim Hudis(Microsoft), David Ingham 882 (Microsoft), Gopal Kakivaya(Microsoft), Johannes Klein(Microsoft), Frank Leymann(IBM), Martin 883 Nally(IBM), Peter Niblett(IBM), Jeffrey Schlimmer(Microsoft), James Snell(IBM), Keith Stobie 884 (Microsoft), Satish Thatte(Microsoft), Stephen Todd(IBM), Sanjiva Weerawarana(IBM), Roger 885 Wolter(Microsoft).

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

887 Abbie Barbir(Nortel), Charlton Barreto(Adobe), Stefan Batres(Microsoft), Hamid Ben Malek 888 (Fujitsu), Andreas Bjarlestam(Ericsson), Toufic Boubez(Layer 7), Doug Bunting(Sun), Lloyd Burch 889 (Novell), Steve Carter(Novell), Martin Chapman(Oracle), Dave Chappell(Sonic), Paul Cotton 890 (Microsoft), Glen Daniels(Sonic), Doug Davis(IBM), Blake Dournaee(Intel), Jacques Durand 891 (Fujitsu), Colleen Evans(Microsoft), Christopher Ferris(IBM), Paul Fremantle(WSO2), Robert 892 Freund(Hitachi), Peter Furniss(Erebor), Marc Goodner(Microsoft), Alastair Green(Choreology), 893 Mike Grogan(Sun), Ondrej Hrebicek(Microsoft), Kazunori Iwasa(Fujitsu), Chamikara Jayalath 894 (WSO2), Lei Jin(BEA), Ian Jones(BTplc), Anish Karmarkar(Oracle), Paul Knight(Nortel), Dan 895 Leshchiner(Tibco), Mark Little(JBoss), Lily Liu(webMethods), Matt Lovett(IBM), Ashok Malhotra 896 (Oracle), Jonathan Marsh(Microsoft), Daniel Millwood(IBM), Jeff Mischkinsky(Oracle), Nilo Mitra 897 (Ericsson), Peter Niblett(IBM), Duane Nickull(Adobe), Eisaku Nishiyama(Hitachi), Dave Orchard 898 (BEA), Chouthri Palanisamy(NEC), Sanjay Patil(SAP), Gilbert Pilz(BEA), Martin Raepple(SAP), 899 Eric Rajkovic(Oracle), Stefan Rossmanith(SAP), Tom Rutt(Fujitsu), Rich Salz(IBM), Shivajee 900 Samdarshi(Tibco), Vladimir Videlov(SAP), Claus von Riegen(SAP), Pete Wenzel(Sun), Steve 901 Winkler(SAP), Ümit Yalçinalp(SAP), Nobuyuki Yamamoto(Hitachi).

Appendix E. Revision History

Rev Date By Whom What
wd-01 2006-12-31 Doug Davis Initial version created based on MakeConnection support in the WS-RM spec
wd-02 2007-01-31 Doug Davis Lots of typos from MarcG Updated WD number and date
wd-02 2007-02-01 Doug Davis PR015 and PR029 applied

903

Appendix F. Notices

904 OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 905 might be claimed to pertain to the implementation or use of the technology described in this document or 906 the extent to which any license under such rights might or might not be available; neither does it represent 907 that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to 908 rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made 909 available for publication and any assurances of licenses to be made available, or the result of an attempt 910 made to obtain a general license or permission for the use of such proprietary rights by implementors or 911 users of this specification, can be obtained from the OASIS Executive Director.

912 OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or 913 other proprietary rights which may cover technology that may be required to implement this specification. 914 Please address the information to the OASIS Executive Director.

915 Copyright (C) OASIS Open (2007). All Rights Reserved.

916 This document and translations of it may be copied and furnished to others, and derivative works that 917 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and 918 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and 919 this paragraph are included on all such copies and derivative works. However, this document itself may 920 not be modified in any way, such as by removing the copyright notice or references to OASIS, except as 921 needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights 922 defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it 923 into languages other than English.

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

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