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.