OASIS Openopen access

WS-Reliability v1.1 (2004-11-01)

OASIS Open · OASIS Open

OASIS Open · Standards · License: Open Access

oasis, standard, oasis open, specification, open standard, oasis_wsrm-ws_reliability-1.1-spec-os, ws-reliability, v1.1, wsrm-ws_reliability-1.1-spec-os, wsrm, ws, reliability, spec, os, 1.1

Web Services Reliable Messaging TC 3 WS-Reliability 1.1 2

OASIS Standard, 15 November 2004

5 6

Document identifier: wsrm-ws_reliability-v1.1-spec-os

7 8

Location: http://docs.oasis-open.org/wsrm/ws-reliability/v1.1

9 10 11 12 13 14 15 16 17

Editors: Principal editor: Kazunori Iwasa, Fujitsu Limited <[email protected]> Assisting editors: Jacques Durand, Fujitsu Software Corporation <[email protected]> Tom Rutt, Fujitsu Software Corporation <[email protected]> Mark Peel, Novell, Inc. <[email protected]> Sunil Kunisetty, Oracle Corporation <[email protected]> Doug Bunting, Sun Microsystems <[email protected]>

18 19 20 21 22

Abstract: Web Services Reliability (WS-Reliability) is a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicates, and guaranteed message ordering. WS-Reliability is defined as SOAP header extensions and is independent of the underlying protocol. This specification contains a binding to HTTP.

23 24

Status: This document is an OASIS Standard.

25 26 27

Committee members should send comments on this specification to the [email protected] list. Others should use the comment form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=wsrm.

28 29 30 31

For information on whether any patents that may be essential to implementing this specification have been disclosed and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Web Services Reliable Messaging TC web page (http://www.oasis-open.org/committees/wsrm/).

32 33

If necessary, the errata page for this version of of the specification will be located at http://www.oasis-open.org/committees/wsrm/documents/errata/1.1/index.html.

15 November 2004 Page 1 of 72

Table of Contents

1 Introduction.....................................................................................................................................6

1.1 Purpose of WS-Reliability.......................................................................................................6

1.2 Definition and Scope of Reliable Messaging..........................................................................6

1.3 Notational Conventions..........................................................................................................7

1.4 Relation to Other Specifications.............................................................................................8

1.5 Terminology............................................................................................................................9

2 Messaging Model.........................................................................................................................11

2.1 Messaging Context...............................................................................................................11

2.2 RMP Operations and Their Invocation.................................................................................11

2.2.1 Binding between WSDL Operation Types and RMP Invocations.................................12

2.3 Assumed SOAP Message Exchange Patterns....................................................................12

2.4 Message Reply Patterns......................................................................................................13

2.4.1 Response RM-Reply Pattern........................................................................................13

2.4.2 Callback RM-Reply Pattern...........................................................................................14

2.4.3 Poll RM-Reply Pattern...................................................................................................14

2.5 Message Identification and Grouping...................................................................................15

3 Reliability Agreement and Features.............................................................................................16

3.1 RM Agreement......................................................................................................................16

3.1.1 Definition........................................................................................................................16

3.1.2 RM Agreement Items....................................................................................................16

3.1.3 Scope of an Agreement Item........................................................................................17

3.1.4 Rules.............................................................................................................................18

3.1.5 Creation, Representation and Deployment of RM Agreements...................................18

3.1.6 RM Capability................................................................................................................18

3.2 Main Reliability Features......................................................................................................18

3.2.1 Guaranteed Delivery.....................................................................................................19

3.2.2 Duplicate Elimination.....................................................................................................19

3.2.3 Guaranteed Message Ordering....................................................................................20

4 Message Format..........................................................................................................................21

4.1 Structure...............................................................................................................................21

4.2 Request Element..................................................................................................................23

4.2.1 Element: Request/MessageId.......................................................................................24

4.2.2 Element: Request/ExpiryTime.......................................................................................26

4.2.3 Element: Request/ReplyPattern....................................................................................27

15 November 2004 Page 2 of 72

4.2.4 Element: Request/AckRequested.................................................................................28

4.2.5 Element: Request/DuplicateElimination........................................................................29

4.2.6 Element: Request/MessageOrder.................................................................................29

4.2.7 Example.........................................................................................................................29

4.3 PollRequest Element............................................................................................................30

4.3.1 Element: PollRequest/ReplyTo.....................................................................................31

4.3.2 Element: PollRequest/RefToMessageIds.....................................................................32

4.3.3 Example.........................................................................................................................33

4.4 Response Element...............................................................................................................34

4.4.1 Element: Response/NonSequenceReply.....................................................................35

4.4.2 Element: Response/SequenceReplies.........................................................................36

4.4.3 Example.........................................................................................................................37

4.5 Fault Codes For Reliable Messaging Failures.....................................................................37

4.5.1 Message Format Faults................................................................................................38

4.5.2 Message Processing Faults..........................................................................................40

4.5.3 RM Fault Examples.......................................................................................................41

4.6 Extensibility Features of Schema.........................................................................................41

5 Operational Aspects and Semantics............................................................................................43

5.1 Message Group Life Cycle...................................................................................................43

5.1.1 Group Termination........................................................................................................43

5.1.2 Group Termination Parameters....................................................................................44

5.1.3 Termination Rules.........................................................................................................45

5.2 Attachments..........................................................................................................................48

6 HTTP Binding...............................................................................................................................49

6.1 Reliable Messaging with Response RM-Reply Pattern.......................................................50

6.2 Reliable Messaging with Callback RM-Reply Pattern..........................................................52

6.3 Reliable Messaging with Poll RM-Reply Pattern..................................................................54

6.3.1 Synchronous Poll RM-Reply Pattern............................................................................54

6.3.2 Asynchronous Poll RM-Reply Pattern...........................................................................56

7 Conformance................................................................................................................................59

8 References...................................................................................................................................60

100

Appendix A. Schema (Normative)...................................................................................................62

101

Appendix B. WS-Reliability Features, Properties and Compositors (Normative and Optional).....63

102

B.1. Introduction..........................................................................................................................63

103

B.2. Conformance.......................................................................................................................63

104

B.3. WSDL Extensibility Elements..............................................................................................64

105

B.3.1. Compositor...................................................................................................................64

15 November 2004 Page 3 of 72

106

B.3.2. Feature.........................................................................................................................65

107

B.3.3. Property........................................................................................................................66

108

B.4. WS-Reliability Feature.........................................................................................................66

109

B.5. WS-Reliability Properties....................................................................................................66

110

B.5.1. Guaranteed Delivery Property.....................................................................................66

111

B.5.2. Duplicate Elimination Property.....................................................................................66

112

B.5.3. Message Ordering Property.........................................................................................66

113

B.5.4. Reply Pattern Property.................................................................................................67

114

B.6. Compositor Examples.........................................................................................................67

115

B.6.1. Example for the "all" compositor..................................................................................67

116

B.6.2. Example for the "choice" compositor:..........................................................................68

117

B.6.3. Example for the "one-or-more" compositor:................................................................69

118

B.6.4. Example for the "zero-or-more" compositor:...............................................................69

119

Appendix C. Acknowledgments......................................................................................................70

120

Appendix D. Notices........................................................................................................................72

15 November 2004 Page 4 of 72

121

List of Tables

122

Table 1 Labels...................................................................................................................................8

123

Table 2 Prefixes................................................................................................................................8

124

Table 3 RM Agreement Items.........................................................................................................17

125

Table 4 Request Element...............................................................................................................23

126

Table 5 MessageId Element...........................................................................................................24

127

Table 6 SequenceNum Element.....................................................................................................25

128

Table 7 ExpiryTime Element...........................................................................................................26

129

Table 8 ReplyPattern Element........................................................................................................27

130

Table 9 Value Element....................................................................................................................27

131

Table 10 ReplyTo Element.............................................................................................................28

132

Table 11 BareURI Element.............................................................................................................28

133

Table 12 AckRequested Element...................................................................................................29

134

Table 13 DuplicateElimination Element..........................................................................................29

135

Table 14 MessageOrder Element...................................................................................................29

136

Table 15 PollRequest Element.......................................................................................................31

137

Table 16 ReplyTo Element.............................................................................................................31

138

Table 17 BareURI Element.............................................................................................................32

139

Table 18 RefToMessageIds Element.............................................................................................32

140

Table 19 SequenceNumRange Element........................................................................................33

141

Table 20 Response Element...........................................................................................................35

142

Table 21 NonSequenceReply Element...........................................................................................35

143

Table 22 SequenceReplies Element..............................................................................................36

144

Table 23 ReplyRange Element.......................................................................................................36

145

Table 24 Invalid Message Format Fault Code Values....................................................................39

146

Table 25 Messaging Processing Failure Fault Code Values..........................................................40

147

Table 26 Conditions for terminating a group – Receiving RMP.....................................................48

148

Table 27 Conditions for terminating a group – Sending RMP........................................................48

149

Table 28 WS-Reliability Schema Prefixes......................................................................................62

15 November 2004 Page 5 of 72

150

1 Introduction

151

1.1 Purpose of WS-Reliability

152 153 154 155 156 157 158

WS-Reliability is a SOAP-based ([SOAP 1.1] and [SOAP 1.2 Part 1]) specification that fulfills reliable messaging requirements critical to some applications of Web Services. SOAP over HTTP [RFC2616] is not sufficient when an application-level messaging protocol must also guarantee some level of reliability and security. This specification defines reliability in the context of current Web Services standards. This specification has been designed for use in combination with other complementary protocols (see Section 1.4) and builds on previous experiences (e.g., ebXML Message Service [ebMS].)

159

1.2 Definition and Scope of Reliable Messaging

160 161 162

Reliable Messaging (RM) is the execution of a transport-agnostic, SOAP-based protocol providing quality of service in the reliable delivery of messages. There are two aspects to Reliable Messaging; both must be equally addressed when specifying RM features:

163 164

(1) The “wire” protocol aspect. RM is a protocol, including both specific message headers and specific message choreographies, between a sending party and a receiving party.

165 166 167 168 169

(2) The quality of service (QoS) aspect. RM defines a quality of messaging service to the communicating parties, viz., the users of the messaging service. This assumes a protocol between these users and the provider of this service (i.e., the reliable messaging middleware). This protocol is defined by a set of abstract operations: Submit, Deliver, Notify, Respond (defined in Section 1.5).

170

Reliable messaging requires the definition and enforcement of contracts between:

171

•

The Sending and Receiving message processors (contracts about the wire protocol)

172

•

The messaging service provider and the users of the messaging service (contracts about quality of service).

173 174

Each major RM feature will be defined as a composition of these two types of contract.

175 176 177 178 179

Example: Guaranteed message delivery is defined as both (1) a messaging protocol involving Acknowledgment Indications and specific message headers and (2) as a rule guaranteeing if “Submit” completes successfully for a payload on the sending side, “Deliver” completes successfully for this payload on the receiving side or “Notify” (of failure) will be invoked on the sending side.

180 181 182 183 184

Figure 1 shows all of the reliability contracts (both QoS and protocol) binding the Reliable Messaging entities (a producer of reliable messages, a consumer of reliable messages, and the two Reliable Messaging Processors or RMPs). The direction of the arrows for the QoS contract abstract operations, shown in Figure 1, represents the direction of information flow associated with the operation.

185

Note:

186 187 188 189 190 191

This specification does not make any assumption about the implementation of a messaging service user component (Producer or Consumer components in Figure 1): such a component could be an application, a queuing or logging system, a database, a SOAP node, or the next handler in the message processing chain. The QoS contracts concern only the conditions of invocation of the “Deliver”, “Submit”, “Respond” and “Notify” operations. The interpretation of these operations is a matter of implementation.

15 November 2004 Page 6 of 72

Figure 1 Reliable Messaging Contracts 192

The current specification defines the following reliability features:

193

•

Guaranteed message delivery, or At-Least-Once delivery semantics.

194

•

Guaranteed message duplicate elimination, or At-Most-Once delivery semantics.

195

•

Guaranteed message delivery and duplicate elimination, or Exactly-Once delivery semantics.

•

Guaranteed message ordering for delivery within a group of messages.

196

197 198

199

Some messaging features are out of scope for this specification. They are: •

Routing features. This specification addresses end-to-end reliability and is not concerned with intermediaries. The mechanisms described are orthogonal to routing techniques and can be used in combination with them.

•

Transactions. Transactional messaging ensures the integrity of exchange patterns that involve possibly several messages. Failure conditions may involve application-level decisions based on message payload interpretation. This specification is concerned with the reliability of individual messages from submission to delivery; it ignores any interpretation of these messages.

200 201

202 203 204 205 206 207 208 209 210

Reliability is often associated with quantitative measures in QoS areas other than Web services (e.g., networking). Thresholds such as rate of failures, minimal size of persistent store, average latency, and quantitative measures that may appear in service level agreements (SLAs) are out of scope for this version.

211

1.3 Notational Conventions

212 213 214 215 216

This document occasionally uses terms that appear in capital letters. When the terms "MUST", “REQUIRED”, “SHALL”, "SHOULD", "RECOMMENDED", “MAY”, “OPTIONAL”, "MUST NOT", “NOT REQUIRED”, “SHALL NOT” and "SHOULD NOT" appear capitalized, they are being used to indicate particular requirements of this specification. An interpretation of the meanings of these terms appears in [RFC2119].

217

All text in this specification is normative, except the following:

218

•

examples

219

•

notes (identified with a preceding “Note” header)

15 November 2004 Page 7 of 72

220 221 222

•

appendices not explicitly identified as normative

Section 4 includes tables to explain each message header element. The meaning of the labels in these tables is as follows: Label

Meaning

Cardinality

A constraint on the number of instances of the element, as allowed in its enclosing element (e.g., “0 or 1” means means the element may be either absent or present only once in its enclosing element).

Value

A type or format for a value of the element.

Attributes

Attribute names for the element. The type or format for the attribute value is included in parentheses.

Child elements

Elements allowed as direct descendants of the element. Table 1 Labels

223

This specification uses the following namespace prefixes: Prefix

Namespace

soap

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

soap12

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

wsrm

http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd

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

wsdl11

http://schemas.xmlsoap.org/wsdl/

fnp

http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd

wsrmfp

http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd

ref

http://docs.oasis-open.org/wsrm/2004/06/reference-1.1.xsd Table 2 Prefixes

224

The choice of any namespace prefix is arbitrary and not semantically significant.

225

XPath [XPath 1.0] is used to refer to header elements, in particular in Section 4.

226

1.4 Relation to Other Specifications

227

•

W3C SOAP 1.1/1.2: SOAP 1.1 [SOAP 1.1] and SOAP 1.2 [SOAP 1.2 Part 1] are the base protocols for this specification. This specification defines reliable messaging protocol features expressed as extension header blocks embedded in the SOAP Header.

•

OASIS ebXML Message Service Specification 2.0: The reliable messaging mechanism defined in the ebXML Message Service Specification 2.0 [ebMS] is implemented in a number of products and open source efforts, many of which have undergone interoperability testing. WS-Reliability borrows from this technology.

228 229 230

231 232 233 234

15 November 2004 Page 8 of 72

235

•

OASIS Web Services Security: SOAP Message Security 1.0: This specification defines reliability independently from security, each of these features mapping to different SOAP header extensions. Although both features can be used in combination, the specification does not attempt to compose them in a more intricate way, nor does it attempt to profile their combination. This specification can be used with OASIS Web Services Security: SOAP Message Security 1.0 [WSS].

•

WS-I Basic Profile 1.1: This specification defines how to use reliability in compliance with WS-I Basic Profile 1.1 [WS-I BP 1.1].

236 237 238 239 240

241 242

243

1.5 Terminology

244 245

Some of these definitions may reference other definitions, either within or outside of the terminology section.

246

Reliable Messaging (RM):

247 248 249

The act of processing the set of transport-agnostic SOAP Features defined by WS-Reliability, which results in a protocol supporting quality of service features such as guaranteed delivery, duplicate message elimination, and message ordering.

250

Reliable Messaging Processor (RMP):

251 252 253 254

A SOAP processor and other infrastructure capable of performing Reliable Messaging as described by this specification. With regard to the transmission of a Reliable Message from one RMP to another, the former is referred to as the Sending RMP and the latter as the Receiving RMP. An RMP may act in both roles.

255

Reliable Message:

256

A SOAP message containing a <wsrm:Request> header block.

257

Payload:

258 259

A subset of the message data intended for the Consumer or Producer of the Reliable Message and provided by the Producer or Consumer respectively.

260

Producer (or Payload Producer)

261 262

An abstract component that produces the payload of a message to be sent. An example of a Producer is an application component able to invoke an RMP to send a payload.

263

Consumer (or Payload Consumer)

264 265 266

An abstract component that consumes the payload of a received message after it has been processed by the Receiving RMP. Examples of Consumers are: an application component called back when a message is received, a queuing device storing received payloads.

267

Deliver:

268

An abstract operation that transfers a payload from Receiving RMP to Consumer.

269

Submit:

270 271

An abstract operation that transfers a payload from Producer to Sending RMP – for example, a request to the Sending RMP to handle the payload subject to a reliability agreement.

272

Respond:

273 274

An abstract operation that transfers a payload from Consumer to Receiving RMP as a response to a previously received Reliable Message.

15 November 2004 Page 9 of 72

275

Notify:

276 277 278

An abstract operation that makes available to the Producer a failure status of a previously sent message (e.g., a notification the Sending RMP failed to send a Reliable Message) or transfers a payload received as a response from Sending RMP to Producer.

279

RMP Operations:

280 281 282 283

Deliver, Submit, Respond and Notify are also called “RMP operations”. These abstract operations control the transfer of payload data (and, in one case, failure information) between the RMP and a user component (Producer or Consumer). An RMP operation is not necessarily implemented by an RMP, but it must be either supported in some way by an RMP or invoked by the RMP.

284

Message Identifier:

285 286

A message header value or a combination of message header values that uniquely identifies a Reliable Message. This identifier is meaningful only to the reliability features described here.

287

Duplicate Message:

288

A message is a duplicate of another message if it has same Message Identifier.

289

Message Delivery:

290

Completion of the Deliver operation for a Reliable Message.

291

Acknowledgment Indication:

292 293 294 295

An indication that refers to a previous message delivered by the Receiving RMP. An Acknowledgment Indication signals that the acknowledged message has been successfully delivered (that is, the message has satisfied all of the reliability requirements placed on it for delivery).

296

Reliable Messaging Fault Indication (RM Fault):

297 298 299

An indication referring to a previous message that encountered a Reliable Messaging fault condition at the Receiving RMP: it signals to the Sending RMP of the referred message that there was a failure to invoke the Deliver operation for the message.

300

Reliable Messaging Reply (RM-Reply):

301 302

An indication – either an Acknowledgment Indication or a Reliable Messaging Fault Indication – referring to a previous Reliable Message.

303

Response, Callback and Poll RM-Reply Patterns:

304

See Section 2.5.

305

PollRequest Message:

306 307

A message from the Sending RMP to the Receiving RMP that requests RM-Replies for its identified set of previously sent Reliable Messages.

308

Intermediary:

309

A SOAP node between a Sending RMP and a Receiving RMP.

310

Publish (an RM-Reply):

311 312 313

The set of mechanisms that make an RM-Reply available to the Sending RMP. The particular mechanism used for a given Publish operation depends on the RM-Reply Pattern (Section 2.5) requested within the Reliable Message that elicited the Publish.

15 November 2004 Page 10 of 72

314

2 Messaging Model

315

2.1 Messaging Context

316 317

The Reliable Messaging Model described in this document makes the following assumptions about SOAP messaging and its relation to the RMP behavior:

318

•

Intermediary transparency. SOAP Intermediaries do not play any active role in the reliability mechanisms. They can be abstracted from the communication between Sending RMP and Receiving RMP: the RMPs are the only parties involved in implementing the RM protocol (e.g., for handling RM-Replies). There is no role for an RMP other than Receiving RMP or Sending RMP. Figure 2 illustrates this model.

•

Message integrity. For the reliability mechanisms described here to fulfill the reliability contract, this specification strongly RECOMMENDS that message header integrity be guaranteed end-to-end by using adequate security options such as those described in Web Services Security: SOAP Message Security 1.0 [WSS].

319 320 321 322

323 324 325 326

Producer Submit

Consumer

Notify

Deliver

Respond

(Reliable Message)

Sending RMP

Receiving RMP ( RM-Reply) (Respond Payload)

Figure 2 Messaging Model

327

2.2 RMP Operations and Their Invocation

328 329

Four operations (Submit, Deliver, Respond and Notify) are used to model the reliability contracts between an RMP and its users (Producer and Consumer components).

330 331 332 333 334 335

These operations and executable components are defined abstractly to simplify discussion of the WS-Reliability protocol, not to imply a particular API or component separation. No requirement is made herein about how these operations should be implemented, which component should implement them, or whether an implementation should explicitly represent them. The operations themselves describe a transfer of information (payload or failure notice) between an RMP and associated external components (Producer, Consumer).

336 337 338 339

The separations assumed here between the RMPs and their external components indicate the expected value of placing WS-Reliability support within an infrastructure component. However, any implementation choice leading to the externally observable properties describe in this specification is equally valid.

15 November 2004 Page 11 of 72

340 341 342 343 344 345 346

For example, a Receiving RMP could put a received payload in a queue; later, an application component gets the payload from that queue. This situation could be modeled in two different ways: (1) the queuing middleware is the Consumer, in which case the delivery is over when the payload is placed in the queue, (2) the application component is the Consumer, in which case the delivery is over when the payload is read by the application. Note that the reliability contracts will differ in each case and that it is an implementation choice to decide the precise point at which the reliability contract is considered fulfilled.

347

The following requirements are associated with the use of RMP operations: •

For every valid and non-expired message it receives, a Receiving RMP MUST invoke the Deliver operation after the associated reliability requirements (ordering, duplicate elimination) have been satisfied.

•

The Sending RMP is NOT REQUIRED to invoke the Notify operation for communicating the status of every Reliable Message to a Producer. Only the failure status and available Consumer payload cases need be reported.

•

355 356 357

An invocation of Deliver is not always matched by an invocation of Respond; the Consumer is NOT REQUIRED to invoke Respond for every Reliable Message delivered. A Receiving RMP MUST be capable of mapping a pair of Deliver and Respond invocations to an instance of SOAP Request-response MEP (See 2.3)

358 359

The basic exchange patterns described in the following section derive from the above messaging assumptions. Reliability features defined in this specification will in turn rely on these patterns.

360

2.2.1 Binding between WSDL Operation Types and RMP Invocations

361 362 363 364 365

This specification supports Reliable Messaging capabilities for WSDL 1.1 [WSDL 1.1] One-way and Request-response operation types only. That is, a WSDL instance describing the Consumer interface would use one of these two operations. Assuming a Sending RMP (or S-RMP) and a Receiving RMP (or R-RMP), the operations in such a WSDL instance MUST bind with the RMP operations in the following way:

348 349 350

351 352 353

354

366

•

A successful WSDL One-way operation maps to a sequence of RMP invocations of the form: S-RMP.Submit(p) + R-RMP.Deliver(p), where (p) is the payload sent in the request (input message) of the operation described in WSDL.

•

A successful WSDL Request-response operation maps to a sequence of RMP invocations of the form: S-RMP.Submit(p) + R-RMP.Deliver(p) + R-RMP.Respond(p2) + S-RMP.Notify(p2), where (p) is the payload sent in the request and (p2) is the payload returned in the response (output message) of the operation described in WSDL.

367 368

369 370 371 372

373

2.3 Assumed SOAP Message Exchange Patterns

374 375 376 377 378 379 380 381 382

Although SOAP [SOAP 1.1] was initially defined as a one-way messaging protocol, support for other exchange patterns [SOAP 1.1], message exchange patterns (MEPs) [SOAP 1.2 Part 2], and operations [WSDL 1.1] has been described. For example, SOAP over HTTP was principally described in terms of a request-response exchange pattern in [SOAP 1.1], bound to either Oneway or Request-response operations in [WSDL 1.1] and restricted (especially with regard to the meaning of a One-way operation) in [WS-I BP 1.1]. Described below are two MEPs – called here SOAP MEPs – of interest for the RM features specified herein and derived from the terminology in those specifications. We use these terms to describe how the RMPs send and receive SOAP messages over the underlying transfer protocol.

383 384 385

An RMP MUST know which SOAP MEP is in use when sending or receiving a Reliable Message. A WSDL instance is just one way among many to specify to an RMP a message's binding to a SOAP MEP.

15 November 2004 Page 12 of 72

386

SOAP One-way MEP:

387

From an RMP perspective, support for this MEP assumes the following:

388

•

The Sending RMP (as a SOAP node) is able to initiate the sending of a SOAP envelope over the underlying protocol (i.e., not as a result of a previous protocol action such as an HTTP GET or POST).

•

No response containing a SOAP envelope is sent back – although a non-SOAP response (e.g., an HTTP error code) may be returned.

389 390

391 392

393

SOAP Request-response MEP:

394

From an RMP perspective, support for this MEP assumes the following:

395

•

The Sending RMP is able to initiate the sending of a SOAP envelope over the underlying protocol.

•

The Receiving RMP can send back a message with a SOAP envelope (called a response) after somehow associating the response with the request.

396

397 398

399

2.4 Message Reply Patterns

400

There are three ways to publish an RM-Reply (Acknowledgment Indication or Fault Indication):

401

2.4.1 Response RM-Reply Pattern

402 403

When the Response RM-Reply Pattern is in use, the following sequence of exchanges MUST occur:

404 405

Step 1: The Sending RMP sends the Reliable Message in a request of a SOAP Requestresponse MEP instance.

406 407

Step 2: The Receiving RMP sends the RM-Reply in the response message of the same SOAP MEP instance.

408

Figure 3 shows this reply pattern.

Producer Submit

Notify

Consumer SOAP MEP Request

Deliver

Respond

(Reliable Message)

Sending RMP

SOAP MEP Response (RM-Reply) (Respond Payload)

Receiving RMP

Figure 3 Response RM-Reply Pattern 409 410

The Response RM-Reply Pattern MUST NOT be used for WSDL One-way operations to the Consumer.

15 November 2004 Page 13 of 72

411

2.4.2 Callback RM-Reply Pattern

412 413

When the Callback RM-Reply Pattern is in use, the following sequence of exchanges MUST occur:

414 415 416

Step 1: The Sending RMP sends the Reliable Message in the SOAP MEP instance required by this Producer-Consumer exchange. This MEP instance may be either Requestresponse or One-way.

417 418 419

Step 2: The Receiving RMP sends the RM-Reply. Except when the RM Reply is bundled with a Reliable Message (as described in Section 4.4), the RMP MUST send this RMReply using a SOAP One-way MEP.

Producer Submit

Notify

Consumer Deliver

Respond

SOAP MEP Request (Reliable Message)

SOAP MEP Response

Sending RMP

(Respond Payload)

Receiving RMP

SOAP MEP Request (RM-Reply)

Figure 4 Callback RM-Reply Pattern 420 421

Figure 4 shows this reply pattern. The dashed arrows indicate the SOAP message returned when a SOAP Request-response MEP is used to send the Reliable Message.

422

2.4.3 Poll RM-Reply Pattern

423

When the Poll RM-Reply Pattern is in use, the following sequence of exchanges MUST occur:

424 425 426

Step 1: The Sending RMP sends the Reliable Message in the SOAP MEP instance required by this Producer-Consumer exchange. This MEP instance may be either Requestresponse or One-way.

427 428 429 430 431

Step 2: The Sending RMP issues a message with a PollRequest element in a new SOAP MEP instance; this acts as a request for Acknowledgment. This message MUST NOT contain a payload (as defined in Section 1.5). The Sending RMP MUST use the request of a SOAP Request-response MEP instance for a synchronous PollRequest and MUST use a SOAP One-way MEP for an asynchronous PollRequest.

432 433 434 435

Step 3: The Receiving RMP sends the RM-Reply either (if synchronous polling) in the response message of the same SOAP instance that carried the PollRequest or (if asynchronous polling) in a message from a SOAP One-way MEP instance. This message MUST NOT contain a payload.

436 437 438 439

When the Sending RMP of Reliable Messages cannot receive underlying protocol requests (e.g., due to security restrictions), it may use the synchronous version of this reply pattern. The Sending RMP MAY also use this reply pattern (steps 2 and 3 above) to extend other RM-Reply Patterns. Figure 5 illustrates the synchronous variant, Figure 6 the asynchronous.

15 November 2004 Page 14 of 72

Producer Submit

Consumer

Notify

Deliver

Respond

SOAP MEP Request (Reliable Message)

Soap MEP Response

Sending RMP

(Respond Payload)

Receiving RMP

SOAP MEP Request (PollRequest)

SOAP MEP Response (RM-Reply)

Figure 5 Synchronous Poll RM-Reply Pattern

Producer Submit

Consumer

Notify

Deliver

Respond

SOAP MEP Request (Reliable Message)

Soap MEP Response (Respond Payload)

Sending RMP

SOAP MEP Request (PollRequest)

Receiving RMP

SOAP MEP Request (RM-Reply)

Figure 6 Asynchronous Poll RM-Reply Pattern

441

2.5 Message Identification and Grouping

442 443 444 445 446 447

A Reliable Message contains an Identifier that is globally unique and relies on the notion of a group. A Reliable Message always belongs to a group. The Sending RMP sends a group of messages to the Receiving RMP as a sequence of individual messages. The Reliable Message Identifier is a combination of a group ID and an optional sequence number; a sequence number, if present, is an integer that is unique within a group. More precisely, a message is uniquely identified as follows:

448 449 450

1) When there is only one message in the group: the group ID, which is a globally unique group identifier, may be used alone as Message Identifier. No sequence number is required, although one is allowed.

451 452

2) When the message belongs to a group of several messages: the message is identified by the group ID and a unique sequence number.

15 November 2004 Page 15 of 72

453

3 Reliability Agreement and Features

454

3.1 RM Agreement

455

3.1.1 Definition

456 457 458 459 460 461

An agreement for messaging reliability, or RM Agreement, describes which reliability features a sending party and a receiving party have agreed to use when exchanging a set of messages. The RM Agreement can be seen as a contract at two levels: (1) quality of service (QoS), about the conditions and quality of message delivery to the Consumer and (2) protocol features, including timing parameters and details about choreography between the Sending and Receiving RMPs.

462

3.1.2 RM Agreement Items

463

An RM Agreement is a list of Agreement Items.

464 465 466 467

