RE: Updated Table: wsaw:Anonymous Combinations

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Christopher B Ferris
> Sent: Thursday, August 10, 2006 5:51 AM
> To: Arun Gupta
> Cc: W3C WS-Addressing Public List
> Subject: Re: Updated Table: wsaw:Anonymous Combinations
> 
> 
> 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). 

We're not trying to capture this level in the table at present.  I'd
rather not try to re-specify mU faults in WS-A, as we might get it
subtly wrong.  The table presumes there were no mU or VM faults.

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

Post-mU behavior, the fault is sent when service wants to, and is
actually able to, send it.  We can't do better than that without
classifying types of applications, which still doesn't really nail
things down, just gives us more terminology.

> Secondly, the determinant as to the disposition of the handling of a
> message is going to be
> largely dependent upon what the value of the @soap:mU is on any wsa
header
> block.
> 
> If there is no @soap:mU=true specified on any of the wsa: header
blocks,
> then the receiving
> endpoint is ***free to ignore*** those header blocks and process the
> message as if the
> wsa: header blocks weren't present in the message... meaning that the
> behavior would
> be as specified in the SOAP specification. I don't think that it is
safe
> to assume that
> because some WSDL is decorated with wsaw: extensions that there can be
any
> certainty as to what the behavior of the endpoint will be. 

It is not our problem if the WSDL asserts a behavior not actually
exhibited by the service.  That's simply a bug.

> Someone could
> have
> made the mistaken assumption that the implementation of their tooling
or
> runtime
> understood that WSDL extension (or policy) when, in fact, it did not,
and
> hence the
> runtime would ignore what the wsaw: extension says and process the
message
> ignoring any wsa: header blocks. Thus, to be sure that the correct
> semantics are
> followed, there SHOULD be a @soap:mU=true on one of the wsa: header
blocks
> in the message so that the sending endpoint can be certain that the
> receiving
> endpoint is actually processing the wsa: header blocks.

You are free put mU on WS-A if you are worried about inaccurate WSDLs.
I don't think we need to tell people how to deal with non-conformance to
the spec, of which there is infinite variety.  Telling them how to
conform is sufficient.

> Finally, why is it that there is no fault defined for the circumstance
in
> which the
> received message violates the constraint expressed in the WSDL wsaw:
> extensions?

Umm, thought that was what the table was doing.  If you mean, specific
fault codes, there are a couple already defined at
http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/#id2270777 that seem
adequate to me.

> If the wsaw:Anonymous=prohibited and the wsa:ReplyTo or wsa:FaultTo
are
> anon, then shouldn't that generate a fault? 

Yes, that's what 1E, 2E, 3E, 4E, 6E, and 10E state.

> If wsaw:Anonymous=required
> and wsa:ReplyTo or wsa:FaultTo are not anon, shouldn't that generate
> a fault? 

See 3D, 5D, 6D, 7D, 8D, 11D.

> Clearly, the sending endpoint is going to be disappointed in the
> handling of the message if it says to send the response or fault to
anon
> and the
> receiving endpoint either discards the result or sends it somewhere
else.

Faults are always a disappointment.  If I ask a service which asserts it
cannot respond to an anonymous address to send a fault to that address,
I should be prepared for some disappointment.

