Re: Updated proposal for WS-Policy assertions

Hi Marc,

Few comments inlined below.

-Anish
--

Marc Hadley wrote:
> The first part of the proposal is to remove the current wsaw:Anonymous 
> WSDL marker. I think we might need to tweak the section describing the 
> UsingAddressing marker to include the following text (modified to remove 
> mentions of policy and anonymous) from the section describing the 
> wsaw:Anonymous marker:
> 
> "A WSDL-based service description that includes the wsaw:UsingAddressing 
> makes no assertion regarding a requirement or a constraint in the use of 
> the anonymous URI in EPRs contained in messages sent to the endpoint."
> 
> The current text for UsingAddressing could be taken to imply that 
> endpoints using it explicitly support anon and non-anon addresses but I 
> think the intent is that UsingAddressing makes no claim about the types 
> of address supported.
> 
> The second part of the proposal is to define three new elements for use 
> in WS-Policy.

Suggestion, who not define Qnames that can be used in WSDL or as policy 
assertion?
> 
> (i) <wsaw:AddressingRequired/> - the endpoint requires WS-Addressing, 
> optionality can be conveyed using WS-Policy constructs.
> 

Doesn't this duplicate the functionality of UsingAddressing?

It is also kinda strange to say:
<wsaw:AddressingRequired wsp:Optional='true'/>


> (ii) <wsaw:AnonymousResponses/> (a child element of 
> <wsaw:AddressingRequired>) - the endpoint can send replies using WS-A 
> anonymous; the endpoint can't send to anon if not present.
> 

The idea of policy friendly wsdl extensions was to create independent 
Qnames that are not parametrized through the use of attribute values or 
children element. Not a policy expert, but doesn't this make it less 
policy friendly?

> (iii) <wsaw:NonAnonymousResponses/> (a child element of 
> <wsaw:AddressingRequired>) - the endpoint can send replies using other 
> addresses; the endpoint can't send to other addresses if not present 
> (unless some other assertion adds a class of supported addresses).
> 
> Element (iii) is deliberately vague, its presence means that a non-anon 
> address might work but doesn't constrain what such an address might look 
> like - a receiver can still reject an address that it doesn't grok or 
> that requires a binding it doesn't support. The WG decided against 
> specifying things like available response bindings so I think this is in 
> line with that decision.
> 
> Here are some examples:
> 
> <wsp:Policy>
>   <wsaw:AddressingRequired>
>     <wsaw:AnonymousReplies/>
>   </wsaw:AddressingRequired>
> </wsp:Policy>
> 
> Means that addressing is required and only anonymous replies are
> supported.
> 
> <wsp:Policy>
>   <wsaw:AddressingRequired>
>     <wsaw:NonAnonymousReplies/>
>   </wsaw:AddressingRequired>
> </wsp:Policy>
> 
> Means that addressing is required and only non-anonymous replies are
> supported.
> 
> <wsp:Policy>
>   <wsaw:AddressingRequired>
>     <wsaw:AnonymousReplies/>
>     <wsaw:NonAnonymousReplies/>
>   </wsaw:AddressingRequired>
> </wsp:Policy>
> 
> Means that addressing is required and both anonymous and non-anonymous
> replies are supported.
> 
> <wsp:Policy>
>   <wsaw:AddressingRequired/>
> </wsp:Policy>
> 
> Wouldn't be too useful for anything other than a one-way message since 
> neither anonymous nor non-anonymouse replies are supported.
> 
> <wsp:Policy>
>   <wsaw:AddressingRequired>
>     <wsaw:AnonymousReplies/>
>     <wsfoo:AnonReplies/>
>   </wsaw:AddressingRequired>
> </wsp:Policy>
> 
> Means that addressing is required and that anon replies as defined by 
> WS-Addr or WS-Foo are supported.
> 
> Marc.
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
> 
>

Received on Monday, 27 November 2006 20:57:37 UTC