RE: Syntax options for Async

There is no question that MU faults do *not* follow WS-Addressing rules
- by virtue of the SOAP processing model, no headers can have been
processed until all MU's are resolved.

--Glen 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Anish Karmarkar
> Sent: Monday, November 21, 2005 3:55 PM
> To: Neil Hudson
> Cc: public-ws-addressing@w3.org
> Subject: 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/2005O
> ct/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 21:12:12 UTC