A Sending RMP MUST be capable of (1) taking knowledge (whether by configuration, an API call, a message, the result of an algorithm or any other means) of a set of values that represent the RM Agreement Items described in this specification and (2) processing them according to the semantics described in this specification.

468 469 470

A Receiving RMP MUST be capable of (1) taking knowledge of the Agreement items as they are communicated via the header elements of Reliable Messages and (2) processing them according to the semantics described in this specification.

471 472

Table 3 shows the Agreement Items this specification uses. Each item is listed with its possible values:

15 November 2004 Page 16 of 72

Name

Value

Definition

GuaranteedDelivery

enabled/disabled For setting Guaranteed Delivery (see Section 3.2.1 for details).

NoDuplicateDelivery

enabled/disabled For setting message delivery without duplicates or Duplicate Elimination (see Section 3.2.2 for details).

OrderedDelivery

enabled/disabled For setting Guaranteed Message Ordering (see Section 3.2.3 for details).

GroupMaxIdleDuration number of seconds

For setting the elapsed time limit from the last message sent or received in a group, after which the group can be terminated. The value MUST NOT be zero or smaller.

GroupExpiryTime

date/time

For setting the date and time after which the group can be terminated.

ExpiryTime

date/time

For setting the date and time after which a message must not be delivered to the Consumer.

ReplyPattern

"Response", For setting the mode of response for "Callback", "Poll" Acknowledgments or Faults. Table 3 RM Agreement Items

473

3.1.3 Scope of an Agreement Item

474

There are two scopes to consider:

475

•

Group scope: All messages sent within a group.

476

•

Message Scope: A single message.

477 478

Agreement Items relate to a particular scope: for example, ExpiryTime affects each message separately, while GroupExpiryTime is an Agreement Item about groups.

479 480 481 482

Agreement items applying to the Message Scope MAY be applied to the Group Scope. For example, an RMP implementation may decide to specify the same ExpiryTime value for all messages of a group and not support setting different values for messages in a group. The default scope of applicability for each RM Agreement item is:

483

Message scope:

484

•

ExpiryTime

485

•

ReplyPattern

486

Group scope:

487

•

OrderedDelivery

488

•

GuaranteedDelivery

489

•

NoDuplicateDelivery

490

•

GroupExpiryTime

491

•

GroupMaxIdleDuration

15 November 2004 Page 17 of 72

492 493 494 495 496

An RMP MUST NOT allow most Agreement items applicable at Group scope to vary between messages of a group. For example, a Sending RMP MUST NOT use different guaranteed delivery modes for different messages of a group. However, it is allowed to dynamically change the value of GroupExpiryTime or GroupMaxIdleDuration pertaining to a group (See Section 5.1.2).

497

3.1.4 Rules

498 499

When defining an RM Agreement instance, there are some dependencies between the items of the agreement that must be respected:

500

•

If OrderedDelivery is enabled for a group, GuaranteedDelivery and NoDuplicateDelivery MUST also be enabled for that group.

•

If GroupExpiryTime is used for a group, the item GroupMaxIdleDuration MUST NOT be used for this group and vice versa.

501

502 503

504

3.1.5 Creation, Representation and Deployment of RM Agreements

505 506 507 508 509 510 511 512 513

The concrete representation of an RM Agreement is beyond the scope of this specification, as this may be part of a more general agreement that covers other matters as well as the reliability aspect. However, the RM Agreement determines the use of the reliability protocol and the behavior of RMPs. For these reasons, this specification references the RM Agreement in an abstract way, showing it as a simple list of (name, value) pairs called Agreement Items. This allows a description of the concrete effect of each Agreement Item on the message content and flow. Once there is a broad enough consensus for using a particular representation for agreements, a future version of this specification will define a corresponding binding for RM Agreements.

514 515 516 517 518 519 520

The way RM Agreements are established or communicated to each party is out of scope. However, one of the principles of this specification is that it should not be necessary to deploy an RM Agreement on both RMPs prior to executing business transactions. Only the Sending RMP needs to have knowledge of the RM Agreement initially. No prior communication of the agreement to the receiving party (an RMP and its user) is required. The only input the Receiving RMP will need in order to enforce the reliability requirements will be obtained from the header elements of received messages.

521

3.1.6 RM Capability

522 523 524 525 526 527

As a way to support the creation of RM Agreements, it may be useful for Web services providers to advertise somehow the reliability features (or RM Agreement Item values) supported by a deployed Web service. In contrast with agreements involving both parties, such reliability features – called RM Capabilities – may conveniently be associated with WSDL definitions. In support of this option, this specification proposes a concrete representation for these capabilities (see Appendix B).

528

3.2 Main Reliability Features

529 530 531

The main reliability features mentioned in Section 1 are formally described here in terms of requirements. This specification provides the means to enforce these requirements. A detailed description of the protocol features implementing these means is given in Section 4 and beyond.

15 November 2004 Page 18 of 72

532

3.2.1 Guaranteed Delivery

533

Quality of Service requirements:

534 535 536 537

When the GuaranteedDelivery Agreement Item is enabled, one of the two following outcomes SHALL occur for each Submit invocation: either (1) the Receiving RMP successfully delivers (Deliver invocation) the submitted payload to its associated Consumer or (2) the Sending RMP notifies (Notify invocation) the Producer associated with that payload of a delivery failure.

538

Notes:

539

•

This QoS feature guarantees only that the sender will always be notified of a delivery failure when a message is not delivered. It is, however, impossible to guarantee this while at the same time guaranteeing that (1) and (2) will never occur together for the same message. A proper usage by an implementation of the protocol options described in this specification will, however, greatly reduce situations where both (1) and (2) occur.

•

The GuaranteedDelivery agreement is defined for messages resulting from invocations of the Submit operation. An extension of this agreement to messages resulting from invocations of the Respond operation is out of scope for this specification.

540 541 542 543

544 545 546 547

Protocol requirements:

548 549 550

For all messages sent with the GuaranteedDelivery agreement, a Receiving RMP MUST publish the RM-Reply of each such message that has been either delivered or faulted. The Sending RMP MUST poll for all of its sent messages that requested the Poll RM-Reply Pattern.

551 552 553 554 555 556

A message resending technique combined with the acknowledgment and fault mechanism described here MUST be used in case of a delivery failure. Parameters that control the resending policy (number of retries, frequency, etc.) are out of the scope of this specification. These parameters may be added to an RM Agreement, although the resending policy may need to be dynamically adjusted depending on network conditions. When resending a message, the message contents must not change.

557 558

A Receiving RMP MUST NOT publish a Reliable Messaging Fault for a delivered Message. The RMP MUST NOT deliver a message for which a Reliable Messaging Fault has been published.

559 560 561

A Sending RMP MUST NOT resend a message for which an RM-Reply with a Fault type other than MessageProcessingFailure has been received and MUST instead notify its Producer of a delivery failure.

562

3.2.2 Duplicate Elimination

563

Quality of Service requirements:

564 565

When the NoDuplicateDelivery Agreement Item is enabled, a message resulting from a Submit invocation SHALL NOT be delivered twice or more to the Consumer.

566

Note:

567 568 569

In the current specification, the NoDuplicateDelivery agreement is defined for messages resulting from invocations to the Submit operation. An extension of this agreement to messages resulting from invocations to the Respond operation is out of scope for this specification.

570

Protocol requirements:

571

An implementation of this specification must ensure the following invariants:

572 573

•

Message instances resulting from separate invocations of Submit MUST NOT share the same Message Identifier.

15 November 2004 Page 19 of 72

•

574

When resending a message, the message contents must not change.

575 576 577

As a corollary to the above requirements, a Receiving RMP MUST ensure that once a message under this agreement has been delivered to a Consumer, no message with the same identifier received afterward will be delivered to this Consumer.

578 579 580 581

When the Response RM-Reply Pattern is requested with Duplicate Elimination for a Reliable Message, the Receiving RMP cannot deliver that message to the Consumer again (because it is a duplicate of a previously delivered message), and a Consumer response payload is expected, the response of the SOAP MEP instance MUST contain one (but not both) of the following:

582

•

a copy of the original response payload returned for that Message (in the SOAP Body) in addition to the Acknowledgment Indication (in the SOAP Header) or

•

a SOAP server Fault (in the SOAP Body) in addition to the Acknowledgment Indication (in the SOAP Header).

583

584 585 586 587

The Sending RMP and Producer expect either a complete response or a SOAP Fault when using the Response RM-Reply Pattern; these two allowed behaviors satisfy that expectation.

588

3.2.3 Guaranteed Message Ordering

589

Quality of Service requirements:

590 591 592 593

When the OrderedDelivery Agreement Item is enabled, messages resulting from a sequence of Submit invocations SHALL be delivered in the same order to the Consumer. In addition, when the Receiving RMP delivers one of these messages, all previous messages submitted in the sequence MUST already have been delivered (no missing message allowed).

594

Note:

595 596 597 598

In the current specification, the OrderedDelivery agreement is defined for messages resulting from invocations of the Submit operation on the Sending RMP. An extension of this agreement to messages resulting from invocations of the Respond operation is out of scope for this specification.

599

Protocol requirements:

600

Ordering is supported only over messages of the same group.

601 602

An implementation of this specification must ensure the following invariants, regarding the usage of sequence numbers (SequenceNum element): •

The Sending RMP MUST reflect the order of the Submit invocations on this RMP in the sequence numbers of the corresponding messages sent.

•

606

The Receiving RMP MUST deliver the messages received according to the order expressed by their sequence numbers, which is the same as the submission order.

607 608

An RMP will terminate the group as specified in Section 5.1.3.5 (T5) when those conditions arise.

603 604

605

15 November 2004 Page 20 of 72

609

4 Message Format

610

4.1 Structure

611 612 613 614 615

Figure 7 shows the structure of reliability SOAP header blocks in the SOAP Envelope, as specified by the WS-Reliability protocol. On the left side of the figure, a Reliable Message is characterized by the presence of the wsrm:Request element. On the right side a response to a Reliable Message contains a wsrm:Response element. Both wsrm:Request and wsrm:Response elements may be found in the same message. Soap:Envelope (continued)

soap:Envelope

soap:Header wsrm:Request

wsrm:Response

any *

wsrm:MessageId

wsrm:NonSequenceReply *

wsrm:SequenceNum

wsrm:SequenceReplies *

wsrm:ExpiryTime

wsrm:ReplyRange *

wsrm:ReplyPattern any * wsrm:Value wsrm:ReplyTo soap:Body wsrm:AckRequested wsrm:DuplicateElimination wsrm:MessageOrder

Cardinality : 1

Cardinality : 0 or 1 *

: An element with this mark may appear more than one time

Figure 7 Structure of WS-Reliability elements

15 November 2004 Page 21 of 72

616

Figure 8 shows the structure of PollRequest message embedded in the SOAP Envelope. soap:Envelope soap:Header wsrm:PollRequest any *

wsrm:RefToMessageIds * wsrm:SequenceNumRange*

Cardinality : 1 Cardinality : 0 or 1

wsrm:ReplyTo *

: An element with this mark may appear more than one time

any *

soap:Body

Figure 8 Structure of PollRequest message elements 617 618

The namespace [XML Namespaces] for reliable messaging defined in this specification is: http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd

619 620

When the text of the specification is shown to be in conflict with schema statements, the schema statements prevail in the absence of an errata addressing the conflict.

621 622 623

The schema for some of the elements specified in this section includes the specification of extensibility elements and attributes. The extensibility features expressed formally in the schema are specified in Section 4.6.

624 625

If a message contains additional elements or attributes not described in this specification, the Reliable Messaging Processor MAY ignore them.

626

Any of the following three elements can be a direct child element of the SOAP Header:

627

•

Request element

628

•

PollRequest element

629

•

Response element

15 November 2004 Page 22 of 72

630

4.2 Request Element

631 632 633

The Request element conveys information about the agreement items that apply to the containing Reliable Message. This element includes the following attribute and child elements (see the description of each child element for cardinality requirements):

634

•

SOAP mustUnderstand attribute (see Appendix A for details)

635

•

MessageId element

636

•

ExpiryTime element

637

•

ReplyPattern element

638

•

AckRequested element

639

•

DuplicateElimination element

640

•

MessageOrder element Cardinality

0 or 1

Value

None

Attributes

soap:mustUnderstand (Boolean)

Child elements

MessageId ExpiryTime ReplyPattern AckRequested DuplicateElimination MessageOrder

Table 4 Request Element 641

Example 1 shows an instance of a Request element.

15 November 2004 Page 23 of 72

Example 1 Request Element

643 644 645 646 647 648 649 650 651 652 653 654 655 656 657

<Request xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope" soap12:mustUnderstand="1"> <MessageId groupId="mid://[email protected]"> <SequenceNum number="0" groupExpiryTime="2005-02-02T03:00:33-31:00" /> </MessageId> <ExpiryTime>2004-09-07T03:01:03-03:50</ExpiryTime> <ReplyPattern> <Value>Response</Value> </ReplyPattern> <AckRequested/> <DuplicateElimination/> <MessageOrder/> </Request>

658

4.2.1 Element: Request/MessageId

659

This element includes the following attribute:

642

660

•

a groupId attribute Cardinality

Value

None

Attributes

groupId (xs:anyURI)

Child elements

SequenceNum

Table 5 MessageId Element

661

4.2.1.1 Attribute: Request/MessageId@groupId

662 663 664 665 666

This attribute identifies a message group. The Sending RMP MUST use a distinct globally unique @groupId value for each distinct group of messages. Within any such group, all messages will have the same value for @groupId. This identification (the value) is of type URI as defined in [RFC2396]. It is RECOMMENDED that implementations use the Message-ID schema defined in [RFC2392].

667

4.2.1.2 Element: Request/MessageId/SequenceNum

668 669

The Sending RMP MUST include the SequenceNum element in all Reliable Messages of a group with more than one message.

670 671 672

The SequenceNum element carries the sequence number as well as other attributes that may alter the Receiving RMP's processing of the group. When a message includes a MessageOrder element, the sequence number is used in support of message ordering (Section 3.2.3).

673

This element includes the following attributes:

15 November 2004 Page 24 of 72

674

•

a groupExpiryTime attribute

675

•

a groupMaxIdleDuration attribute

676

•

a number attribute

677

•

a last attribute

678 679

In a request message, the sender MAY include either (but not both) @groupExpiryTime or @groupMaxIdleDuration (see Section 5.1.2).

680

Example 2 illustrates the SequenceNum element with some message fragments: Example 2 SequenceNum Element

681 682

683 684 685 686 687

688 689 690 691 692

693 694 695

1) First message <MessageId groupId="mid://[email protected]"> <SequenceNum number="0" groupExpiryTime="2005-02-02T03:00:33-31:00" /> </MessageId> 2) Second message <MessageId groupId="mid://[email protected]"> <SequenceNum number="1" groupExpiryTime="2005-02-02T03:00:33-31:00" /> </MessageId> 3) The last message for the group <MessageId groupId="mid://[email protected]"> <SequenceNum number="2" groupExpiryTime="2005-02-02T03:00:33-31:00" last="true" /> </MessageId> Cardinality

Value

None

Attributes

groupExpiryTime (dateTime) groupMaxIdleDuration (duration) number (unsignedLong) last (Boolean)

Child elements

None

Table 6 SequenceNum Element

696

4.2.1.2.1 Attribute: Request/MessageId/SequenceNum@groupExpiryTime

697 698 699

