RE: Syntax options for Async

Note that in the case where the receiving endpoint doesn't understand the
WS-Addressing headers, then the SOAP processing model follows the 
SOAP binding in use to determine where the fault is to be transmited
(if anywhere). Note that there is no requirement that the fault be 
transmitted.
SOAP faults are "generated". The binding determined whether or not, and to 
where
the fault is transmitted unless overridden by some SOAP header, such as
the wsa:FaultsTo (which would apply only if the endpoint understood the
WS-Addressing header(s).

Thus, in the context of the SOAP/HTTP binding, the fault MUST be 
transmitted
on the HTTP Response message, regardless of what the wsa:FaultTo might
have implied.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295



"Glen Daniels" <gdaniels@sonicsoftware.com> 
Sent by: public-ws-addressing-request@w3.org
11/21/2005 04:11 PM

To
"Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "WS-Addressing" 
<public-ws-addressing@w3.org>
cc

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