Re: Comment on WSDL spec: use of Anonymous Element

Alastair,
  There are a couple of different things at play here. First, sorry about 
the long cc-list but the wsrx mailing list still doesn't appear to work so 
I need to include the entire wsrx team manually :-(
In a non-anonymous world the wsa:Address field represents both the fact 
that the destination can access connections and it identifies the party. 
And I think that makes sense.  There is no reason to not have a single URI 
do that (let's not get into the 'identity' issue w.r.t. ref-p's  :-). So, 
if we then switch over to the anonymous case, IMO, I don't believe the 
implementation should need to change w.r.t. the purpose of this URI. In 
the simple WS-Addr anon use-case the URI still indicates both things - 
whether or not (and 'not' in this case) the destination will accept a 
connection, and it also indicates the identity - sort of.  The identity is 
implicitly defined by the fact that it is tied to the connection on which 
the request came in on.  If we did what you're suggesting and add a second 
header then, IMO, RM would require quite a big change to people's soap 
processor.  I think WS-Addr did a really good thing by keeping everything 
people need to know with a single structure - the EPR.  Even with the 
introduction of the anonymous URI (which could very easily have been 
introduced in a much less cleaner fashion), most of the SOAP processor 
doesn't really need to know what the specific value of the wsa:Address 
element is until it tries to actually send the message over the wire. 
  So, if we then switch over the MakeConnection use-case, I think RM did 
the right thing by using the same mechanism WS-Addr did - keep everything 
within a single EPR.  This allows for most of the SOAP processor to be 
totally unaware of the actually transport mechanism until (or close to) 
the time the message is serialized on the wire.  If there were additional 
headers to carry this information then existing WS-Addr logic of mapping a 
wsa:ReplyTo over to a wsa:To + ref-p headers when constructing a response 
might need to also change.  There's also lots of other use-cases where the 
logic to handle the RM code isn't on the same machine doing this WS-Addr 
mapping so if its not aware of RM at all it wouldn't even know to include 
some special bit on the outgoing message (either in the message or in the 
soap processor's metadata about the message) to indicate that 
MakeConnection will be used.  Things are just a whole lot easier if 
everything is encapsulated in a single EPR, and more specifically in the 
wsa:Address field.  Which is exactly how WS-Addr anon works today.
  I don't think loosening the wording makes thing indeterminate - it still 
requires a URI with the proper semantics, but it allows for the 
composition of other specifications that may defined their own.  And, IMO, 
as long as they are consistent with WS-Addr's definition of anon, from a 
WS-Addr perspective, then how they choose to add additional semantics is 
up to them. 
  In talking about this with Chris Ferris, he mentioned another 
alternative... instead of saying "MUST", perhaps the text related to the 
wsaw:Anon flag could simply say "SHOULD".  This clearly indicates that 
WS-Addr's anon URI is the URI of choice, but if there are good reasons for 
using some other one then the processor will allow those as well.

thanks,
-Doug




Alastair Green <alastair.green@choreology.com> 
Sent by: public-ws-addressing-request@w3.org
08/04/2006 06:59 AM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
public-ws-addressing@w3.org, ws-rx@lists.oasis-open.org
Subject
Re: Comment on WSDL spec: use of Anonymous Element







Doug,

This is probably a dumb question, but aren't you trying to change the 
wrong spec?

In RM you are using a single header property to indicate two things: 
"we're doing back-channel here, and it's part of a logical connection, 
identified thus".

Why can't you separate the communication of these two semantics, by 
using two properties:

1) wsa:ReplyTo = anonymous URI
2) wsrm:MakeConnection = connection identity?

2) without 1) would be illegal.

In your example posted on the WS-RX list, you state that [reply 
endpoint] is not set because MakeConnection is a "one-way message". But 
it's a message that usually/frequently expects a reply (at a WS-A 
level). Unlike many other applications, a WS-RM MC sender will tolerate 
an empty response (no SOAP in the HTTP body), but I don't think that 
stops one viewing this as a utilization of the request-reply pattern 
implied by use of reply-to.

If you loosen the WSAW wording, then surely it becomes indeterminate. 
What does "required" imply on the wire, thereafter?

Alastair

Doug Davis wrote:
>
> To elaborate a little on Bob's note [1], in the WSA WSDL spec, when 
> talking about the various values for the Anonymous Element it lists:
>
> "optional": This value indicates that a response endpoint EPR in a 
> request message MAY contain an anonymous URI as an address.
> "required":This value indicates that all response endpoint EPRs in a 
> request message MUST always use anonymous URI as an address.
> If a response endpoint EPR does not contain the anonymous URI as an 
> address value, then a predefined InvalidAddressingHeader fault defined 
> in Web Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP 
> Binding] MUST be generated.
> "prohibited":This value indicates that any response EPRs in a request 
> message MUST NOT use anonymous URI as an address.
> If a response endpoint EPR contains the anonymous URI as an address 
> value, then a predefined InvalidAddressingHeader fault defined in Web 
> Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP Binding] 
> MUST be generated.
>
>
> The problem comes up when another spec defines their own version of 
> anonymous - like WS-RM does.  It defines an anon URI which acts almost 
> exactly like the WSA one in that it means "send it on the transport 
> specific back-channel".  However, if the wsaw:Anonymous element is set 
> to "required" then the above text would seem to imply that regardless 
> of whether or not the RM spec is supported by the endpoint, the client 
> can never send a wsa:ReplyTo with anything other than WSA's anonymous. 
>  So the above text precludes another spec from ever extending WSA to 
> define their own anon URI where from a WSA perspective its equivalent. 
>  If the text were loosened up a bit to not mention the WSA anon URI 
> specifically, but rather something more generic like: "... MUST always 
> use a URI implying the transport specific back-channel" then the use 
> of the wsaw:Anonymous element would not preclude other specs defining 
> their own anon URI and not violate the meaning of the wsaw:Anonymous.
>
> thanks
> -Doug
>
>
>
> [1] 
> 
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/0009.html