This attribute represents the GroupExpiryTime agreement item (Section 3.1.2, Table 3). It specifies the the date and time at which the sender wishes the group to terminate. The @groupExpiryTime value is expressed as UTC and conforms to [XML Schema Part 2] dateTime.

15 November 2004 Page 25 of 72

700 701

The Cardinality of this attribute is 0 or 1. Constraints on the use of this attribute are specified in Section 5.

702 703

4.2.1.2.2 Attribute: Request/MessageId/SequenceNum@groupMaxIdleDuration

704 705 706 707

This attribute represents the GroupMaxIdleDuration agreement item (Section 3.1.2, Table 3). It specifies the maximum idle time for a group. The @groupMaxIdleDuration value conforms to [XML Schema Part 2] duration. The Cardinality of this attribute is 0 or 1. Constraints on the use of this attribute are specified in Section 5.

708

4.2.1.2.3 Attribute: Request/MessageId/SequenceNum@number

709 710 711

This attribute contains the sequence number, which identifies the message within its group (Section 2.6) and is used in support of message ordering (Section 3.2.3). @number conforms to [XML Schema Part 2] unsignedLong.

712 713 714 715

The Sending RMP MUST set this value to 0 for the first message of a group. The Sending RMP thereafter MUST increment this value by 1 for each message submitted in this group. Once the value reaches the maximum (18446744073709551615, the maximum value for this data type), the group is terminated (see Section 5).

716

4.2.1.2.4 Attribute: Request/MessageId/SequenceNum@last

717 718 719

This attribute indicates whether or not the containing message is the last in a group. The Cardinality of this attribute is 0 or 1. When this attribute is present, its Boolean value has the following meaning:

720

•

false: Indicates the message is not the last message of the group or is not known to be the last message of the group.

•

true: Indicates the message is known to be the last message sent within a group of messages.

721

722 723 724

When this attribute is not present, its value defaults to false.

725

4.2.2 Element: Request/ExpiryTime

726 727 728 729 730 731 732

The ExpiryTime element represents the ExpiryTime agreement item (Section 3.1.2, Table 3). It indicates the ultimate date and time after which the Receiving RMP MUST NOT invoke the Deliver operation for the received message. The message is considered expired if the current time, expressed in UTC, is greater than the value of the ExpiryTime element. When a message expires on the Sending RMP before being successfully sent, a Sending RMP MUST NOT send or resend it and MUST communicate a delivery failure to the Producer. The time is expressed as UTC and conforms to [XML Schema Part 2] dateTime. Cardinality

Value

xs:dateTime

Attributes

None

Child elements

None

Table 7 ExpiryTime Element

15 November 2004 Page 26 of 72

733

4.2.3 Element: Request/ReplyPattern

734 735

A Sending RMP MUST include the ReplyPattern element in a Request element. The ReplyPattern element includes the following child elements:

736

•

a Value element

737

•

a ReplyTo element Cardinality

Value

None

Attributes

None

Child elements

Value ReplyTo

Table 8 ReplyPattern Element

738

4.2.3.1 Element: Request/ReplyPattern/Value

739 740 741 742 743

The Value element indicates which reply pattern the Sending RMP requests. This element specifies whether the Receiving RMP should send the Acknowledgment Indication or RM Fault Indication back in the response to the reliable message, in a separate callback request, or in the response to a separate poll request. A Sending RMP MUST include the Value element in a ReplyPattern element. This element has one of the following three values:

744

•

Response

745

•

Callback

746

•

Poll

747 748

These values respectively indicate which of the RM-Reply Patterns – Response, Callback or Poll – is in use, as described in Section 2.5. Cardinality

Value

xs:string: Response, Callback or Poll

Attributes

None

Child elements

None

Table 9 Value Element

749

4.2.3.2 Element: Request/ReplyPattern/ReplyTo

750 751 752 753 754

If the value of the Request/ReplyPattern/Value element is "Callback", the Sending RMP MUST include this element in the Reliable Message. For all other values ("Poll" and "Response") of Request/ReplyPattern/Value element, the Sending RMP MUST NOT include this element. This element specifies the endpoint where the Sending RMP expects to receive a callback containing RM-Reply information.

15 November 2004 Page 27 of 72

755 756 757

If present, the reference-scheme attribute specifies the format of the single child element of the ReplyTo element. If the attribute is omitted, the default content of the ReplyTo element is BareURI. Cardinality

0 or 1

Value

None

Attributes

reference-scheme

Child elements

{xs:anyType} (an element representing the reference)

Table 10 ReplyTo Element

758

4.2.3.2.1 Attribute: Request/ReplyPattern/ReplyTo@reference-scheme

759 760 761

This attribute specifies the format or schema of the child element of Request/ReplyPattern/ReplyTo. The Sending RMP MUST omit this attribute when the child element of Request/ReplyPattern/ReplyTo is BareURI. The type of this attribute is xs:anyURI.

762

4.2.3.2.2 Element: Request/ReplyPattern/ReplyTo/BareURI

763 764 765 766 767

This element provides one of the simplest referencing options, the URI of the callback recipient's endpoint. It is the default content of the Request/ReplyPattern/ReplyTo and PollRequest/ReplyTo (see Section 4.3.1) elements, though the Sending RMP MAY use any other element and scheme supported by the Receiving RMP. This location (the value) is of type URI as defined in [RFC2396].

768 769

Section 6 provides additional information about the specific case for which the content of a BareURI in a Request or PollRequest element uses the HTTP URI scheme. Cardinality

0 or 1

Value

xs:anyURI

Attributes

None

Child elements

None

Table 11 BareURI Element

770

4.2.4 Element: Request/AckRequested

771 772 773 774 775 776 777 778 779

A Sending RMP MUST include the AckRequested element in a message if and only if that message is subject to the GuaranteedDelivery Agreement Item (refer to Section 3.2.1 for details); as described in Section 3.1.4, this condition includes all messages subject to the OrderedDelivery Agreement Item. The Sending RMP uses this element to request the Receiving RMP to publish an Acknowledgment after the message is delivered to the consumer party or else to publish an RM Fault Indication. The Receiving RMP MUST publish this information, even for received messages that are duplicates of previously delivered messages. For example, if the RM-Reply Pattern is Callback and no fault occurs, an Acknowledgment Indication SHALL be sent back.

780 781

The Receiving RMP MAY publish an RM Fault Indication for a Reliable Message, even if the AckRequested element is not present in the Request element for that message.

15 November 2004 Page 28 of 72

782 783

The pattern used to send the Acknowledgment or RM Fault Indication is determined by the value of the ReplyPattern element. Cardinality

0 or 1

Value

None

Attributes

None

Child elements

None

Table 12 AckRequested Element

784

4.2.5 Element: Request/DuplicateElimination

785 786 787 788

A Sending RMP MUST include the DuplicateElimination element in a message if and only if that message is subject to the NoDuplicateDelivery Agreement Item (refer to Section 3.2.2 for details); as described in Section 3.1.4, this condition includes all messages subject to the OrderedDelivery Agreement Item. Cardinality

0 or 1

Value

None

Attributes

None

Child elements

None

Table 13 DuplicateElimination Element

789

4.2.6 Element: Request/MessageOrder

790 791

A Sending RMP MUST include the MessageOrder element if and only if that message is subject to the OrderedDelivery Agreement Item (refer to Section 3.2.3 for details).

792 793 794

If the MessageOrder element appears in the message received, the Receiving RMP MUST NOT deliver the message until all messages with the same Request/MessageId@groupId value and a lower Request/MessageId/SequenceNum@number value have been delivered. Cardinality

0 or 1

Value

None

Attributes

None

Child elements

None

Table 14 MessageOrder Element

795

4.2.7 Example

796 797 798 799 800

The HTTP message below uses the Request element to specify (among other things) that all three reliability features should be used: GuaranteedDelivery ("AckRequested" element), NoDuplicateDelivery ("DuplicateElimination" element), and OrderedDelivery ("MessageOrder" element). The reply pattern is “Poll”, meaning that no Acknowledgment or Fault will be sent back unless explicitly requested by another message containing a PollRequest header.

15 November 2004 Page 29 of 72

Example 3 Reliable Message with Request header 801

POST /abc/servlet/wsrEndpoint HTTP/1.0 Content-Type: text/xml; charset=utf-8 Host: 192.168.183.100 SOAPAction: "" Content-Length: 736

802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <Request xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" soap:mustUnderstand="1"> <MessageId groupId="mid://[email protected]"> <SequenceNum number="0" groupExpiryTime="2005-02-02T03:00:33-31:00" /> </MessageId> <ExpiryTime>2004-09-07T03:01:03-03:50</ExpiryTime> <ReplyPattern> <Value>Poll</Value> </ReplyPattern> <AckRequested/> <DuplicateElimination/> <MessageOrder/> </Request> </soap:Header> <soap:Body> <Request xmlns="http://example.org/wsr">Request Message</Request> </soap:Body> </soap:Envelope>

829

4.3 PollRequest Element

830 831 832 833 834

A PollRequest Message requests an RM-Reply for a Reliable Message that had “Poll” as the value of the Request/ReplyPattern/Value element and included the Request/AckRequested element. However, PollRequest Messages can also solicit delivery status for messages that were originally sent with “Response” or “Callback” as the value of the Request/ReplyPattern/Value element and that included the Request/AckRequested element.

835 836 837

If a Receiving RMP does not support the use of PollRequest as a general status query mechanism, it MAY return a FeatureNotSupported fault in response to a PollRequest when the relevant ReplyPattern Agreement Item does not have the value “Poll”.

838 839

A Receiving RMP that receives a supported form of PollRequest MUST publish RM-Reply information relevant to non-expired messages identified in that request.

840

This element includes the following attribute and child elements:

841

•

SOAP mustUnderstand attribute (see Appendix A for details)

842

•

a ReplyTo element

15 November 2004 Page 30 of 72

843

•

a RefToMessageIds element Cardinality

0 or 1

Value

None

Attributes

soap:mustUnderstand (Boolean)

Child elements

ReplyTo RefToMessageIds

Table 15 PollRequest Element Example 4 PollRequest Element

845 846 847 848 849 850 851 852 853 854 855 856

857

4.3.1 Element: PollRequest/ReplyTo

858 859 860

The Receiving RMP MUST send the RM-Reply information in a new request to the endpoint specified by PollRequest/ReplyTo whenever this element is present. If it is not present, the Receiving RMP MUST send back the RM-Reply on the response to the PollRequest message.

861 862

Section 4.2.3.2 provides additional information about the very similar Request/ReplyPattern/ReplyTo element.

844

Cardinality

0 or 1

Value

None

Attributes

reference-scheme

Child elements

{xs:anyType} (an element representing the reference)

Table 16 ReplyTo Element

863

4.3.1.1 Attribute: PollRequest/ReplyTo@reference-scheme

864 865

Section 4.2.3.2.1 provides additional information about the similar Request/ReplyPattern/ReplyTo@reference attribute.

15 November 2004 Page 31 of 72

866

4.3.1.2 Element: PollRequest/ReplyTo/BareURI

867 868

Section 4.2.3.2.2 provides additional information about the similar Request/ReplyPattern/ReplyTo/BareURI element. Cardinality

0 or 1

Value

xs:anyURI

Attributes

None

Child elements

None

Table 17 BareURI Element

869

4.3.2 Element: PollRequest/RefToMessageIds

870 871 872

The RefToMessageIds element contains the identifiers of groups and messages whose status the Sending RMP is requesting. This element includes @groupId and zero or more SequenceNumRange elements as follows:

873

•

a groupId attribute

874

•

zero or more SequenceNumRange elements Cardinality

1 or more

Value

None

Attributes

groupId (URI)

Child elements

SequenceNumRange

Table 18 RefToMessageIds Element 875 876 877

When this RefToMessageIds element does not include a SequenceNumRange element, the Receiving RMP MUST return RM-Replies for non-expired messages that were delivered or faulted in that group.

878 879 880 881 882

When the RefToMessageIds element includes one or more SequenceNumRange element(s), the Receiving RMP MUST return RM-Replies for the non-expired messages that were delivered or faulted in the identified subset of that group. The identified subset includes all Reliable Messages whose MessageId/SequenceNum@number values fall in the range(s) specified in the RefToMessageIds/SequenceNumRange element(s) of the PollRequest.

883 884

A Sending RMP MAY include multiple RefToMessageIds elements (one for each @groupId value) in a single PollRequest Message to request RM-Replies for multiple groups.

885

4.3.2.1 Attribute: PollRequest/RefToMessageIds@groupId

886 887

The @groupId specifies the group of messages whose status the Sending RMP is requesting. This identification (the value) is of type URI as defined in [RFC2396].

15 November 2004 Page 32 of 72

888

4.3.2.2 Element: PollRequest/RefToMessageIds/SequenceNumRange

889 890 891

The SequenceNumRange element specifies those messages in a group for which the Sending RMP requests status. Attributes @from and @to of this element express an inclusive range for SequenceNum values. This element contains the following two attributes:

892

•

a from attribute

893

•

a to attribute

894

When these attributes have the same value, the range is limited to a single message. Cardinality

0 or more

Value

None

Attributes

from (unsignedLong) to (unsignedLong)

Child elements

None

Table 19 SequenceNumRange Element

895 896

4.3.2.2.1 Attribute: PollRequest/RefToMessageIds/SequenceNumRange@from

897 898

This attribute specifies the lowest SequenceNum@number value of the message range. The value of @from is of type unsignedLong and SHALL be less than or equal to the value of @to.

899

4.3.2.2.2 Attribute: PollRequest/RefToMessageIds/SequenceNumRange@to

900 901

This attribute specifies the highest SequenceNum@number value of the message range. The value of @to is of type unsignedLong and SHALL be greater than or equal to the value of @from.

902

4.3.3 Example

903 904 905 906

The HTTP message below uses the PollRequest reliability element, polling the Receiving RMP for the status of messages within the range of sequence numbers 0 to 20 of a particular group. The response to this PollRequest will identify which of those messages have been delivered (Acknowledged).

15 November 2004 Page 33 of 72

Example 5 PollRequest Message embedded in HTTP Request 907

POST /abc/servlet/wsrEndpoint HTTP/1.0 Content-Type: text/xml; charset=utf-8 Host: 192.168.183.100 SOAPAction: "" Content-Length: 432

908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <PollRequest xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" soap:mustUnderstand="1"> <RefToMessageIds groupId="mid://[email protected]"> <SequenceNumRange from="0" to="20"/> </RefToMessageIds> </PollRequest> </soap:Header> <soap:Body /> </soap:Envelope>

925

4.4 Response Element

926 927

The Response element indicates Acknowledgments and Faults for Reliable Messages. This element includes the following attributes:

928 929 930

•

SOAP mustUnderstand attribute (see Appendix A for details)

The Response element SHALL include a list one or more elements in length containing a choice or choices from the following:

931

•

NonSequenceReply element(s)

932

•

SequenceReplies element(s)

933 934 935 936

When the Response occurs under the Response RM-Reply Pattern, the first element in this list describes the status of the received Reliable Message. In this case, when the SequenceReplies element is used, the first contained ReplyRange element will include the received Reliable Message within its range.

937 938 939 940 941 942 943 944 945

