- From: David Hull <dmh@tibco.com>
- Date: Tue, 21 Feb 2006 14:45:48 -0500
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Cc: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
- Message-id: <43FB6DEC.5050403@tibco.com>
Anish Karmarkar wrote: > 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. I'm not making any assumptions here, just asking for clarification. As far as I can tell the messages for the offered sequences are supposed to go to anonymous (because that's the [reply endpoint] of the creation request), and the acks are also supposed to go to anonymous (because that's the wsrm:AcksTo in the wsrm:Accept). I was wondering how that works. If I understand correctly what you say below, the messages for the accepted sequence would come to me in response to messages I sent to the destination of my sequence, and I would send acks in response to messages I happened to get from that party. For example * I send an outmsg to the other end (as a request). * The other end sends me back an ack for that outmsg, or an inmsg, or neither, or both (as a response) * Some time later (or maybe earlier) the other end sends me something (but not an inmsg and not an ack for an outmsg) as a request * I may send back acks for any inmsgs I've received as a response to that request. > > In the case of SOAP/HTTP the ack for the offered sequence has to flow > on the HTTP response (in your example). Just to drive the point home, that's not what WSA says. WSA defines three specific cases ([reply endpoint] in request, [fault endpoint] in request and [destination] in reply). It doesn't define behavior for anonymous outside the context of particular endpoints in particular kinds of messages. There is no anonymous address per se. Even before the resolution of CR 15, we only said that you /could/ use a SOAP response for anonymous messages, not that you had to. > 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). In the example I give, by those rules, doesn't the other end have to send its messages to me as responses to messages I send it (sequence destination == [reply endpoint] of request == anonymous)? If so, is there a way I could get the same effect with two separate create sequence exchanges? > > > HTH. > > -Anish > -- >
Received on Tuesday, 21 February 2006 19:45:56 UTC