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