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

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).

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.

• 
  The reliability aspect (c) namely QoS definitions (at-least-once, at-most-once, in-order) needs be partially modified in order to make sense for a response, and to accommodate the constraints of a request-response MEP.
  
• 
  Statements on a reliability QoS for the response leg should in some cases be associated with appropriate requirements on the reliability QoS of the request leg. Supporting such a combined QoS is easier for RMPs that already implement WS-R 1.1 (aspect (b)).
  
• 
  No change in the protocol definition (a) is required, and few new functions (b) need be supported, assuming proper modifications are made in (c).
  

• 
  Response messages are submitted to the RMP using the abstract operation “SubmitResponse” (previously “Respond”).
  
• 
  Response messages are delivered to a Consumer application using the abstract operation “DeliverResponse” (instead of Notify). Delivery failure notification still uses Notify.
  
• 
  the RMP roles Sending and Receiving (as well as Producer / Consumer) are reversed when sending the Response message. In order to avoid confusion, the expressions Request-sending RMP (equivalent to Response-receiving RMP) and Response-sending RMP (equivalent to Request-receiving RMP) will be used instead.
  

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:

• 
  GuaranteedDelivery is also enabled for the request message,
  
• 
  DuplicateElimination is also enabled for the request message.
  

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.

Directory: committees -> download.php
download.php -> Emergency Interoperability Consortium Membership Meeting
download.php -> Technical Communicators, Get ready: Here comes Augmented Reality! Rhonda Truitt
download.php -> Oasis set tc
download.php -> Iepd analyze Requirements Use Cases for edxl situation reporting messages Draft Version 4
download.php -> Technical Committee: oasis transformational Government Framework tc chair
download.php -> Ibops protocol Version 0 Working Draft 2 9 March 2015 Technical Committee
download.php -> Service Component Architecture sca-j common Annotations and apis Specification Version 1 Committee Draft 03 – Rev1 + Issue 127
download.php -> Scenario Two – Hurricane Warning
download.php -> Technical Committee: oasis augmented Reality in Information Products (arip) tc chairs
download.php -> This is intended as a Non-Standards Track Work Product. [Type the document title]

Download 19.29 Kb.

Share with your friends: