W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2006

RE: Updated proposal for WS-Policy assertions

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Wed, 15 Nov 2006 12:50:43 +1100
Message-ID: <BEE2BD647C052D4FA59B42F5E2D946B33757B8@AUSYMS12.ca.com>
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Marc Hadley" <Marc.Hadley@Sun.COM>, <public-ws-addressing@w3.org>


UsingAddressing will be used as a WSDL marker, but not as an assertion.
That is because the semantics in WSDL are different from the semantics
in policy (this was discussed at length on the most recent WS-Addressing
call). Thus the assertion is AddressingRequired, with optionality
conveyed by WS-Policy constructs - it is straightforward to interconvert
between the WSDL marker and the Policy form, but neither is really
suited for use in place of the other. Giving them different names helps
make it clear that they are different (albeit related).

wsaw:Anonymous will be removed as an assertion, replaced by two new
assertions (two options here). One of the reasons for the removal is the
desire to avoid parameterised assertions, per WS-Policy.

Tony Rogers
tony.rogers@ca.com

-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Yalcinalp,
Umit
Sent: Wednesday, 15 November 2006 12:18
To: Marc Hadley; public-ws-addressing@w3.org
Subject: RE: Updated proposal for WS-Policy assertions


What am I missing? Probably I am a bit out of sync, so apologies in
advance for this question. 

What is not clear to me regardless of the decision on opt-in/opt-out is
that the relationship with the wsaw:UsingAddressing. The other aspect is
more easily resolvable. 

I did not see the marker being removed to be proposed. I did not also
see whether the proposed new markers were children (nested assertions)
within the marker. 

This is a very important aspect of assertion design. 

Marc/Dave? Could you clarify where you were heading with respect to the
existing element in Section 3.1?

Is UsingAddressing become an assertion too? BTW, there is no  as stated
to the use of UsingAddressing as an assertion, except modifying the
@wsdl:required attribute . Thus it is very conceivable that the proposed
3 assertions will have to be clarified and used with the
wsaw:UsingAddressing anyway as Anonymous element was trying to attempt. 

--umit
 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Marc Hadley
> Sent: Tuesday, Nov 14, 2006 5:55 AM
> To: public-ws-addressing@w3.org List
> Subject: Re: Updated proposal for WS-Policy assertions
> 
> In the examples, s/Replies/Responses/.
> 
> Marc.
> 
> On Nov 13, 2006, at 6:40 PM, 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.
> >
> > (i) <wsaw:AddressingRequired/> - the endpoint requires WS- 
> > Addressing, optionality can be conveyed using WS-Policy constructs.
> >
> > (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.
> >
> > (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.
> >
> >
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
> 
> 
> 
Received on Wednesday, 15 November 2006 01:51:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:15 GMT