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

RE: RE: Updated proposal for WS-Policy assertions

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 14 Nov 2006 19:16:54 -0800
Message-ID: <2BA6015847F82645A9BB31C7F9D6416502AC4274@uspale20.pal.sap.corp>
To: "Marc Goodner" <mgoodner@microsoft.com>, "Rogers, Tony" <Tony.Rogers@ca.com>, "Marc Hadley" <Marc.Hadley@Sun.COM>, <public-ws-addressing@w3.org>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>

 

> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> Sent: Tuesday, Nov 14, 2006 7:07 PM
> To: Rogers, Tony; Yalcinalp, Umit; Marc Hadley; 
> public-ws-addressing@w3.org; Anish Karmarkar
> Subject: RE: RE: Updated proposal for WS-Policy assertions
> 
> Please note that the current WSDL binding spec defines 
> UsingAddressing such that it can be used as a policy 
> assertion. There seems to be consensus that there are no 
> problems with UsingAddressing as a policy assertion and there 
> are implementations today that do.

That was my point as well, Marc. 

I prefer perhaps that we should actually shift them all to WS-Policy
space instead of using wsdl:required so that 

(a) composition
(b) intersection
(c) policy authoring independent of WSDL

Works as expected rather than explaining how half of the design in in
WSDL land, and the rest is intended to be part of Policy Expression. 
 
> 
> I think Tony is correct in that it was the additional 
> capabilities the Anonymous marker was trying to express that 
> were problematic in a direct mapping from WSDL marker to 
> policy assertion. The WG, IMO, seems to feel for the most 
> part that these capabilities are more desirable in terms of 
> policy assertions than as WSDL markers so the proposals have 
> shifted in that direction.

I do not have any issues with that direction. 

> 
> I thought we were waiting on feedback from Anish, and any 
> others, who have been proponents of the Anonymous WSDL marker 
> to see if they feel these capabilities are more important to 
> them in terms of policy assertions or WSDL markers. On the 
> last call no one spoke up saying they were implementing the 
> Anonymous marker for use as a WSDL marker alone. I'd 
> certainly like to hear from the historical proponents of this 
> marker regarding how they may or may not be currently using it.
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Rogers, Tony
> Sent: Tuesday, November 14, 2006 6:25 PM
> To: Yalcinalp, Umit; Marc Hadley; public-ws-addressing@w3.org
> Subject: RE: Updated proposal for WS-Policy assertions
> 
> 
> 
> My take (and I am NOT stating the official position of the 
> WS-A WG here)
> is that we want to retain compatibility with those who have 
> implemented
> WS-A already, so we continue with UsingAddressing in WSDL, where the
> presence of UsingAddressing means that WS-Addressing is supported, but
> not required. We add mustUnderstand to make it required (this has the
> advantage of being backwards compatible - if the other end doesn't
> understand UsingAddressing then they clearly won't support it.
> 
> The problem is that for Policy, an assertion that "I support
> WS-Addressing but do not require it" cannot be readily 
> converted into "I
> require WS-Addressing" by use of Policy constructs (there's no
> "mustUnderstand" option). We could have said that the UsingAddressing
> assertion meant "I REQUIRE WS-Addressing", but then the meaning of the
> assertion and the WSDL marker would be different, even though the name
> was the same - that would be a BAD IDEA. So the assertion is
> AddressingRequired, which can be converted to optional through the use
> of WS-Policy constructs.
> 
> In other words, the WSDL marker is optional, add a (WSDL familiar)
> construct to make it required; the Policy assertion is required, add a
> (Policy familiar) construct to make it optional.
> 
> Hence the position we have reached, where we use different names,
> because they are different meanings.
> 
> Does that explain that bit more clearly? (I'm not talking about the
> other assertions here - that's another discussion...).
> 
> As I said, this is my understanding of the situation - I'm sure others
> will chime in if I'm misrepresenting things :-)
> 
> Tony Rogers
> tony.rogers@ca.com
> 
> -----Original Message-----
> From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> Sent: Wednesday, 15 November 2006 12:58
> To: Rogers, Tony; Marc Hadley; public-ws-addressing@w3.org
> Subject: RE: Updated proposal for WS-Policy assertions
> 
> Thanks Tony, but this does not answer my question. See below.
> 
> As a policy wonk, I look at it and scratch my head. In my opinion, you
> could easily move wsaw:UsingAddressing as a policy assertion with
> wsp:optional if the capability was not required. However, if the spec
> does not explain this well and most importantly the 
> interaction between
> the new assertions and the existing marker, it would not be useful.
> 
> For example,
> 
> (a) should I be able to indicate the capability of addressing
> independent of WSDL?
> (b) If addressing is not enabled, should I be able to attach a policy
> expression with WS-A assertions on top?
> C)If my intersection algorithm understands the 3 policy 
> assertions, do I
> still have to look at WSDL to make sense of the complete picture?
> (d) How does WS-Policy intersection algorithm work depending 
> on how you
> answer question 2?
> 
> I am trying to answer these myself, so I do not think that 
> the fat lady
> has started to sing yet although the necessary steps were made in the
> right direction.
> 
> Cheers,
> 
> --umit
> 
> 
> > -----Original Message-----
> > From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
> > Sent: Tuesday, Nov 14, 2006 5:51 PM
> > To: Yalcinalp, Umit; Marc Hadley; public-ws-addressing@w3.org
> > Subject: RE: Updated proposal for WS-Policy assertions
> >
> >
> > 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 05:57:21 GMT

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