[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Respons Reliability Scenarious using WS-Reliability 1.1
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 5133Title: 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:
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:
(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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]