RELIABILITY OF MESSAGES SENT AS RESPONSES OVER AN UNDERLYING

1 CALIBRATION AND RELIABILITY TESTS OF ENVIRONMENTAL MOBILE SENSORS
18 M ODULE PEPASU115 RELIABILITY OF NONREPAIRABLE COMPONENTS M
18 THE RELIABILITY AND VALIDITY OF LAST MENSTRUAL PERIOD

329 RELIABILITY AND ITS RELATION RELIABILITY AND
6TH INTERNATIONAL SYMPOSIUM ON RELIABILITY ENGINEERING AND RISK MANAGEMENT
ALAY S & KOÇAK S (2002) VALIDITY AND RELIABILITY

Rel 2: req-resp need be accommodated, especially means Ack needs be bundled with

Reliability of Messages Sent as Responses over an Underlying Request-response Protocol.

(DRAFT)


Jacques Durand (Fujitsu Software)

Hamid BenMalek (Fujitsu Software)

With contribution from Alan Weissberger (individual)

Introduction


Business payloads are often carried over protocol responses. This is the case in request-response message exchange patterns or when message pulling is being used (e.g. by eBusiness SME partners in order to overcome their connectivity constraints).


This draft investigates what is the meaning of applying reliability to the response leg of a request-response protocol that is underlying SOAP. Intuitively, the reliability of a response message in a request-response MEP depends on the reliability of the request message. This draft shows how and to what extent the reliability of the request leg supports – but is no substitute for - the reliability of the response leg.


The reliability model and QoS has been specified in WS-Reliability 1.1 for application to the request leg of an underlying protocol. It remains to be determined under which conditions the reliability of the response leg can be supported.


Before getting into more details, consider the three following aspects in reliability:

  1. the message protocol– the wire manifestation - and its semantics,

  2. the functions of the RMP ( resending, duplicate elimination, reordering …)

  3. the QoS definitions, or reliability contracts between application components and RMP.


The relationship between (a)(b)(c) is:

  1. supports (b)

  2. supports (c)


WS-Reliability 1.1 has so far specified (a) and (c), and when describing or mentioning (b), did it in a non-normative and illustrative way on how (c) may be supported or interpreted. Also, the protocol (a) is defined with the feasibility and performance of (b) functions in mind. This draft is extending on notions defined in WS-Reliability, though clearly its proposal on the QoS aspect is unrelated to any particular reliability protocol.


Some of the conclusions of this draft are:








Assumed Messaging Model:



RELIABILITY OF MESSAGES SENT AS RESPONSES OVER AN UNDERLYING

Guaranteed Delivery of the Response message in a request-response MEP instance




Quality of Service definition:


When the GuaranteedDelivery Agreement Item is enabled for the response message in a request-response MEP, the following conditions must also be satisfied:

One of the two following outcomes SHALL occur for each SubmitResponse invocation that follows a successfully delivered SOAP request message: either:

(1) the Response-receiving RMP successfully delivers (DeliverResponse invocation) the payload to its associated Consumer or

(2) it notifies (Notify invocation) the Response-consumer of a delivery failure for the response.

In case (2) an additional delivery failure to the Response-producer by the Response-sending RMP may occur.



Functional and Protocol Aspects: (WS-Reliability)


The request message submitted with Submit operation, must use the wsrm:Response RM-Reply Pattern. When under GuaranteedDelivery, the response message resulting from SubmitResponse invocation, may or may not contain a wsrm:Request element. If the Response message includes a wsrm:Request element, this element must use Callback RM-Reply Pattern with AckRequested element.


One of the two following successful message exchanges is expected between two RMPs (A) and (B), depending on whether the option to acknowledge the response has been chosen :


Option 1: No acknowledgement is expected for the response (only for the request):


(1.a) A request B

(1.b) A response + Ack1 B


Only A is expected to notify its party of a delivery failure of the response. A failure to receive Ack1 is tied to a failure to receive the response. In both cases, a resending of the request is expected.


Recovery case:

(1.a) A request B

(1.b) (message lost) response + Ack1 B

(2.a) A resent request B

(2.b) A (duplicate of) response of 1.b + Ack1 B



Option 2: An acknowledgement is expected for the response (the response contains a wsrm:Request element):


(1.a) A request B

(1.b) A response + Ack1 B

(2.a) A Ack2 B


Note that two separate transactions take place on the underlying protocol: (1.a)+(1.b) and (2.a).

In case of failure of 1.b, Ack2 serves primarily for allowing notification of delivery failure on B side. B MUST notify its party of the failure to deliver the response.


In both cases, when failing to get Ack1, the Request-sending RMP is expected to initiate the resending of the request. The resending of the response by the Response-sending RMP is conditioned by the reception of the resent request.

The Response-sending RMP must send the submitted response message (SubmitResponse) over the response of the request-response instance that carried the related request message. Once sent, the same copy of the response message (a duplicate) must be sent by the Response-sending RMP as response of any subsequently received duplicate of the same request.


NOTE: Of the three basic reliability QoS assurances - at-least-once, at-most-once, in-order -, Guaranteed Delivery (at-least-once) can be seen as close to a transactional behavior. At-least-once for a request-response MEP instance has some of the characteristics of a transactional contract. However as often the case when a very specific yet very common pattern falls under a more general solution, the latter may not leverage well the performance opportunities offered by this specific pattern. Using a transactional protocol like 2PC, even when adapted to WS such as in WS-AtomicTransaction, would simply be unacceptable from an overhead (registration, extra-messages…) and performance perspective.


Duplicate Elimination of the Response message in a Request-response MEP instance


Quality of Service definition:


When the NoDuplicateDelivery Agreement Item is enabled for the response, a message resulting from a SubmitResponse invocation SHALL NOT be delivered twice or more to the Response-consumer.


NOTE: this definition is analogous to the definition used for the request message, in WS-Reliability 1.1.


Functional and Protocol Aspects: (WS-Reliability)


Same as for the request.



Ordering of the Response message in a Request-response MEP instance


Quality of Service definition:


NOTE: The main objective of response ordering, is to guarantee that a request-sending application will get a sequence of responses that matches the sequence of requests it has submitted.

The definition below differs from the in-order notion defined for the request message alone, in that the ordering of responses is conditioned by the ordering of requests (submission of requests). An ordering of response messages alone is of little interest, as the sending order of these responses is predicated on the reception order of the requests.


Definition:


When the OrderedDelivery Agreement Item is enabled for a response, response messages resulting from a sequence of request messages SHALL be delivered to the Response-consumer (DeliverResponse) in the same order as the related requests were submitted (Submit) by the Request-producer.


Note: this definition achieves the ordering of responses without requiring the ordering of the requests. It may always be composed with ordering of the request as defined in 1.1, if desirable. It is inline with properties expected from request-response protocols, such as pipelining, (see RFC2616).



Functional and Protocol Aspects: (WS-Reliability)


The request-sending RMP implements the ordering. It does not need doing so differently than in WS-Reliability 1.1, assuming that each response is given a sequence number equal to the sequence number of the request.



ARTICLE 7 POWER RELIABILITY R840 REPORT OF IMPENDING EMERGENCIES
CHAPTER 5 EXERCISE VALIDITY AND RELIABILITY EXERCISE PROVIDE A
CHAPTER SUMMARY CHAPTER 4 VALIDITY RELIABILITY AND GENERALIZABILITY


Tags: messages sent, request messages, underlying, responses, reliability, messages