The Receiving RMP MAY bundle a Response element with a Request element when responding to a message that used the Callback RM-Reply Pattern. In this case, the response and the new Reliable Message MUST share a common destination URI. This enables the combination of an Acknowledgment Indication and the business response to the original message. This also allows a Receiving RMP to bundle an Acknowledgment Indication with another unrelated message to the Sending RMP to reduce network traffic. When combined in a single message, the Request and Response elements are treated separately from the perspective of the abstract model (Section 2); a Receiving RMP component handles the Request element and payload while a Sending RMP handles the Response element.

15 November 2004 Page 34 of 72

Cardinality

0 or 1

Value

None

Attributes

soap:mustUnderstand (Boolean)

Child elements

NonSequenceReply SequenceReplies

Table 20 Response Element 946

Example 6 shows an instance of the Response element. Example 6 Response Element

948 949 950 951 952 953 954 955 956 957 958 959

960

4.4.1 Element: Response/NonSequenceReply

961 962

An RM-Reply for a message that does not have a sequence number SHALL include a NonSequenceReply element. This element includes the following attributes:

947

963

•

a groupId attribute

964

•

a fault attribute

965 966

The @fault indicates a particular fault for the identified message. Without this attribute, the NonSequenceReply element is an Acknowledgment Indication for the message. Cardinality

0 or more

Value

None

Attributes

groupId (URI) fault (QName)

Child elements

None

Table 21 NonSequenceReply Element

15 November 2004 Page 35 of 72

967

4.4.1.1 Attribute: Response/NonSequenceReply@groupId

968 969 970

This attribute specifies the group identifier of a message that did not have a sequence number. A NonSequenceReply element SHALL include the message's @groupId. This identification (the value) is of type URI as defined in [RFC2396].

971

4.4.1.2 Attribute: Response/NonSequenceReply@fault

972 973

This attribute indicates the code of a Reliable Messaging Fault encountered while processing the message. The Cardinality of this attribute is 0 or 1.

974

4.4.2 Element: Response/SequenceReplies

975 976 977

An RM-Reply for a group (or a subset thereof) whose messages had sequence numbers SHALL include a SequenceReplies element. This element contains a @groupId and 1 or more ReplyRange elements. Cardinality

0 or more

Value

None

Attributes

groupId (URI)

Child elements

ReplyRange

Table 22 SequenceReplies Element

978

4.4.2.1 Attribute: Response/SequenceReplies@groupId

979 980 981

The @groupId specifies the message group for which its SequenceReplies element carries the status. A SequenceReplies element SHALL include the group's @groupId. This identification (the value) is of type URI as defined in [RFC2396].

982

4.4.2.2 Element: Response/SequenceReplies/ReplyRange

983 984 985 986

The ReplyRange element indicates a range of sequence numbers with a shared delivery status. The @fault indicates a particular, common fault all messages in the range share. Without this attribute, the ReplyRange element is an Acknowledgment Indication for all messages in the range. Cardinality

1 or more

Value

None

Attributes

from (unsigned Long) to (unsigned Long) fault (QName)

Child elements

None

Table 23 ReplyRange Element

15 November 2004 Page 36 of 72

987

4.4.2.2.1 Attribute: Response/SequenceReplies/ReplyRange@from

988

This attribute has same type and semantics as in the PollRequest element.

989

4.4.2.2.2 Attribute: Response/SequenceReplies/ReplyRange@to

990

This attribute has same type and semantics as in the PollRequest element.

991

4.4.2.2.3 Attribute: Response/SequenceReplies/ReplyRange@fault

992 993

This attribute indicates the code of a Reliable Messaging Fault encountered while processing all of the messages in the identified range. The Cardinality of this attribute is 0 or 1.

994

4.4.3 Example

995 996 997 998 999 1000

The message below uses the Response reliability element, which in this case is carrying the response of a previous PollRequest element. The response acknowledges a message specified by the group identifier “mid://[email protected]” and messages for a group specified by the group identifier “mid://[email protected]” within the ranges of sequence numbers 0 to 14 and 16 to 20. The response also reports an RM Fault for a message with sequence number 15 for the group. Example 7 RM-Reply message embedded in HTTP Response

1001

HTTP/1.0 200 OK Server: WS-ReliabilityServer Date: Mon, 02 Feb 2004 10:38:32 GMT Content-Language: en Content-Type: text/xml; charset=utf-8 Content-Length: 593

1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <Response soap:mustUnderstand="1" xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd"> <NonSequenceReply groupId="mid://[email protected]"/> <SequenceReplies groupId="mid://[email protected]"> <ReplyRange from="0" to="14"/> <ReplyRange from="15" to="15" fault="InvalidRequest"/> <ReplyRange from="16" to="20"/> </SequenceReplies> </Response> </soap:Header> <soap:Body /> </soap:Envelope>

1022

4.5 Fault Codes For Reliable Messaging Failures

1023

The protocol defines two fault categories:

15 November 2004 Page 37 of 72

•

The Message Format fault set, which includes all faults generated because of a malformed Reliable Message header.

•

1027

The Message Processing fault set, which includes all faults generated while processing the message.

1028 1029 1030

They are explained in detail in the following sections. The Receiving RMP returns these protocolspecific fault codes within the Response header element. Reliable Message Faults are carried in the SOAP Header and do not rely exclusively on the SOAP Fault model for the following reasons:

1024 1025

1026

1031

•

The SOAP Fault model does not allow batching of several faults in the same message.

1032

•

RM Faults may be carried along with business messages that are unrelated to these faults; they should not affect the processing of the SOAP body in such messages.

1033 1034

1035

The rules for processing faults are: •

The Receiving RMP MUST NOT deliver a message for which an RM Fault is published. Therefore, the Receiving RMP MUST NOT send an Acknowledgment Indication for such a message.

•

If a Reliable Message sent over a SOAP Request-response MEP cannot be delivered to the Consumer, the response of the SOAP MEP instance SHALL contain a SOAP Fault (in the SOAP Body) in addition to the appropriate RM Fault (in the SOAP Header). If the specific RM Fault encountered was due to a problem with the request header element, the Receiving RMP MUST set the value of the soap:Fault@faultcode attribute to "soap:Client" (for SOAP 1.1 messages) or the soap12:Fault/Code/Value element to "soap12:Sender" (for SOAP 1.2 messages). If the specific RM Fault encountered was due to a problem with processing by the Receiving RMP, the Receiving RMP MUST set the value of the soap:Fault@faultcode attribute to "soap:Server" (for SOAP 1.1 messages) or the soap12:Fault/Code/Value element to "soap12:Receiver" (for SOAP 1.2 messages). The Sending RMP and Producer expect either a complete response or a SOAP Fault when using the SOAP Request-response MEP; this requirement satisfies those expectations. More details are given in Section 3.2 and in the HTTP Binding section (Section 6).

•

When a Reliable Message sent over a SOAP One-way MEP cannot be delivered to the Consumer due to a failure in processing the RM headers, a SOAP Fault SHALL NOT be returned. The HTTP binding section (Section 6) gives more details on the recommended behavior in such case.

1036 1037

1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051

1052 1053 1054 1055

1056 1057

The Fault codes described in Sections 4.5.1 and 4.5.2 are allowed values for @fault in a Response element.

1058

4.5.1 Message Format Faults

1059 1060

The Receiving RMP publishes these faults when the message format of the Reliable Messaging Headers is either invalid or wrong.

15 November 2004 Page 38 of 72

Local part name

Description and Cause(s)

InvalidRequest

The Request element is wrong or invalid. Examples are: 1.Any of the mandatory elements such as MessageId, ExpiryTime or ReplyPattern are missing. 2.AckRequested, DuplicateElimination or MessageOrder elements appear twice. 3.The soap:mustUnderstand attribute is missing.

InvalidPollRequest

The PollRequest element is wrong or invalid. Examples are: 1.The soap:mustUnderstand attribute is missing. 2. The RefToMessageIds element is missing.

InvalidMessageId

Used in any of the following cases: 1. @groupId (for MessageId or RefToMessageIds) is not present or is present with an invalid value. 2. @number in SequenceNum element is not present or is present with an invalid value. 3. Attributes (from and to) of SequenceNumRange are not present or are present with invalid values.

InvalidMessageParameters

Used in any of the following cases: 1. The @groupExpiryTime is wrong or invalid. 2. The @groupMaxIdleDuration is wrong or invalid. 3. Both group parameters are present. 4. SequenceNum@last exists but is not one of the allowed {false|true} values.

InvalidReplyPattern

Used in either of the following cases: 1. The ReplyPattern format is wrong or invalid. 2. The ReplyTo element is missing for the Callback pattern.

InvalidExpiryTime

The ExpiryTime format is wrong or invalid. Table 24 Invalid Message Format Fault Code Values

1061

Note:

15 November 2004 Page 39 of 72

1062 1063

Cases exist in which the Receiving RMP is unable to send RM Fault Indications for messages with invalid message headers, such as:

1064

•

The ReplyTo element is missing or invalid in the Callback and asynchronous Poll cases.

1065

•

The MessageId element is missing for the Request element.

1066

•

The RefToMessageIds is missing for the PollRequest element.

1067

4.5.2 Message Processing Faults

1068 1069

The Receiving RMP publishes these faults when there is an error processing a valid Reliable Messaging message. Local part name

Description and Cause(s)

FeatureNotSupported

The Receiving RMP receives a message with an RM feature that it does not support. An example is an RM message with a MessageOrder element sent to a Receiving RMP that doesn’t support Guaranteed Message Ordering.

PermanentProcessingFailure

Permanent and fatal processing failures such as: 1. Persistence Storage failures. 2. Message Delivery failures. A PermanentProcessingFailure fault indicates that the failure is fatal and subsequent retries of the same message will also fail.

MessageProcessingFailure

Used in transient failure cases such as: 1. The number of buffered requests exceeded the maximum limit. 2. The number of threads reached the maximum limit, etc. 3. The Deliver operation fails. A transient fault, unlike a permanent fault, is temporary; the message may succeed after a subsequent retry.

GroupAborted

All processing for the group associated with the reliable message request has been aborted by the Receiving RMP. The Receiving RMP MUST NOT deliver subsequent messages within that group. Table 25 Messaging Processing Failure Fault Code Values

15 November 2004 Page 40 of 72

1070

4.5.3 RM Fault Examples Example 8 RM Fault Indication for Reliable Messaging

1072 1073 1074 1075 1076 1077 1078 1079 1080 1081

1082 1083

If the PollRequest element in Example 4 was missing the soap:mustUnderstand attribute, the InvalidPollRequest fault may be sent as follows.

1071

Example 9 RM Fault Indication for PollRequest message

1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <Response soap:mustUnderstand="1" xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd"> <SequenceReplies groupId="mid://[email protected]"> <ReplyRange from="0" to="5" fault="InvalidPollRequest"/> <ReplyRange from="15" to="20" fault="InvalidPollRequest"/> </SequenceReplies> <NonSequenceReply groupId="mid://[email protected]" fault="InvalidPollRequest"/> <SequenceReplies groupId="mid://[email protected]/"> <ReplyRange from="713" to="6150" fault="InvalidPollRequest"/> </SequenceReplies> </Response> </soap:Header> <soap:Body /> </soap:Envelope>

1101

4.6 Extensibility Features of Schema

1102 1103

The core schema for this specification (associated in Section 1.3, Table 2,with the “wsrm” namespace prefix) specifies extension mechanisms for some schema elements.

1104 1105 1106 1107

The following elements (which have a complex sequence type) allow the presence of zero or more extension elements (of type xs:anyType; that is, any type not defined in this core namespace is allowed) at the beginning of the sequence, as well as zero or more extension attributes (with similar namespace restrictions):

1084

1108

•

Request

15 November 2004 Page 41 of 72

1109

•

Response

1110

•

PollRequest

1111

•

NonSequenceReply

1112

•

SequenceReplies

1113

•

ReplyRange

1114 1115

The extensibility of the ReplyTo elements (Sections 4.2.3.2 and 4.3.1) is somewhat different; it is described in the appropriate sections above.

15 November 2004 Page 42 of 72

1116

5 Operational Aspects and Semantics

1117

5.1 Message Group Life Cycle

1118

5.1.1 Group Termination

1119 1120 1121 1122

Being able to know when a group may be terminated and its persistent resources reclaimed is essential for keeping the resource footprint of reliability low. However, this section is not just about efficient management of resources: it describes normative behavioral rules for RMPs when handling group termination.

1123 1124 1125 1126 1127

Termination of a group in the Sending RMP and in the Receiving RMP are two distinct events, not synchronized by any special message but instead occurring as the result of rules applying separately to the Sending and Receiving RMPs. As a consequence, the termination of a group may occur at quite different times on the Sending RMP and the Receiving RMP. However, the lack of synchronization allowed by these termination rules is not consequential.

1128 1129

Groups undergoing termination on the Sending RMP and the Receiving RMP pass through the following states:

1130

Group complete:

1131

•

The Sending RMP considers a group complete when all of its messages have been sent and the last sent message has an ending marker (SequenceNum@last="true" or it has a sequence number with the maximum value). Note that completeness occurs even if not all of the group's messages have been either acknowledged or faulted (in case GuaranteedDelivery is enabled).

•

The Receiving RMP considers a group complete when a message with an ending marker has been received and all previous messages for this group also have been received (no number missing in the sequence) although not necessarily delivered yet.

1132 1133 1134 1135

1136 1137 1138

1139

Group closed:

1140

•

When a group is closed in the Sending RMP, the RMP expects to send no new message in this group. However, the RMP MAY resend messages as needed if GuaranteedDelivery is enabled. If a new message is submitted for a closed group, the Sending RMP MUST notify the Producer that the group is closed and MUST NOT send the message.

•

When a group is closed in the Receiving RMP, the RMP expects to receive no new message for this group. After a group is closed and before it is "removed" (see definition below), a Receiving RMP MUST NOT deliver messages received with this group identifier, whether or not they are duplicates of previous messages and regardless of whether they result from a resend of previously failed messages initiated before closing on the Sending RMP (in case GuaranteedDelivery is enabled).

1141 1142 1143 1144

1145 1146 1147 1148 1149 1150

1151

Note:

1152 1153

Due to time-out, a group may be closed without being complete. Once complete, a group will close (see termination rules).

15 November 2004 Page 43 of 72

1154

Group Removed:

1155 1156 1157 1158

Group removal occurs at the time the group is closed or afterward. Intuitively, a group is removed when a Receiving RMP does not need to remember anything about this group, i.e., when there is no need to check for duplicates of its messages in the future (for example, when all of its messages have expired).

1159

•

When a group is removed in the Sending RMP, the RMP is NOT REQUIRED to verify that future submitted messages are improperly associated with the removed group and MAY treat them as part of a new group. However, the Sending RMP is responsible for generating group identifiers, and it SHOULD generate values unique enough to avoid later reuse of the group identifier of a removed group (for example, generation mechanisms including a timestamp will make reuse impossible).

•

When a group is removed in the Receiving RMP, the RMP is no longer supposed to remember anything about this group. In particular, the group identifier is discarded from the RMP state. When receiving a message with same group identifier as a removed group, a Receiving RMP is NOT REQUIRED to confirm whether or not this group identifier value has already been used; the RMP MAY treat such a message as part of a new group.

1160 1161 1162 1163 1164

1165 1166 1167 1168 1169 1170

1171

5.1.2 Group Termination Parameters

1172 1173 1174 1175 1176

Two RM Agreement Items, GroupExpiryTime and GroupMaxIdleDuration, determine when a group can be terminated. These two items are considered Group Termination parameters that control the persistence of the group data. The corresponding message header attributes are @groupExpiryTime and @groupMaxIdleDuration respectively. The following requirements pertain to these header attributes:

1177 1178 1179 1180 1181

a) The first message in a group (the one with Request/MessageId/SequenceNum@number=0) indicates which Group Termination (timeout) parameter is in use for the group. However, the Receiving RMP MUST use the first message received for this group to indicate which termination parameter is associated with this group. •

If the first message in the sequence of a group has neither group time-out parameter present, the group will be terminated according to condition T3, T4 or T5.

•

If the first message has one of the two time-out parameters present (either @groupExpiryTime or @groupMaxIdleDuration), the group will be subject to termination rules T1 or T2 described below.

•

The Receiving RMP MUST return an InvalidMessageParameters fault if both group persistence parameters are present in any request message.

•

1190

If @groupExpiryTime is in use, the Sending RMP MUST NOT send a message in that group with an ExpiryTime value greater than @groupExpiryTime.

1191 1192

b) The group termination parameter sent on the first message in the group SHALL be used on all subsequent messages in that group and SHALL be assigned a value.

1193 1194 1195

c) If the Receiving RMP receives a message with a group termination parameter that is not consistent with the termination parameter used in previous messages for this group, the Receiving RMP MUST return an InvalidMessageParameters fault.

1196 1197 1198 1199

When the group is ordered, the fault SHALL be returned for the message with lowest sequence number that was found inconsistent in the group. If the group is not required to be ordered, the fault SHALL be returned for the first message received that was found inconsistent in the group.

1182 1183

1184 1185 1186

1187 1188

1189

15 November 2004 Page 44 of 72

1200 1201 1202 1203 1204

d) The Sending RMP MAY modify either time-out parameter, sending a subsequent message with the new value. When applying termination rules, the Sending RMP MUST use the value in the message with the highest sequence number sent for the group. The Receiving RMP MUST use the value from the message with the highest sequence number received for the group.

1205 1206 1207

e) @groupMaxIdleDuration can be either increased or decreased without restriction. The Sending RMP may increase or decrease @groupExpiryTime as long as it is never less than the max(ExpiryTime) of the messages sent for the group so far.

1208 1209 1210

The Receiving RMP MUST publish an InvalidMessageParameters Fault for a message with a @groupExpiryTime value less than the max(ExpiryTime) of the messages previously received for the group.

1211

5.1.3 Termination Rules

1212 1213 1214 1215 1216 1217 1218 1219

Termination is the process by which an RMP discontinues the use of a group, allowing the RMP to reclaim resources used by the group. Termination typically involves two steps that may occur at different times: closing and removal. Removal of a group may happen some time after it is closed, allowing an RMP to filter out potential duplicate messages. The general rule is that a group is removed once all of its messages have expired. If we define max(ExpiryTime) as the maximum date and time of all ExpiryTime values of the messages sent for a group (on the Sender side) or received for a group (on the Receiver side), a group will not be removed before max(ExpiryTime) occurs.

1220

There are two general indicators an RMP will use to terminate a group:

1221 1222 1223

a) Message Marker: Information within a message (either Request/MessageId/SequenceNum@last=”true” or the maximum sequence number) indicates the last message for the group. This is used by termination rules T3, T4.

1224 1225 1226

b) Timing: Either the group's lifespan expired or its idle time exceeded a time-out. This is used by termination rules T1, T2. Or due to message expiration, a group with the ordering requirement cannot be delivered. This is used by termination rule T5.

1227 1228

These termination rules apply to both ordered and unordered groups. However, these rules do not apply to groups that contain a single message with no sequence number.

1229

5.1.3.1 Termination by expiration (T1):

1230

Context:

1231

The group specified @groupExpiryTime.

1232

Receiver side:

1233

Triggering event: @groupExpiryTime is in the past.

1234

The RMP MUST close and remove the group.

1235

Sender side:

1236 1237

Triggering event: @groupExpiryTime is in the past (note: in this case, max(ExpiryTime) also is past).

1238

The RMP MUST close and remove the group.

15 November 2004 Page 45 of 72

1239

5.1.3.2 Termination by idle time-out (T2):

1240

Context:

1241

The group specified @groupMaxIdleDuration.

1242

Receiver side:

1243 1244

Triggering event: The time since the last received message for the group is over @groupMaxIdleDuration.

1245 1246 1247 1248

The RMP MUST close the group. But unlike T1, some of its past messages may not have expired yet. In case Duplicate Elimination is required, the RMP MUST NOT remove the group until max (ExpiryTime) is reached in order to make sure all potential duplicates for the group will not be delivered.

1249

Sender side:

1250 1251

Triggering event: The time since the last sent message for the group is over @groupMaxIdleDuration.

1252 1253 1254 1255

The RMP MUST close the group. If GuaranteedDelivery was required, the RMP MUST remove the group once it has received either acknowledgment or notification of delivery failure for all sent messages. If no GuaranteedDelivery was required, the RMP MUST remove the group immediately.

1256

5.1.3.3 Termination by completeness (T3):

1257

Context:

1258

No specific context.

1259

Receiver side:

1260 1261 1262 1263

Triggering event: The RMP receives a message marked last (Request/MessageId/SequenceNum@last=”true”). If all previous messages for the group have been received, the group is closed immediately. Alternately, the group is closed when the RMP receives the last missing message in the group.

1264 1265 1266 1267

The RMP MUST close the group. However, its removal is done according to T1 or T2 depending on which time-out parameter was specified for the group. If no time-out parameter was specified, the group is removed once all of its messages have expired, i.e., the date and time max (ExpiryTime) has passed.

1268

Note:

1269 1270

In the case in which a message is received with an ending marker before all previous messages have been received, the group remains active. No termination process is initiated yet.

1271

Sender side:

1272

Triggering event: The RMP sends a message marked last.

1273 1274 1275 1276

All messages of the group have been sent. The RMP MUST close the group. If GuaranteedDelivery was required, the RMP MUST remove the group once it has received either acknowledgment or notification of delivery failure for all sent messages. If GuaranteedDelivery was not required, the RMP MUST remove the group immediately.

15 November 2004 Page 46 of 72

1277

5.1.3.4 Termination by sequence exhaustion (T4):

1278

Context:

1279

No specific context.

1280

Receiver side:

1281 1282 1283

Triggering event: The RMP receives a message with a sequence number of the maximum value. If all previous messages for the group have been received, the group is closed immediately. Alternately, the group is closed when the RMP receives the last missing message in the group.

1284 1285

The group closing and removal follow the rules in T3, the message with the maximum sequence number acting as a message with the ending mark.

1286

Note:

1287 1288

In case a message is received with the maximum sequence number before all previous messages have been received, the group remains active. No termination process is initiated yet.

1289

Sender side:

1290

Triggering event: The RMP sends a message with a sequence number with the maximum value.

1291 1292

The group closing and removal follow the rules in T3, the message with the maximum sequence number acting as a message with the ending mark.

1293

5.1.3.5 Termination by ordering failure (T5):

1294

Context:

1295

The group requires the Guaranteed Message Ordering reliability feature.

1296

Receiving side:

1297 1298 1299 1300

Triggering event: In an ordered group, a received message expires before delivery or faults with a fault code other than MessageProcessingFailure. If all previous messages for the group have been received, the group is closed immediately. Alternately, the group is closed when the RMP receives the last missing message in the group.

1301

The RMP MUST close the group. The group is removed according to rule T3.

1302

Sender Side:

1303 1304 1305

Triggering event: In an ordered group, an unacknowledged message expires or the RMP receives an RM Fault for this Reliable Message with a fault code other than MessageProcessingFailure.

1306

The RMP MUST close the group. The group is removed according to rule T3.

1307

5.1.3.6 Summary of Group Termination Rules

1308

Conditions for terminating a group in a Receiving RMP:

15 November 2004 Page 47 of 72

Group Closing

Group Removal

When @groupExpiryTime has passed.

(after closing) When @groupExpiryTime has passed.

When the @groupMaxIdleDuration time-out has expired.

(after closing) When Max(ExpiryTime) has passed.

When a group is complete.

(after closing) When Max(ExpiryTime) has passed.

When a group is ordered AND an undelivered message expires or faults.

(after closing) When Max(ExpiryTime) has passed.

Table 26 Conditions for terminating a group – Receiving RMP 1309

Conditions for terminating a group in a Sending RMP: Group Closing

Group Removal

When @groupExpiryTime has passed.

(after closing) When @groupExpiryTime has passed.

When the @groupMaxIdleDuration time-out has expired.

(after closing) In case GuaranteedDelivery is not required, remove the group immediately. Otherwise, remove it if all messages have been either acknowledged or faulted.

When a group is complete.

(after closing) In case GuaranteedDelivery is not required, remove the group immediately. Otherwise, remove it if all messages have been either acknowledged or faulted.

When a group is ordered AND an unacknowledged message expires or faults.

(after closing) Remove the group after all messages have been either acknowledged or faulted.

Table 27 Conditions for terminating a group – Sending RMP

1310

5.2 Attachments

1311 1312

When an RMP implementing this specification uses the W3C Note “SOAP Messages with Attachments” specification [SOAP with Attachments], it MUST follow the following rules:

1313 1314

1) The Sending RMP MUST include the whole SOAP envelope containing the WSReliability header elements in the first MIME part.

1315 1316

2) It MUST set the charset parameter of the Content-Type header of the first MIME part to either UTF-8 or UTF-16.

1317

3) It MAY include zero or more additional MIME parts in a Reliable Message.

1318 1319

4) The Receiving RMP MUST deliver all MIME parts in a Reliable Message to the Consumer.

15 November 2004 Page 48 of 72

1320

6 HTTP Binding

1321 1322

This section specifies two normative bindings of WS-Reliability header elements to SOAP header blocks carried in messages using HTTP as a transport protocol:

1323

•

SOAP 1.1 over HTTP POST binding: An implementation of WS-Reliability MAY support mapping the WS-Reliability header elements as SOAP header blocks in accordance with the SOAP 1.1 HTTP Binding specified in Section 6 of [SOAP 1.1]. In that case, the SOAP Request-response MEP defined in this specification will map to an HTTP requestresponse. The SOAP One-way MEP, as defined in Section 2.3, maps to the request of an HTTP request-response.

•

SOAP 1.2 over HTTP POST binding: An implementation of WS-Reliability MAY support mapping the WS-Reliability header elements as SOAP header blocks in accordance with the SOAP 1.2 HTTP binding for the Request-Response MEP specified in Section 7, “SOAP HTTP Binding”, of [SOAP 1.2 Part 2].

1324 1325 1326 1327 1328

1329 1330 1331 1332 1333 1334 1335 1336 1337 1338

If a Reliable Message request is invoked using SOAP 1.1, all subsequent message exchanges pertaining to that Message Identifier MUST use the SOAP 1.1 protocol. In addition, when an HTTP binding is used, it is RECOMMENDED the RMP comply with WS-I BP 1.1 [WS-I BP 1.1]. When no WSDL describes the messages being exchanged, the previous WS-I conformance requirements should be understood as conformance to the subset of the profile requirements pertaining to the message artifact only.

1339 1340 1341

In case a message encounters a failure in processing the RM headers, the requirements for Fault handling in Section 4.5 apply. When using SOAP 1.1, conformance to the WS-I Basic Profile 1.1 requires the following:

1342

•

For SOAP One-way HTTP binding: the HTTP response entity-body SHALL be empty. If the RM Fault is a Message Format fault, the HTTP status code SHOULD be “400 Bad Request" (see R1113 in [WS-I BP 1.1]); otherwise, the RM fault is a Message Processing fault and the status code SHOULD be "500 Internal Server Error".

•

For SOAP Request-response HTTP binding: the HTTP response contains a SOAP Fault element and has the "500 Internal Server Error" HTTP status code (see R1126 in [WS-I BP 1.1]).

1343 1344 1345

1346 1347 1348 1349 1350

These two requirements for Fault handling apply to all message exchanges described in this section and its sub-sections.

1351 1352 1353 1354

If a ReplyTo element present in a Request element or Poll Request header element sent using the SOAP 1.1 protocol uses the wsrm:BareURI (the default, described in Sections 4.2.3.2.2 and 4.3.1.2) reference scheme and uses the 'http:' URL scheme, the Receiving RMP MUST send the WS-Reliability response using the HTTP binding specified in Section 6 of SOAP 1.1.

1355 1356

If a Reliable Message request is invoked using SOAP 1.2, all subsequent message exchanges pertaining to its Message Identifier MUST use the SOAP 1.2 protocol.

1357 1358 1359 1360

If a ReplyTo element present in a Request element or Poll Request header element sent using the SOAP 1.2 protocol uses the wsrm:BareURI reference scheme and uses the 'http:' URL scheme, the the Receiving RMP MUST send the WS-Reliability response using the HTTP binding for Request-Response MEP specified in SOAP 1.2.

1361 1362 1363

The following subsections specify the mapping of WS-Reliability header elements to HTTP request and response messages for the three RM-Reply Patterns. The Poll RM-Reply Pattern has two variations: synchronous and asynchronous.

15 November 2004 Page 49 of 72

1364 1365

The value of the ReplyPattern/Value element identifies the specific RM-Reply Pattern in use (see Section 4.2.3.1 for details).

1366 1367 1368 1369 1370

This specification requires the transport layer to deliver messages to the reliability layer without corruption. When a request message contains the AckRequested element, the Receiving RMP MUST send an RM-Reply (an Acknowledgment Indication or an RM Fault Indication) for that request. For the Callback and Poll RM-Reply Patterns, a Response element can contain multiple Acknowledgment and/or RM Fault Indications.

1371 1372 1373 1374

For simplicity, the detailed examples show only the use of SOAP 1.1. However, the figures that show the mapping of WS-Reliability elements to HTTP POST request messages and HTTP response messages apply to both the SOAP 1.1 over HTTP POST binding and the SOAP 1.2 over HTTP POST binding.

1375

6.1 Reliable Messaging with Response RM-Reply Pattern Producer Submit

Notify

Sending RMP

Consumer HTTP Request/Response

Deliver

(1) HTTP Request (Reliable Message)

(2) HTTP Response

Respond

Receiving RMP

(Rm-Reply) (Respond Payload)

Figure 9 Response RM-Reply Pattern 1376 1377 1378

As described in general for this RM-Reply Pattern (Section 2.4.1), the Receiving RMP MUST return the RM-Reply with the HTTP response on the same HTTP connection used by the Sending RMP to send the request. This is illustrated in Figure 9.

1379 1380

•

In (1), the Sending RMP initiates an HTTP connection and sends a Message using the HTTP POST method, as in Example 10.

1381 1382

•

In (2), using the same connection, the Receiving RMP sends back to the Sending RMP an HTTP response containing an RM-Reply; in Example 11, the RM-Reply is an Acknowledgment Indication.

1383

15 November 2004 Page 50 of 72

Example 10 Request Message with Response RM-Reply Pattern 1384

1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411

POST /abc/servlet/wsrEndpoint HTTP/1.0 Content-Type: text/xml; charset=utf-8 Host: 192.168.183.100 SOAPAction: "" Content-Length: 755 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > <soap:Header> <Request xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" soap:mustUnderstand="1"> <MessageId groupId="mid://[email protected]"> <SequenceNum number="0" groupExpiryTime="2005-02-02T03:00:33-31:00" /> </MessageId> <ExpiryTime>2004-09-07T03:01:03-03:50</ExpiryTime> <ReplyPattern> <Value>Response</Value> </ReplyPattern> <AckRequested/> <DuplicateElimination/> <MessageOrder/> </Request> </soap:Header> <soap:Body> <Request xmlns="http://example.org/wsr">Request Message</Request> </soap:Body> </soap:Envelope>

