Re: Why anonymous may be different (for AcksTo and elsewhere)

Given as the WS-RX specification isn't yet complete, I see no reason why 
we might not
make a clarification to tighten things up and make the behavior 
unambiguous.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 02/21/2006 09:44:57 AM:

> As I understand it, specifications distinguish between conforming 
> and non-conforming implementations, not between naive and non-naive 
> implementations.
> 
> The pattern I gave, of C sending acks back on B's "back-channel", 
> would conform if WS-RX takes the view that anonymous AcksTo is 
> nothing special and WS-A changes its semantics to define anonymous 
> as always meaning the "back-channel".  If you don't like that, you 
> don't specify "don't be naive", you tighten the semantics, right?
> 
> As WS-A now stands, such a use of anonymous would be undefined, 
> forcing WS-RX to clarify what it actually means.  WS-RX seems like 
> the better place to handle this.  WS-A specifically takes on 
> request-response but otherwise just provides building blocks. 
> Whatever else we say about this, it seems pretty clear that AcksTo 
> and ReplyTo are two different beasts.  We would like to be able to 
> use the underlying response message for both, but that doesn't give 
> them the same semantics.
> 
> As an aside, the pattern I mentioned might actually be the Right 
> Thing, if A and B are coming from the same physical place and that 
> place's infrastructure knows about all active sequences.  In that 
> case, you get twice as many chances to get acks back.  Why wait 
> until I send an A message to get an A ack?  That's why I talked 
> about "anonymous means back-channel" effectively tying together 
> everyone who used anonymous when sending to a given endpoint.  This 
> tying together may or may not be good, depending on context, but I'm
> pretty sure it's a consequence of that rule.
> 
> Christopher B Ferris wrote: 
> 
> David, 
> 
> Please see my inlined comments below, 
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295 
> 
> public-ws-addressing-request@w3.org wrote on 02/21/2006 02:15:17 AM:
> 
> > The more I ponder the problem of anonymous AcksTo, the more I think 
> > that anonymous can't quite be treated as just another EPR address. 
> > I'm posting this here because I think the situation is not unique to
> > AcksTo or WS-RX.  Rather, WS-RX happens to have presented the use 
> > case that flushes the issue out.  Also, while I may have got the WS-
> > RX use case wrong here, I believe the overall point is still of 
> > interest to WSA.  Finally, there are clearly enough WS-RX folks in 
> > the audience here that if this is in fact relevant to WS-RX, I'm 
> > sure the news will find its way there.
> > 
> > Here's the scenario:
> > 
> > Suppose that A and B both want to use a reliable sequence to send 
> > messages to C.  Each uses its own sequence.  As I understand it, 
> > this is the normal case (as opposed to, say, A and B sharing the 
> > same sequence).  Now further suppose that A and B both use anonymous
> > for AcksTo.  Given that acks for a given message could come back 
> > with a later message, the following could happen: 
> > A sends C message A1 
> > C sends back a response with no acks 
> > B sends C message B1 
> > C sends back a response with an ack to message A1 
> > For that matter, if C isn't careful, it could send acks to some 
> > completely unrelated process that happened to be sending to it 
> > without even using WS-RX. 
> 
> Exsqueeze me? Why would it do that? Only the most naive implementation 
> would be written to arbitrarily send an ack on the HTTP response flow 
> (in the case of an HTTP binding) blindly, without consideration as to 
> the context. 
> 
> The RM Sequence provides the context... if a "request" message (oh how 
> I HATE that term) or more properly a SOAP envelope carried on the HTTP 
request
> has a wsrm:Sequence header with wsrm:Identifier X, then the RMD 
> instructed to use the anon EPR for its wsrm:AcksTo can use the HTTP 
> response to any message, carrying that Sequence context, to send 
> a wsrm:SequenceAcknowledgement... either piggy-backed on an 
application-level
> response, or in an infrastructure-manufactured SOAP envelope. 
> 
> Why is this so complicated? 
> 
> > 
> > So, in order for this to work, C has to be careful only to use 
> > anonymous AcksTo for replies to request messages that are part of 
> > the same sequence (by the way, how does C ack the last message of 
> > such a sequence if it doesn't know it's the last?). 
> 
> Well, of course. See above. The wsrm:Sequence/wsrm:Identifier provides 
> the needed context. 
> 
> > 
> > By contrast, it doesn't seem C would have to be so careful in the 
> > case where the AcksTo EPRs are not anonymous.  Normally (and again 
> > I'm not a WS-RXpert) I would expect that A and B would use separate 
> > AcksTo addresses, and C would just send acks to the addresses it was 
> 
> I would agree that in the case of the non-anonymous EPR, that the RMD 
> *can* send acks for ANY Sequence that has a matching wsrm:AcksTo EPR 
(despite
> the fact that there are no EPR comparison rules defined), however, in 
> practice, I see this as a rather esoteric use case. I envisage that 
> implementations will likely stick to the practice of dealing with 
> a single Sequence at a time, based upon the context of the 
> wsrm:Sequence/wsrm:Identifier contained in the message just received. 
> 
> > told to use.  Even if A and B used the same AcksTo address and used 
> > the sequence number on the acks to sort out whose acks they were, 
> > they could do so without any help from C because the acks would at 
> > least always end up at the same destination.
> > 
> > Another way to look at this is that using the same AcksTo for two 
> > different sequences ties the two sequences together and whoever's 
> > getting the acks has to know about both sequences.  This would apply
> > equally to anonymous and non-anonymous.  I believe this handles most
> > of the problem, but not all.  First, this would require every sender
> > that wants to use anonymous AcksTo with a given destination to know 
> > about every other one.  Second, by itself it doesn't deal with 
> > senders that aren't even using WS-RX.  I'm not sure the second 
> > problem is serious, but the first one seems like it might be.
> > 
> > It also seems worth considering the case where A uses anonymous and 
> > B doesn't.  If B is expecting acks at non-anonymous D, then it 
> > wouldn't normally be checking for acks in its responses, and neither
> > could it be expected to know what to do with A's acks if it did 
> > notice them.  C can send B's acks freely to D, but it has to be 
> > careful to send A's acks back only on responses to messages from A. 
> 
> See above. Only a naive implementation would do something this 
> inane. 
> 
> > 
> > Even if there turn out to be no serious issues here for WS-RX, it 
> > seems worth noting that trying to extend anonymous beyond the 
> > context of a single request-response message exchange effectively 
> > ties together all senders to a given destination into one virtual 
> > receiver for messages to anonymous.  That is, a message sent to 
> > anonymous in such a scenario could arrive back at any sender. 
> 
> Sorry, I am not buying. There are no issues and I do not see any reason 
> to constrain the semantic of the anon URI to apply generally to an MEP 
> absent a context of a given MAP. It is the MAP that should define the 
> semantic of the context that applies. For wsa:ReplyTo and wsa:FaultsTo, 
> the WS-A is free to constrain the semantic to apply to the MEP. 
> For wsrm:AcksTo, I see no reason why the WS-RX TC can't assign the 
> semantic that constrains the set of SequenceAcknowledgements to those 
> with a Sequence identifier that match that of the received message. 
> 
> IMO, you are making this more complicated than it needs to be. 
> 
> We have demonstrated interop that was perfectly happy with the 
> status quo of the semantic of the anon URI as applies to the 
> wsrm:AcksTo. Why impose an unnecessary change?