Re: Clarification for WS-RX

David Hull wrote:
> I'm a bit loath to send this to the whole WS-RX list, and I think there
> are enough WS-RXperts here to answer, so ...
> 
> Suppose I use an ordinary request-response, with anonymous [reply
> endpoint], to create a sequence.  In that request, I wsrm:Offer to
> create a sequence the other way.  The receiver of the request responds
> with wsrm:Accept.  This has wsrm:AcksTo anonymous.
> 
> What happens?
> 

By 'what happens,' I'm going to assume that you want to know how the 
acks in the reverse direction (for the offered/accepted Sequence) are 
delivered given that AcksTo is anon?

The offer/accept is nothing but optimization. It changes nothing.
The acks in both the direction are delivered the same way (through 
whatever 'anon' points to as defined by the binding).

Are you making an assumption that only the sender of the CreateSequence 
message initiates RM messages (at least in the context of soap/http)? If 
so, that is not necessarily correct. A Sequence (in either direction) 
can span multiple "clients" or WSDL endpoints.

In the case of SOAP/HTTP the ack for the offered sequence has to flow on 
the HTTP response (in your example). What this means is that if the 
responder to the CreateSequence message (RMD) never initiates a HTTP 
request there is no 'anon' available for the acks going in the reverse 
direction. I.e., acks in the reverse direction cannot be sent -- the 
actors in the Sequence will timeout at some point and terminate the 
sequence. The same is true if the AcksTo was non-anon but not reachable 
or was just a bad EPR.

OTOH, if the responder to the CreateSequence message (RMD) does initiate 
HTTP requests there is an 'anon' available for the acks going in the 
reverse direction and everything is fine.

This is no different than what would have happened if the optimization 
of offer/accept was not used and separate CreateSequence message was 
sent by the RMD (in your example) to the RMS (in your example).


HTH.

-Anish
--

Received on Tuesday, 21 February 2006 19:19:53 UTC