15 November 2004 Page 51 of 72

Example 11 Acknowledgment Indication with Response RM-Reply Pattern 1412

HTTP/1.0 200 OK Server: WS-ReliabilityServer Date: Mon, 02 Feb 2004 10:38:32 GMT Content-Language: en Content-Type: text/xml; charset=utf-8 Content-Length: 414

1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429

1430

6.2 Reliable Messaging with Callback RM-Reply Pattern Producer Submit

Consumer Deliver

Notify

Respond

HTTP Request/Response

(1) HTTP Request (Reliable Message)

(2) HTTP Response

Sending RMP

(Respond Payload)

HTTP Request/Response

Receiving RMP

(3) HTTP Request (RM-Reply)

(4) HTTP Response

Figure 10 Callback RM-Reply Pattern 1431 1432

As described in general for this RM-Reply Pattern (Section 2.4.2) and as illustrated in Figure 10, two distinct HTTP request/response exchanges are involved.

1433 1434

•

In (1), the Sending RMP initiates a new HTTP request and sends a Reliable Message with the Callback RM Reply Pattern. Example 12 shows such an HTTP message.

1435

•

In (2), the HTTP response may have an empty entity-body (in case of a SOAP One-way MEP instance).

•

In (3), the Receiving RMP MUST return the RM-Reply on an HTTP connection different from the one the Sending RMP used to send the message. The direction of the HTTP

1436

1437 1438

15 November 2004 Page 52 of 72

connection used by the Receiving RMP is from the Receiving RMP to the Sending RMP. Example 14 shows an Acknowledgment Indication as the RM-Reply.

1439 1440

1441 1442

•

In (4), there is no HTTP entity-body unless the RM-Reply was bundled with a new Reliable Message on a SOAP Request-response MEP instance. Example 12 Request Message with Callback RM-Reply Pattern

1443

1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473

POST /abc/servlet/wsrEndpoint HTTP/1.0 Content-Type: text/xml; charset=utf-8 Host: 192.168.183.100 SOAPAction: "" Content-Length: 863 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > <soap:Header> <Request xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" soap:mustUnderstand="1"> <MessageId groupId="mid://[email protected]"> <SequenceNum number="0" groupExpiryTime="2005-02-02T03:00:33-31:00" /> </MessageId> <ExpiryTime>2004-09-07T03:01:03-03:50</ExpiryTime> <ReplyPattern> <Value>Callback</Value> <ReplyTo> <BareURI>http://wsr-sender.org/abc/wsrmListener</BareURI> </ReplyTo> </ReplyPattern> <AckRequested/> <DuplicateElimination/> <MessageOrder/> </Request> </soap:Header> <soap:Body> <Request xmlns="http://example.org/wsr">Request Message</Request> </soap:Body> </soap:Envelope> Example 13 HTTP response with no content

1474

1475 1476 1477 1478 1479

HTTP/1.0 200 OK Server: WS-ReliabilityServer Date: Mon, 02 Feb 2004 10:38:32 GMT Content-Language: en Content-Type: text/xml; charset=utf-8 Content-Length: 0

15 November 2004 Page 53 of 72

Example 14 Acknowledgment Indication with Callback RM-Reply Pattern 1480

POST /abc/wsrmListener HTTP/1.0 Content-Type: text/xml; charset=utf-8 Host: 192.168.183.200 SOAPAction: "" Content-Length: 414

1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496

1497

6.3 Reliable Messaging with Poll RM-Reply Pattern

1498 1499 1500 1501 1502 1503

The general rules for this RM-Reply Pattern are described in Section 2.4.3. When the Sending RMP issues a PollRequest, the Receiving RMP MAY return the RM-Reply on the HTTP connection used to send the PollRequest message (synchronous), or it MAY return the RM-Reply on a different HTTP connection (asynchronous). Whether the RM-Reply corresponding to the PollRequest is synchronous or asynchronous depends on the presence of a ReplyTo element in the PollRequest element.

1504

6.3.1 Synchronous Poll RM-Reply Pattern Producer Submit

Notify

Consumer HTTP Request/Response

(1) HTTP Request

Deliver

Respond

(Reliable Message)

(2) HTTP Response (Respond Payload)

Sending RMP

HTTP Request/Response

(3) HTTP Request

Receiving RMP

(PollRequest) (4) HTTP Response (RM-Reply)

Figure 11 Synchronous Poll RM-Reply Pattern 1505

1506 1507

Figure 11 illustrates the synchronous variant of the Poll RM Reply Pattern. •

In (1), the Sending RMP initiates a new HTTP Request and sends a Reliable Message with the Poll RM-Reply Pattern.

15 November 2004 Page 54 of 72

1508

•

In (2), the HTTP response may have an empty entity-body (in case of a SOAP One-way MEP instance).

•

In (3), at a later time the Sending RMP initiates a different HTTP Request to send a PollRequest message. The PollRequest does not include the ReplyTo element (see Example 15).

•

In (4), the Receiving RMP returns the RM-Reply in an HTTP response on the same HTTP connection used to send the PollRequest, as illustrated in Figure 11. The HTTP response (4) includes an RM-Reply (e.g., an Acknowledgment Indication as in Example 16).

1509

1510 1511 1512

1513 1514 1515 1516

Example 15 PollRequest message with Synchronous Poll RM-Reply Pattern 1517

1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534

POST /abc/servlet/wsrmListener HTTP/1.0 Content-Type: text/xml; charset=utf-8 Host: 192.168.183.100 SOAPAction: "" Content-Length: 433 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > <soap:Header> <PollRequest xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" soap:mustUnderstand="1"> <RefToMessageIds groupId="mid://[email protected]"> <SequenceNumRange from="0" to="20"/> </RefToMessageIds> </PollRequest> </soap:Header> <soap:Body /> </soap:Envelope>

15 November 2004 Page 55 of 72

Example 16 Synchronous Acknowledgment Indication 1535

1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554

HTTP/1.0 200 OK Server: WS-ReliabilityServer Date: Mon, 02 Feb 2004 10:38:32 GMT Content-Language: en Content-Type: text/xml; charset=utf-8 Content-Length: 456 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > <soap:Header> <Response soap:mustUnderstand="1" xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd"> <SequenceReplies groupId="mid://[email protected]"> <ReplyRange from="0" to="14"/> <ReplyRange from="16" to="20"/> </SequenceReplies> </Response> </soap:Header> <soap:Body /> </soap:Envelope>

6.3.2 Asynchronous Poll RM-Reply Pattern Producer Submit

Notify

Consumer HTTP Request/Response

(1) HTTP Request

Deliver

Respond

(Reliable Message)

(2) HTTP Response (Respond Payload)

HTTP Request/Response

(3) HTTP Request

Sending RMP

(Poll Request)

(4) HTTP Response

Receiving RMP

HTTP Request/Response

(5) HTTP Request (RM-Reply)

(6) HTTP Response

Figure 12 Asynchronous Poll RM-Reply Pattern 1555

1556 1557

Figure 12 illustrates the asynchronous variant of the Poll RM Reply Pattern. •

In (1), the Sending RMP initiates a new HTTP Request and sends a Reliable Message with the Poll RM-Reply Pattern.

15 November 2004 Page 56 of 72

•

In (2), the HTTP response may have an empty entity-body (in the case of a SOAP Oneway MEP instance).

•

In (3), the Sending RMP initiates a new HTTP request and sends a PollRequest message. Note that in Example 17, the PollRequest element has a ReplyTo element.

1562

•

In (4), the HTTP response (4) has no HTTP entity-body (see Example 13).

1563 1564

•

In (5), the Receiving RMP sends the RM-Reply in a different HTTP request to the listener identified by the ReplyTo element (see Example 18).

1565

•

In (6), the HTTP response has no HTTP entity-body (see Example 13).

1558 1559

1560 1561

Example 17 PollRequest message with Asynchronous Poll RM-Reply Pattern 1566

1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587

POST /abc/servlet/wsrmListener HTTP/1.0 Content-Type: text/xml; charset=utf-8 Host: 192.168.183.100 SOAPAction: "" Content-Length: 553 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > <soap:Header> <PollRequest xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" soap:mustUnderstand="1"> <RefToMessageIds groupId="mid://[email protected]"> <SequenceNumRange from="0" to="20"/> </RefToMessageIds> <ReplyTo> <BareURI>http://wsr-sender.org/xyz/servlet/wsrmListener </BareURI> </ReplyTo> </PollRequest> </soap:Header> <soap:Body /> </soap:Envelope>

15 November 2004 Page 57 of 72

Example 18 Asynchronous Acknowledgment Indication 1588

1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605

POST /xyz/servlet/wsrmListener HTTP/1.0 Content-Type: text/xml; charset=utf-8 Host: 192.168.183.200 SOAPAction: "" Content-Length: 456 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > <soap:Header> <Response soap:mustUnderstand="1" xmlns="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd"> <SequenceReplies groupId="mid://[email protected]"> <ReplyRange from="0" to="14"/> <ReplyRange from="16" to="20"/> </SequenceReplies> </Response> </soap:Header> <soap:Body /> </soap:Envelope>

15 November 2004 Page 58 of 72

1606

7 Conformance

1607 1608

In order to conform to this specification, an implementation must satisfy all of the following conditions:

1609

•

It has implemented all required syntax, features and behaviors.

1610

•

It complies with the following interpretation of the keywords OPTIONAL and MAY: as stated in [RFC2119], when these keywords apply to the behavior of the implementation, the implementation is free to support these behaviors or not.

•

It MUST be capable of processing the prescribed failure mechanism for those optional features it has chosen to implement. If an RMP conforming to this requirement has implemented an optional feature, syntax or behavior defined in this specification, it can interoperate with another implementation that has not.

•

It MUST be capable of generating the prescribed failure mechanism for those optional features it has not chosen to implement. If an RMP conforming to this requirement has not implemented an optional feature, syntax or behavior defined in this specification, it can interoperate with another implementation that has.

1611 1612

1613 1614 1615 1616

1617 1618 1619 1620

15 November 2004 Page 59 of 72

1621

8 References

1622 1623

[ebMS] "Message Service Specification Version 2.0", OASIS ebXML Messaging Services Technical Committee, OASIS Standard, 1 April 2002. Available at

1624

http://www.ebxml.org/specs/ebMS2.pdf

1625 1626

[RFC1738] "Uniform Resource Locators (URL)", T. Berners-Lee et al, RFC 1738, IESG and IETF, December 1994. Available at

1627

http://www.ietf.org/rfc/rfc1738.txt

1628 1629

