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

Christopher B Ferris wrote:

>
> 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.

That's my thought as well.  I believe the original hope was that WS-A
could provide a definition of anonymous that would "just work" in
WS-RX.  At this point we don't, and it's not clear it's even possible. 
Personally, I'm convinced it isn't.

What WS-A can do is to define what it does define in such a way as to
make it as easy as possible for WS-RX and any other interested party to use.

Beyond that, we seem to have flushed out a useful distinction between
anonymous and other [destination] values:  With most destination values
you can send any time you like and one message is just as good as any
other.  Neither of these is necessarily true with anonymous.  This is
not specific to WS-RX, but it seems to matter particularly to WS-RX.

>
> 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?