Respons Reliability Scenarious using WS-Reliability 1.1

[Tom Rutt <tom@coastin.com>]

attached is a contribution for discussion at the F2F

Tom RUtt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

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

Scenarios for Reliable response using WS-Reliability 1.1

 

This short paper presents two scenarios which demonstrate capabilities allowing a receiver to offer reliability in the response.

 

The reliability features for the response would be the same as that for the request (e.g., guaranteed delivery, duplicate elim, ordered delivery.� Note that in both of these scenarios, duplicate elimination occurs at the receiver whether it is requested or not, as a side effect of the receiver buffering response payload.

1          Reliability for Response payload by waiting for resend

This approach has some disadvantages:

• There is no way for A to request reliability for the Response Payload,
• B has to hold Payload2 until the original request expires.

 

Normal transaction (no need to resend)

 

(1.a) A� rm:Request(id=1) + Payload1� B

(1.b) A � Payload2 + rm:Ack(id=1) � B

 

We address here the case where the response message (1.b) failed. The solution is for B to wait to resend the response over an HTTP response, itself part of a resend of the original HTTP request. A successful recovery will look like this:

 

(1.a) A� rm:Request(id=1) + Payload1 � B

(1.b)�������� Payload2 + rm:Ack(id=1) � B

(2.a) A� rm:Request(id=1) + Payload1 � B

(2.b) A � Payload2 + rm:Ack(id=1) � B

 

Note: If B is supporting reliability of response Payload using this approach, the contents of Payload2� sent in 2.b will the same as what was sent in 1.b, whether or not duplicate elimination is explicitly requested)

 

2          Reliability for Response payload using piggyback request for callback ack

 

This approach has the advantage that B does not have to hold Payload2 after it receives the callback ack from A.

 

This approach still has some disadvantages:

• There is no way for A to request reliability for the Response Payload
• Will not work if A is behind Firewall

 

 

(1.a) A� rm:Request(id=1) + Payload1� B

(1.b) A � Payload2 + rm:Ack(id=1) + rm:Request(id=2, ReplyTo=B) � B

(2.a) A � rm:Ack(id=2) � B

 

We address here the case where the response message (1.b) failed. The solution is to resend the response over an HTTP response, itself part of a new HTTP transaction that involves resending the request. In other words, we consider that the entire HTTP transaction (1) has failed, and redo it. A successful recovery will look like this:

 

(1.a) A� rm:Request(id=1) + Payload1 � B

(1.b)�������� Payload2 + rm:Ack(id=1) + rm:Request(id=2, ReplyTo=B) �� B

(2.a) A� rm:Request(id=1) + Payload1 � B

(2.b) A � Payload2 + rm:Ack(id=1) + rm:Request(id=2, ReplyTo=B) �� B

(3.a) A � rm:Ack(id=2) � B

 

Note: If B is supporting reliability of response Payload using this approach, the contents of Payload2� sent in 2.b will the same as what was sent in 1.b, whether or not duplicate elimination is explicitly requested)

 

Variant 1, Case of lost Ack:

 

In case the Ack itself was lost, we�ll have the following exchange:

 

(1.a) A� rm:Request(id=1) + Payload1� B

(1.b) A � Payload2 + rm:Ack(id=1) + rm:Request(id=2, ReplyTo=B) � B

(2.a) A � rm:Ack(id=2)���������

 

B will retain its copy of Payload2 until the expiry time for request with id=1.

 

B cannot just resend the response (1.b), since A is satisfied by receiving rm:ack with id=1.

 

Proposal 1.2:

 

The conventional approach here would be to consider that the transaction (1) has failed, and redo it. However, it was successful. Can we recover without redoing it?

Option 1.3.1: RMP(B) uses polling (status request) to verify that RMP(A) got the response.

 

(1.a) A� rm:Request(id=1) + Payload1� B

(1.b) A � Payload2 + rm:Ack(id=1) + rm:Request(id=2, ReplyTo=B) � B

(2.a) A � rm:Ack(id=2)���������

 

(3.a) A � rm:Poll(id=2)� � B

(3.b) A � rm:Ack(id=2) �� B

 

Note that (3.a and 3.b) are over same HTTP req-response.

Sub-issue: security restrictions at (A) (firewall) may prevent (B) to initiate a request toward (A). A possible� option (not covering all cases of Ack loss) is RMP(A) resending Ack if the previous Ack callback failed to receive an http response.