Re: Syntax options for Async

This is similar to the issue that Hugo had raised about MU faults in 
SOAP and the use of FaultTo SOAP header block -- if FaultTo header block 
is tagged with soap:MustUnderstand='1' and the SOAP processor does not 
understand WSA, where is the MU fault sent (can't locate the issue right 
now in the issues list)? I *think* we resolved this to say that FaultTo 
does not apply to MU faults.

-Anish
--

Neil Hudson wrote:
> 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
> ------------------------------------------------------------
> 
> 
> 
>

Received on Monday, 21 November 2005 20:54:32 UTC