Re: Syntax options for Async

(Tony modestly downplays his role in producing "Tony's timeline
<http://www.flickr.com/photos/psd/9877189/in/photostream/>" at the async
meeting in Palo Alto)

I'm becoming more convinced that talking about a "backchannel" muddies
the waters.  We've been using the term for a while, but with only an
intuitive notion of what it means.  I would prefer to talk about
"sending to the anonymous address" at the application level and
"request-response" at the SOAP or wire level, as I think these are both
better defined.  The link is that sending to an anonymous address at the
application level means using request-response at the SOAP or wire level.

In terms of the proposal I previously sent out
<http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0051.html>,
the anonymous endpoint (if available) MAY (or possibly MUST) be /used/
for faults in any MEP until the wsa:FaultTo header is understood.  The
rest should work OK, with appropriate changes to the non-normative
notes.  In particular, even an in-only may manifest as a
request-response in the context of SOAP/HTTP (e.g., if an in-only
message contains an unrecognized MustUnderstand header, the receiver MAY
(or possibly MUST) send back a fault as a response).

Or at least, that's how I read the timeline.  If we want some other
reasonable semantics, we should be able to define it just as briefly and
clearly in the framework I gave.

Rogers, Tony wrote:

> The fact that a fault may be sent on the backchannel in a number of
> cases (you identified one not previously discussed - the idea of an
> intermediate non-WSA node) was one of the more hotly discussed topics
> on the async task force. It was not agreed that a fault on the
> backchannel could be ignored, however. Indeed, it was agreed that the
> sender should be prepared to accept a fault on the backchannel for
> some period. Ideally this period would be until the 202 was received
> (sending a fault on the backchannel after that is, um, problematic!).
> Should the implementation close the connection early, however, the
> fault would get dropped on the floor (I don't like this - I think
> closing the connection before receiving the response is just asking
> for trouble, but there are timeout questions here).
>  
> I don't believe there was overall agreement on how to describe this.
> Some believe this belongs to the protocol binding, because it's
> talking of HTTP 202s. Others believe it can be discussed at a more
> abstract level, in terms of whether the underlying protocol supports a
> backchannel (without a backchannel the discussion becomes moot). I'd
> like to think that it can be described in general terms at a more
> abstract level, with the specifics (eg: returning a 202) left to the
> binding.
>  
> -----Original Message-----
> *From:* public-ws-addressing-request@w3.org on behalf of Neil Hudson
> *Sent:* Thu 17-Nov-05 15:30
> *To:* public-ws-addressing@w3.org
> *Cc:*
> *Subject:* Re: Syntax options for Async
>
>
>     I would like to raise an observation on the proposal : Async
>     Extension for
>     SOAP1.1/HTTP
>     http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/att-0116/Pr
>     oposalTake3.htm
>
>     The observation relates to how the rules for routing messages when a
>     separate HTTP return connection is being specified for example with:
>         <wsaw:Async wsdl:required="true"/>full<wsaw:Async>
>     or possibly:
>         <wsaw:Async wsdl:required="true"/>always<wsaw:Async>
>     apply to Fault messages.
>
>     In the first case "full" section 3.1.1 states that the consumer
>     can cause a
>     separate connection to be used by specifying an explicit reply EPR
>     rather
>     than using the anonymous URI.  When this is done the specification
>     states
>     that the initial consumer connection receives a Null 202 response
>     without a
>     SOAP body and that replies are sent to the EPR on another connection
>     initiated by the provider.
>
>
>
>     [1] Question on the Null 202 Response?
>
>     Does the reply have to have an empty HTTP body or is it just that
>     there is
>     no Soap Body inside the reply?  What meaningful information could be
>     contained in a non empty HTTP body?  The BP 1.1 states that for
>     one-way
>     operation there is no Soap Envelope in the response, should these two
>     patterns be consistent?
>
>
>
>     [2] Exceptional Cases - Sending Faults to the 'Wrong' Place
>
>     The text as currently written could be interpreted as stating that
>     if "full"
>     operation is an option and the consumer specifies an EPR for
>     Faults then the
>     initial connection, if successful, would never get a Fault Message
>     back but
>     would always get the Null 202 response.  I believe there could be
>     exceptional cases where the node that receives the initial request
>     could not
>     guarantee that a Fault reply will not be sent back on the initial
>     connection.  Some possible cases where this could occur are:
>     (a) The SOAP envelope has become so corrupted that it can not be
>     parsed and
>     a Fault is generated in response.  The parser has two
>     alternatives, don't
>     send any Fault information or send  a Fault back on the open
>     connection.
>     The later is the general case.
>     (b) The Reply EPR and Fault EPR attributes have been lost from the
>     message.
>     A Fault is generated.  It could be argued that the sensible thing
>     is to send
>     it back over the initial connection.
>     (c) The initial connection is to an intermediate node that is not
>     WS-A aware
>     and a Fault is generated / returned from this node.
>     (d) The message does not map to a recognised operation and the
>     lower level
>     dispatcher implementation is not WS-A aware.
>
>     The examples above illustrate three basic types of issue:
>     (a) Corruption of messages that prevent the use of the Fault EPR
>     even if the
>     layer of the service stack is fully capable of dealing with a
>     Fault EPR were
>     the information present.
>     (b) Lower level protocols within the stack, that are not
>     necessarily WS-A
>     aware, and that generate Faults and return them immediately whilst
>     aborting
>     the higher level processing.
>     (c) Connection through intermediate nodes which may not be WS-A
>     aware and
>     may view WS-A data as payload.
>
>     Note that on point (b) it could be argued that a compliant
>     implementation
>     needs to address the WS-A Fault EPR at all levels.  So for example
>     if the
>     SOAP protocol layer detects a Fault it should check for the Fault
>     EPR in the
>     message it has received and if so send the Fault to this EPR. 
>     However this
>     would increase coupling between layers and goes against the
>     implementation
>     of stacks in layers.  Implementation could be easier / cleaner if a
>     'generic' SOAP implementation is used and WS-A protocols are
>     implemented as
>     a higher layer in the stack.  The present wording would mean a
>     well behaved
>     implementation would have to implement Fault EPR routing in the
>     SOAP layer
>     and even this would not guarantee that the Fault EPR would always
>     be used
>     and that no Fault message would ever come back on the initial
>     channel (due
>     to
>     message corruption).
>
>     In theory a compliant consumer could ( should? ) simply ignore
>     Faults it
>     received back instead of a Null 202 reply and carry on, however:
>     (a) Consumer implemented based on this assumption could be vulnerable.
>     Software that gets something it is not expecting has a long track
>     record of
>     malfunctioning badly.  It would be better to spell out what could
>     happen so
>     that consumer developers know it is coming - eventually.
>     (b) Lower level, 'middleware' faults could be lost because they
>     are not sent
>     to the Fault EPR.  If the service is a Robust-In-Only, "You will
>     be told if
>     something has gone wrong.", this increases the risk of the request
>     failing
>     without the consumer being informed.
>     (c) Application monitoring systems / event logs may miss faults
>     resulting in
>     a lower quality of service.
>
>     Maybe one approach worth considering  is that the provider will be
>     making
>     best efforts to send Faults to the EPR specified by the consumer
>     but that
>     this will not always be the case and the consumer needs to be
>     aware of this.
>     Putting this into concrete requirements is messy but one stab is
>     illustrated
>     below:
>
>     [1] The consumer MUST be able to receive a Fault reply on the initial
>     connection in the response to the initial HTTP request without
>     malfunction.
>     [2] The consumer MUST be able to receive Fault replies at the
>     Fault EPR
>     without malfunction.
>     [3] The consumer MUST be able to receive Fault replies at the
>     Reply EPR
>     without malfunction.
>     [4] The provider MAY send Generic SOAP and WS-A faults on either
>     the initial
>     connection or to the Fault EPR( or to the Reply EPR if no Fault EPR is
>     present.).
>     [5] The provider SHOULD send WS-A faults to the Fault EPR where
>     this can be
>     identified as the consumers selection( or to the Reply EPR if no
>     Fault EPR
>     is present.).
>     [6] The provider MUST send Faults for protocols that sit above the
>     WS-A
>     level to the Fault EPR( or to the Reply EPR if no Fault EPR is
>     present.)
>     [7] The provider MUST send explicitly declared Operation Faults to
>     the Fault
>     EPR( or to the Reply EPR if no Fault EPR is present.)
>
>     I am less clear about suggesting the following:
>
>     [8]  The consumer MUST respond identically to Generic SOAP and
>     WS-A faults
>     received in either the response to the initial HTTP request or on the
>     specified Fault EPR ( which could be the Reply EPR if no Fault EPR was
>     specified in the request).
>     [9] When the consumer specified a separate Fault EPR it SHOULD
>     respond to
>     Faults received on the Reply EPR in a way identical to Faults
>     Received on
>     the Fault EPR. - deals with lost Fault EPR
>
>     I don't think these state the obvious - for example that a Fault
>     EPR needs
>     to deal with Faults that are sent to it.
>
>     Explicitly stating that the consumer needs to expect the
>     unexpected, particularly for lower level Faults will make for more
>     robust
>     less tightly coupled systems.
>
>     Best regards
>
>     Neil
>
>     --
>     ------------------------------------------------------------
>     Neil Hudson CEng MBCS MIEEE
>     ------------------------------------------------------------
>     SQC Technology Limited
>     Phone : +44(0)1283 763632
>     Fax   : +44(0)1283 763631
>     Email : nahudson@sqc.co.uk
>     Web   : http://www.sqc.co.uk
>     ------------------------------------------------------------
>
>
>
>