[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Bradner, S., IESG and IETF, March 1997. Available at

1630

http://www.ietf.org/rfc/rfc2119.txt

1631 1632

[RFC2392] “Content-ID and Message-ID Uniform Resource Locators”, RFC2392, E. Levinson, IESG and IETF, August 1998. Available at

1633

http://www.ietf.org/rfc/rfc2392.txt

1634 1635

[RFC2396] "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, Tim Berners-Lee et al, IESG and IETF, August 1998. Available at

1636

http://www.ietf.org/rfc/rfc2396.txt

1637 1638

[RFC2616] "Hypertext Transfer Protocol – HTTP/1.1", RFC 2616, R. Fielding et al, IESG and IETF, June 1999. Available at

1639

http://www.ietf.org/rfc/rfc2616.txt

1640 1641

[RFC2822] "Internet Message Format", RFC 2822, P. Resnick, Editor, IESG and IETF, April 2001. Available at

1642

http://www.ietf.org/rfc/rfc2822.txt

1643 1644

[SOAP 1.1] "Simple Object Access Protocol (SOAP) 1.1", Don Box et al, W3C Note, 8 May, 2000. Available at

1645

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

1646 1647 1648

[SOAP 1.2 Part 1] "SOAP 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, eds., W3C Recommendation, 24 June 2003. Available at

1649

http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

15 November 2004 Page 60 of 72

1650 1651 1652

[SOAP 1.2 Part 2] "SOAP 1.2 Part 1: Adjuncts", Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, eds., W3C Recommendation, 24 June 2003. Available at

1653

http://www.w3.org/TR/2003/REC-soap12-part2-20030624/

1654 1655

[SOAP with Attachments] "SOAP Messages with Attachments”, John J. Barton, Satish Thatte, Henrik Frystyk Nielsen, W3C Note, 11 December 2000, Available at

1656

http://www.w3.org/TR/SOAP-attachments

1657 1658

[XML] "Extensible Markup Language (XML) 1.0 (Third Edition)", Tim Bray et al, eds., W3C Recommendation, first published 10 February 1998, revised 4 February 2004. Available at

1659

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

1660 1661

[XML Namespaces] "Namespaces in XML", Tim Bray et al., eds., W3C Recommendation, 14 January 1999. Available at

1662

http://www.w3.org/TR/1999/REC-xml-names-19990114/

1663 1664

[XML Schema Part 1] "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, eds., W3C Recommendation, 2 May 2001. Available at

1665

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/

1666 1667

[XML Schema Part 2] "XML Schema Part 2: Datatypes", Paul V. Biron and Ashok Malhotra, eds. W3C Recommendation, 2 May 2001. Available at

1668

http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

1669 1670

[XPath 1.0] "XML Path Language (XPath) Version 1.0", James Clark, Steve DeRose, eds., W3C Recommendation, 16 November 1999. Available at

1671

http://www.w3.org/TR/1999/REC-xpath-19991116

1672 1673

[WSDL 1.1] “Web Services Description Language (WSDL) 1.1”, Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weerawarana, eds., W3C Note, 15 March 2001. Available at

1674

http://www.w3.org/TR/2001/NOTE-wsdl-20010315

1675 1676 1677

[WS-I BP 1.1] “Basic Profile Version 1.1”, Keith Ballinger, David Ehnebuske, Christopher Ferris, Martin Gudgin, Mark Nottingham, Prasad Yendluri, eds., WS-I specification, 8 August 2004. Available at

1678

http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-07-21.html

1679 1680 1681

[WSS] "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds, OASIS Standard 200401, March 2004. Available at

1682

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

15 November 2004 Page 61 of 72

1683

Appendix A.Schema (Normative)

1684 1685

The schemas for this specification have the following URLs and are located using the filenames shown in the table: Schema Namespace URL

File name

Prefix

http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd ws-reliability1.1.xsd

wsrm

http://docs.oasis-open.org/wsrm/2004/06/reference-1.1.xsd

reference-1.1.xsd

ref

http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd

fnp-1.1.xsd

fnp

http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd

wsrmfp-1.1.xsd

wsrmfp

Table 28 WS-Reliability Schema Prefixes 1686 1687 1688

RMPs MUST include the SOAP mustUnderstand attribute (defined in the same namespace used for the soap:Envelope element) in all Reliable Messaging specified header blocks and MUST observe the following restrictions:

1689

•

For SOAP 1.1, the mustUnderstand attribute value is restricted to "1".

1690

•

For SOAP 1.2, the mustUnderstand attribute value is restricted to "1" or "true".

15 November 2004 Page 62 of 72

1692

Appendix B.WS-Reliability Features, Properties and Compositors (Normative and Optional)

1693

B.1. Introduction

1694 1695 1696 1697 1698 1699 1700 1701 1702

Users of a Web Service need to be aware of the reliability capabilities (RM capabilities) the service supports or requires. One practical location to advertise these capabilities is in the service description (WSDL document), which allows publishing both abstract service definitions and concrete protocol details (bindings). This allows clients (including other Web services) to easily obtain information about specific capabilities (such as guaranteed delivery, duplicate elimination, message ordering, and the supported reply patterns) of a specific Web service before calling the service. While bundling RM capabilities with the service description may not be desirable in all cases, this convenient approach often should be appropriate. The WSDL annotation mechanism described here adds such capability assertions in a flexible way.

1703 1704 1705

WS-Reliability uses the WSDL 1.1 extensibility points to define an extensible framework consisting of features, properties and compositors. This framework addresses the needs of a reliable Web service to advertise its capabilities and the composability of those capabilities.

1706

The following extensibility elements are relevant to RM capabilities:

1691

1707

•

feature – see Appendix B.3.2.

1708

•

property – see Appendix B.3.3.

1709

•

compositor – see Appendix B.3.1.

1710 1711 1712

An annotation composed with the above extensibility elements will specify the reliability features and properties associated with specific WSDL constructs. Features and properties represent RM capabilities; compositors specify how these capabilities are composed.

1713 1714

This would, for example, allow a Web service description to advertise that clients invoking the service must use duplicate elimination or message ordering.

1715

B.2. Conformance

1716 1717

Implementations of WS-Reliability are expected (though not required) to understand the WSDL extensibility points defined in this section.

1718 1719 1720 1721

Understanding these extensibility points promotes interoperability: a service advertises its supported and required features when its WSDL document contains these extensibility points. Therefore it is RECOMMENDED that implementations recognize, understand and support these extensibility points.

1722 1723

It is also possible for services to advertise features through other channels (such as UDDI) in addition to these extensibility points.

15 November 2004 Page 63 of 72

1724

B.3. WSDL Extensibility Elements

1725

B.3.1.Compositor

1726 1727 1728 1729 1730 1731 1732 1733 1734

The compositor semantics describe how features and properties are composed for the enclosing component (or WSDL 1.1 element). The compositor's semantics determine whether the usage of composed elements by a client to the service is required or optional. All of the RM capabilities represented by these elements must be supported by the service. A compositor element can occur as a child element of wsdl11:portType, wsdl11:operation (which itself may be a child of wsdl11:portType or wsdl11:binding), wsdl11:binding, wsdl11:service and wsdl11:port. The compositor element uses the extensibility defined by WSDL 1.1. A compositor element specifies the semantics for combining its children elements. These children elements can be additional compositors, features, properties or extensibility elements.

1735

A compositor element is expressed by the following pseudo-syntax:

1736

1737 1738 1739

<fnp:compositor uri="..." name="NCName"?> [fnp:feature/> | <fnp:property/> | <fnp:compositor/> | <extensibility-element/>]+ </fnp:compositor>

1740 1741 1742 1743 1744 1745

The uri attribute of the compositor specifies its semantics. Four different compositors (URIs) and their capability-related semantics are described below. It is possible to provide additional compositors by using other URIs. The possibility of additional compositors and the existence of extensibility points (represented by "<extensibility-element>") make the framework extensible. The optional @name identifies the compositor. An element built with such compositors represents an RM capability.

1746

•

1747 1748

all: this compositor specifies that a service invocation MUST comply with all of the children elements representing RM capability assertions. This compositor is identified by the URI:

1749

http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositors/all

1750

•

1751 1752

choice: this compositor specifies that a service invocation MUST comply with exactly one of the possibly many children elements representing RM capability assertions. This compositor is identified by the URI:

1753

http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositors/choice

1754

•

1755 1756

one-or-more: this compositor specifies that a service invocation MUST comply with at least one of the possibly many children elements representing RM capability assertions. This compositor is identified by the URI:

1757

http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositors/one-or-more

1758

•

1759 1760

zero-or-more: this compositor specifies that a service invocation MAY comply with one or more of the children elements representing RM capability assertions. This compositor is identified by the URI:

1761

http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositors/zero-or-more

1762

Examples for each compositor are provided in Appendix B.7 below.

1763 1764

Compositors specified at different WSDL components are implicitly aggregated using the 'all' compositor at the dependent WSDL component. Consider the example below:

15 November 2004 Page 64 of 72

1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784

<wsdl11:definitions> ... <wsdl11:portType name="myPortType"> <fnp:compositor uri="..." name="A"> ... </fnp:compositor> ... </wsdl11:portType> <wsdl11:binding name="myBinding" type="myPortType"> <fnp:compositor uri="..." name="B"> ... </fnp:compositor> ... <wsdl11:binding> <wsdl11:service name="myService"> <wsdl11:port name="myPort" binding="myBinding> ... </wsdl11:port> </wsdl11:service> <wsdl11:definitions>

1785 1786 1787

The compositor specified at the wsdl11:portType "myPortType" and the compositor specified at wsdl11:binding "myBinding" are aggregated at the dependent wsdl11:port "myPort" using the 'all' compositor. The equivalent compositor at "myPort" is

1788

1789 1790 1791 1792 1793 1794 1795

<fnp:compositor uri="http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositor/all"> <fnp:compositor uri="..." name="A"> </fnp:compositor> <fnp:compositor uri="..." name="B"> ... </fnp:compositor> </fnp:compositor>

1796

B.3.2.Feature

1797 1798

A feature describes an abstract RM capability or assertion associated with a WSDL element. A feature can occur only as a child of a compositor.

1799 1800 1801

The enclosing compositor(s) define(s) whether or not the usage of a feature is required. A feature is identified by a URI. Recognizing the URI of a feature implies understanding the feature identified by that URI.

1802

A feature element is expressed by the following pseudo-syntax:

1803

<fnp:feature uri="..."> [<fnp:compositor/> | <extensibility-element/>]* </fnp:feature>

1765

1804 1805

15 November 2004 Page 65 of 72

1806

B.3.3.Property

1807 1808

A property is identified by a QName. A property is an assertion or constraint on a specific RM capability and its value(s). A property can occur only as a child of a compositor.

1809 1810 1811 1812 1813 1814 1815

Typically, properties are (but are not required to be) associated with a feature and are described in a feature specification. The QName identifier of a property uniquely identifies the property. Recognizing the property QName identifier implies understanding the semantics associated with that property. The property QName identifier typically points to a global XML Schema element declaration. A property specification typically specifies the schema containing this global element declaration. There may be a constraint on the set of values a property can have; such a constraint is specified by a QName identifying an XML Schema type.

1816

1817 1818 1819 1820

<fnp:property name="xs:QName"> [<fnp:value>xs:anyType</fnp:value> | <fnp:constraint>xs:QName</fnp:constraint>] [<extensibility-element/>]* </fnp:property>

1821

B.4. WS-Reliability Feature

1822

The WS-Reliability feature is identified by the URI

1823

http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd

1824 1825

This feature URI identifies the WS-Reliability specification. Understanding this URI implies understanding the WS-Reliability specification.

1826

B.5. WS-Reliability Properties

1827 1828

This section identifies properties for the WS-Reliability specification. Typically these properties are scoped within the feature identified by the URI

1829

http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd

1830

B.5.1.Guaranteed Delivery Property

1831 1832 1833

This property is identified by the QName "wsrmfp:GuaranteedDelivery" and corresponds to the semantics specified by the WS-Reliability guaranteed delivery semantics. The type of this property is "xs:boolean".

1834

B.5.2.Duplicate Elimination Property

1835 1836 1837

This property is identified by the QName "wsrmfp:NoDuplicateDelivery" and corresponds to the semantics specified by the WS-Reliability duplicate elimination semantics. The type of this property is "xs:boolean".

1838

B.5.3.Message Ordering Property

1839 1840 1841

This property is identified by the QName "wsrmfp:OrderedDelivery" and corresponds to the semantics specified by the WS-Reliability message ordering semantics. The type of this property is "xs:boolean".

15 November 2004 Page 66 of 72

1842

B.5.4.Reply Pattern Property

1843 1844 1845

This property is identified by the QName "wsrmfp:ReplyPattern" and corresponds to the semantics specified by the WS-Reliability reply pattern options. The type of this property is "xs:string". (values: Response, Poll, Callback)

1846

B.6. Compositor Examples

1847

B.6.1.Example for the "all" compositor

1848

1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868

<wsdl11:portType name="Example-1"> <fnp:compositor uri="http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositor/all"> <fnp:feature uri="http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd" <fnp:compositor uri= "http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositor/all"> <fnp:property name="wsrmfp:NoDuplicateDelivery"> <fnp:value>true</fnp:value> </fnp:property> <fnp:property name="wsrmfp:OrderedDelivery"> <fnp:value>true</fnp:value> </fnp:property> <fnp:property name="wsrmfp:GuaranteedDelivery"> <fnp:value>true</fnp:value> </fnp:property> </fnp:compositor> </fnp:feature> </fnp:compositor> ... </wsdl11:portType>

1869 1870 1871 1872

In the example above, the reliability feature identified by URI "http://docs.oasisopen.org/wsrm/2004/06/wsrmfp-1.1.xsd" is required by the portType. This feature consists of three properties, all of which are required because of the semantics of the 'all' compositor that composes the three properties.

15 November 2004 Page 67 of 72

1873

B.6.2.Example for the "choice" compositor:

1874

1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894

<wsdl11:binding name="Example-2"> <fnp:compositor uri="http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositor/all"> <fnp:feature uri="http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd" <fnp:compositor uri= "http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositors/choice"> <fnp:property name="wsrmfp:ReplyPattern"> <value>Response</value> </fnp:property> <fnp:property name="wsrmfp:ReplyPattern"> <value>Callback</value> </fnp:property> <fnp:property name="wsrmfp:ReplyPattern"> <value>Poll</value> </fnp:property> </fnp:compositor> </fnp:feature> </fnp:compositor> ... </wsdl11:binding>

1895 1896 1897

In the example above, the reliability feature identified by URI "http://docs.oasisopen.org/wsrm/2004/06/wsrmfp-1.1.xsd" is required by the portType. This feature consists of three properties composed by the 'choice' compositor; the client must choose one.

15 November 2004 Page 68 of 72

1898

B.6.3.Example for the "one-or-more" compositor:

1899

1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919

<wsdl11:portType name="Example-3"> <fnp:compositor uri="http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositor/all"> <fnp:feature uri="http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd" > <fnp:compositor uri= "http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositor/one-or-more"> <fnp:property name="wsrmfp:NoDuplicateDelivery"> <fnp:value>true</fnp:value> </fnp:property> <fnp:property name="wsrmfp:OrderedDelivery"> <fnp:value>true</fnp:value> </fnp:property> <fnp:property name="wsrmfp:GuaranteedDelivery"> <fnp:value>true</fnp:value> </fnp:property> </fnp:compositor> </fnp:feature> </fnp:compositor> ... </wsdl11:portType>

1920

B.6.4.Example for the "zero-or-more" compositor:

1921

<wsdl11:portType name="Example-4"> <fnp:compositor uri="http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositor/all"> <fnp:feature uri="http://docs.oasis-open.org/wsrm/2004/06/wsrmfp-1.1.xsd" <fnp:compositor uri= "http://docs.oasis-open.org/wsrm/2004/06/fnp-1.1.xsd/compositor/zero-or-more"> <fnp:property name="wsrmfp:NoDuplicateDelivery"> <fnp:value>true</fnp:value> </fnp:property> <fnp:property name="wsrmfp:OrderedDelivery"> <fnp:value>true</fnp:value> </fnp:property> <fnp:property name="wsrmfp:GuaranteedDelivery"> <fnp:value>true</fnp:value> </fnp:property> </fnp:compositor> </fnp:feature> </fnp:compositor> ... </wsdl11:portType>

1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941

15 November 2004 Page 69 of 72

1942

Appendix C.Acknowledgments

1943 1944

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

1945

David Ingham, Arjuna Technologies Limited

1946

Joseph Chiusano, Booz Allen Hamilton

1947

Peter Furniss, Choreology Ltd

1948

Jeff Turpin, Cyclone Commerce

1949

Pramila Mullan, France Telecom

1950

Jacques Durand, Fujitsu

1951

Kazunori Iwasa (Secretary), Fujitsu

1952

Tom Rutt (Chair), Fujitsu

1953

Jishnu Mukerji, Hewlett-Packard

1954

Robert Freund, Hitachi

1955

Eisaku Nishiyama, Hitachi

1956

Nobuyuki Yamamoto, Hitachi

1957

Ben Bloch, Individual

1958

Mark Hansen, Individual

1959

Paolo Romano, Individual

1960

Dock Allen, Mitre Corporation

1961

Junichi Tatemura, NEC Corporation

1962

Alan Weissberger, NEC Corporation

1963

Magdolna Gerendai, Nokia

1964

Szabolcs Payrits, Nokia

1965

Mark Peel, Novell

1966

Sunil Kunisetty (Secretary), Oracle

1967

Anish Karmarkar, Oracle

1968

Jeff Mischkinsky, Oracle

1969

Marc Goodner (Secretary), SAP

1970

Pete Wenzel, SeeBeyond Technology Corporation

1971

Doug Bunting (Secretary), Sun Microsystems

15 November 2004 Page 70 of 72

1972

Tony Graham, Sun Microsystems

1973

Chi-Yuen Ng, University of Hong Kong

1974

Patrick Yee, University of Hong Kong

1975

Prasad Yendluri, webMethods, Inc.

1976

Scott Werden, WRQ, Inc.

1977

And the following people made contributions to produce Ver 1.0 of this specification:

1978 1979 1980 1981 1982 1983 1984 1985 1986 1987

Colleen Evans, Sonic Software Corporation / Dave Chappell, Sonic Software Corporation / Doug Bunting, Sun Microsystems, Inc. / George Tharakan, Sun Microsystems, Inc. / Hisashi Shimamura, NEC Corporation / Jacques Durand, Fujitsu Software Corporation / Jeff Mischkinsky, Oracle Corporation / Katsutoshi Nihei, NEC Corporation / Kazunori Iwasa, Fujitsu Limited / Martin Chapman, Oracle Corporation / Masayoshi Shimamura, Fujitsu Limited / Nicholas Kassem, Sun Microsystems, Inc. / Nobuyuki Yamamoto, Hitachi Limited / Sunil Kunisetty, Oracle Corporation / Tetsuya Hashimoto, Hitachi Limited / Tom Rutt, Fujitsu Software Corporation / Yoshihide Nomura, Fujitsu Limited / Akira Ochi, Fujitsu Limited / Hirotaka Hara, Fujitsu Limited / Hiroyuki Tomisawa, Hitachi Limited / Katsuhisa Nakazato, Fujitsu Limited / Masahiko Narita, Fujitsu Limited / Nobuyuki Saji, NEC Corporation / Shuichi Imabayashi, Fujitsu Limited

15 November 2004 Page 71 of 72

1988

Appendix D.Notices

1989 1990 1991 1992 1993 1994 1995 1996 1997

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

1998 1999 2000

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

2001

2002 2003 2004 2005 2006 2007 2008 2009 2010

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

2011 2012

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

2013 2014 2015 2016 2017

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

15 November 2004 Page 72 of 72

WS-Reliability v1.1 (2004-11-01)

Related documents