> Cheers,
> 
> 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
> 
> public-ws-addressing-request@w3.org wrote on 08/09/2006 01:32:57 PM:
> 
> > Attached is the updated set of rules and table based upon Anish's
> > recommendation. I've preserved the grey color of cells in the
original
> > table [1] but updated the resolution.
> >
> > [1]
> > http://lists.w3.org/Archives/Public/public-ws-
> >
addressing/2006Aug/att-0001/anonymous-semantics.htm__charset_WINDOWS-
> 1252
> >
> > -Arun
> > --
> > got Web Services ?
> > Download and Contribute Web Services Interoperability Technology
(WSIT)
> > http://java.sun.com/webservices/interop
> > wsaw:Anonymous and ReplyTo/FaultTo Combinations
> > Purpose:
> > This document defines the behavior of an endpoint based upon the
> > combinations of ReplyTo/FaultTo EPRs in the message received and the
> > value of wsaw:Anonymous.
> > Rules:
> > 1. Columns A and B define a combination of ReplyTo and FaultTo
> > received at a receiver.
> > 2. Each cell in columns D, E and F define outbound message flow from
> > receiver after the inbound message is processed.
> > 3. "None" URI is a special address whose semantics are defined in
> > WS-Addressing Core.
> > 4. If the receiver is going to generate a fault and FaultTo value is
> > incorrect, then it may send the fault over the back-channel with the
> > understanding that the sender may not receive or process this fault.
> >
> >
> > A
> >
> > B
> >
> > C
> >
> > D
> >
> > E
> >
> >
> >
> > ReplyTo
> >
> > FaultTo
> >
> > Anonymous=Optional
> >
> > Anonymous=Required
> >
> > Anonymous=Prohibited
> >
> > 1
> >
> > Anon
> >
> > Not Specified
> >
> > Normal or Fault response on transport back channel.
> >
> > Normal or Fault response on transport back channel.
> >
> > Generates a fault and may send the fault on transport back channel.
> >
> > 2
> >
> > Anon
> >
> > Anon
> >
> > Normal or Fault response on transport back channel.
> >
> > Normal or Fault response on transport back channel.
> >
> > Generates a fault and may send the fault on transport back channel.
> >
> > 3
> >
> > Anon
> >
> > Non-Anon
> >
> > Normal response on transport back channel, Fault response to FaultTo
> address.
> >
> > Generates a fault and may send the fault on transport back channel.
> >
> > Generates a fault and send Fault response to FaultTo address.
> >
> > 4
> >
> > Anon
> >
> > None
> >
> > Normal response on transport back channel, Fault response is
discarded.
> >
> > Normal response on transport back channel, Fault response is
discarded.
> >
> > Generates a fault and discards it.
> >
> > 5
> >
> > Non-Anon
> >
> > Not specified
> >
> > Normal and Fault response to ReplyTo address.
> >
> > Generates a fault and may send the fault on transport back channel.
> >
> > Normal and Fault response to ReplyTo address
> >
> > 6
> >
> > Non-Anon
> >
> > Anon
> >
> > Normal response to ReplyTo address, Fault response on transport back
> channel.
> >
> > Generates a fault and send Fault response on transport back channel.
> >
> > Generates a fault and may send the fault on transport back channel.
> >
> > 7
> >
> > Non-Anon
> >
> > Non-Anon
> >
> > Normal response to ReplyTo address, Fault response to FaultTo
address.
> >
> > Generates a fault and may send the fault on transport back channel.
> >
> > Normal response to ReplyTo address, Fault response to FaultTo
address.
> >
> > 8
> >
> > Non-Anon
> >
> > None
> >
> > Normal response on transport back channel, Fault response is
discarded.
> >
> > Generates a fault and discards it.
> >
> > Normal response to ReplyTo address, Fault response is discarded.
> >
> > 9
> >
> > None
> >
> > Not specified
> >
> > Normal and Fault response are discarded.
> >
> > Normal and Fault response are discarded.
> >
> > Normal and Fault response are discarded.
> >
> > 10
> >
> > None
> >
> > Anon
> >
> > Normal response is discarded, Fault response sent on transport back
> channel.
> >
> > Normal response is discarded, Fault response sent on transport back
> channel.
> >
> > Generates a fault and may send the fault on transport back channel.
> >
> > 11
> >
> > None
> >
> > Non-Anon
> >
> > Normal response is discarded, Fault response sent to FaultTo
address.
> >
> > Generates a fault and may send the fault on transport back channel.
> >
> > Normal response is discarded, Fault response sent to FaultTo
address.
> >
> > 12
> >
> > None
> >
> > None
> >
> > Normal and Fault response are discarded.
> >
> > Normal and Fault response are discarded.
> >
> > Normal and Fault response are discarded.
> >
> >
> > Last Updated: August 09, 2006 10:18 AM

Received on Monday, 14 August 2006 17:07:38 UTC