Re: Updated Table: wsaw:Anonymous Combinations

Christopher B Ferris wrote:
>
> Who is Tony and why does he have a timeline? I'm missing the connection.
Tony is the estimable Tony Rogers.  The timeline in question came out of
the Async Task Force, and is captured in this image
<http://www.flickr.com/photos/psd/9877189/in/set-72057594085366895/>
snapped by the equally estimable Paul Downey.

The particular diagram illustrates the processing of an HTTP request
message with ReplyTo and FaultTo not anonymous (and FaultTo not none ...
sigh).  At some point, the receiver will determine that the FaultTo is
valid, or will have died trying.  Call this point A.  At some later
point, assuming the FaultTo was valid, the receiver will send back an
ack, telling the sender it has received the message.  Call this point B.

Before point A, the receiver has no choice but to send back any faults
on the HTTP backchannel.  After point B, the receiver has no choice but
to send any faults along to the FaultTo.  In between, it may do either
(and it doesn't much matter which).

Since then, "Tony's Timeline" has become a bit of a shorthand (at least
for me :-) for cases like this.  In light of recent discussions, and my
never-ending efforts to generalize beyond the HTTP-only view, I'd tweak
this a bit:

    * At some point A, the receiver will have done the basic SOAP
      processing (well-formedness, mU, whatever else).  Up to this
      point, it knows nothing about WSA and will have to report faults
      using whatever means the binding provides.
    * At some point A', the receiver will have determined whether the
      FaultTo address is valid.
    * At some point A'', the receiver will have determined whether the
      other WSA headers are valid.
    * At some point B, the receiver will have completed the request
      operation (e.g., by sending back an HTTP 202 response).

Since there is no way to do anything out of the ordinary before point
A', there's no need to distinguish A and A' here.  There may or may not
be any need to distinguish A' and A''.  I don't think there's any need
to distinguish the A's from B, as there's usually no external way to
tell which happened first, the completion of the binding-level MEP or
the sending of a fault to the FaultTo.


>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> David Hull <dmh@tibco.com> wrote on 08/14/2006 04:13:15 PM:
>
> > Christopher B Ferris wrote:
> >
> > There is an important, yet subtle distinction not captured in the
> > table (either version).
> >
> > The SOAP MU fault will ALWAYS travel on the HTTP response REGARDLESS
> > of what the wsa:faultTo, wsa:ReplyTo, etc. say. Thus, I think that
> > you have to make
> > it clear that this applies only to faults that are NOT SOAP-specific
> > faults (MU and
> > VM). Saying that the fault MAY be sent on the transport-specific
> > backchannel is
> > not enough. I think it needs to be made clear when this will be the
> > case and when it
> > will not.
> > This is a "Tony's Timeline" issue.  In case of an MU fault, WSA is
> > not engaged and none of the table applies.
> >
> > It occurs to me that this distinction might be part of folklore but
> > not really written down anywhere official.