RE: Updated Table: wsaw:Anonymous Combinations

Chris,

Did you intend to open a new public comment issue with your last point
(following "Finally"?

Thanks

-bob

 

________________________________

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 8: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). 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. 

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

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? 

If the wsaw:Anonymous=prohibited and the wsa:ReplyTo or wsa:FaultTo are 
anon, then shouldn't that generate a fault? If wsaw:Anonymous=required 
and wsa:ReplyTo or wsa:FaultTo are not anon, shouldn't that generate 
a fault? 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. 

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-125
2
> 
> -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