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

RE: First cut policy write up

From: Gilbert Pilz <Gilbert.Pilz@bea.com>
Date: Mon, 4 Dec 2006 12:41:07 -0800
Message-ID: <E16EB59B8AEDF445B644617E3C1B3C9C02C38465@repbex01.amer.bea.com>
To: "Marc Goodner" <mgoodner@microsoft.com>, "David Illsley" <david.illsley@uk.ibm.com>
Cc: <public-ws-addressing@w3.org>
Wait, why are we talking about nesting UsingAddressing? I thought that, if
we did get into nesting our policy assertions, UsingAddressing would have to
be the top-level, containing assertion.

- gp 

> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> Sent: Monday, December 04, 2006 12:37 PM
> To: David Illsley; Gilbert Pilz
> Cc: public-ws-addressing@w3.org
> Subject: RE: First cut policy write up
> 
> So are you also proposing that UsingAddressing now be only a 
> policy assertion? Or is it possible to describe its use as 
> both a WSDL marker and as a nested policy assertion?
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> David Illsley
> Sent: Friday, December 01, 2006 5:03 AM
> To: Gilbert Pilz
> Cc: public-ws-addressing@w3.org
> Subject: Re: First cut policy write up
> 
> 
> I spent a while yesterday going over this proposal with Katy, 
> Paco, and our WS-Policy development team and we have a couple 
> of concerns.
> 
> 1. There is no way to mandate addressing in this proposal 
> i.e. In normal form (once the wsp:Optionals etc have been 
> expanded) the presence of wsaw:UsingAddressing only indicates 
> addressing is supported. We need a way to say addressing is 
> required. I don't have a proposal yet to deal with this.
> 
> 2. I was a little unclear reading the proposal and then the 
> examples if the AnonymousResponses element implies addressing 
> is supported.. hence 2a and 2b below
> 
> 2a. AnonymousResponses implies addressing supported
>         As noted in elsewhere in the thread, 
> AnonymousResponses and UsingAddressing won't intersect which 
> doesn't fit with the policy processing model.
>                 e.g. A server which only supports 
> AnonymousResponses only includes the AnonymousResponses 
> assertion. A client doesn't care and has the UsingAddressing 
> assertion.
>                         These assertions clearly don't 
> intersect, and requiring any policy subject which supports 
> anon and non-anon to include all 3 as wsp:Optional="true" 
> will significantly increase the number of alternatives on 
> normalisation. It also includes alternatives in which 
> addressing is not supported which is not the intent.
> 
> 2b. AnonymousResponses does not imply addressing supported - 
> UsingAddressing also needed to indicate addressing suppot
>         In this case, to allow a client policy which only has 
> the UsingAddressing assertion to intersect with a server 
> policy with the AnonymousResponses assertion, the 
> AnonymousResponses assertion would have to be 
> wsp:Optional="true". If addressing support (UsingAddressing) 
> is itself optional then when this is expanded to normal form 
> there will be an invalid alternative containing just the 
> AnonymousResponses assertion.
> 
> The solution (and proposal) we arrived at for 2 is to use 
> proper nested policy[1] (not parameterised policy[2] as 
> discussed on the Monday call).
> This seems appropriate as the type of responses supported is 
> dependant on the fact that addressing is supported. The use 
> of nested WS-Policy for this situation is explicitly called 
> out in the WS-Policy Primer[3].
>         Extract: "Best practice: represent dependent 
> behaviors that apply to the same policy subject using nested 
> policy assertions. "
> 
> This follows the path of 2b where the UsingAddressing (or a 
> replacement given 1 above) is used to indicate addressing 
> support and the other assertions clarify. It has the 
> advantage that none of the generated alternatives when taken 
> to normal form are invalid.
> 
> This would look like*:
>  1. Addressing supported, no statement about response EPRs 
> supported <wsaw:UsingAddressing>
>         <wsp:Policy />          <!- required by WS-Policy Framework
> Section 4.3.2 -->
> </wsaw:UsingAddressing>
> 
> 2. Addressing supported, AnonymousResponses explicitly 
> supported <wsaw:UsingAddressing>
>         <wsp:Policy>
>                 <wsaw:AnonymousResponses wsp:Optional="true" />
>         </wsp:Policy>
> </wsaw:UsingAddressing>
> 
> 3. Addressing supported, NonAnonymousResponses explicitly 
> supported <wsaw:UsingAddressing>
>         <wsp:Policy>
>                 <wsaw:NonAnonymousResponses wsp:Optional="true" />
>         </wsp:Policy>
> </wsaw:UsingAddressing>
> 
> 4. Addressing supported, Anonymous and NonAnonymousResponses 
> explicitly supported <wsaw:UsingAddressing>
>         <wsp:Policy>
>                 <wsaw:AnonymousResponses wsp:Optional="true" />
>                 <wsaw:NonAnonymousResponses wsp:Optional="true" />
>         </wsp:Policy>
> </wsaw:UsingAddressing>
> 
> A client which requires explicit support of anonymous 
> responses would then have a policy of:
> <wsaw:UsingAddressing>
>         <wsp:Policy>
>                 <wsaw:AnonymousResponses/>
>         </wsp:Policy>
> </wsaw:UsingAddressing>
> 
> which would intersect with 2 and 4.
> 
> David
> 
> * N.B. There is a discussion to be had about whether the 
> above wsaw:AnonymousResponse and wsaw:NonAnonymousResponses 
> should be wsp:Ignorable rather than wsp:Optional but 
> wsp:Ignorable is new and less well understood so agreement on 
> a nested approach seems like a good first step.
> 
> [1]
> http://www.w3.org/TR/2006/WD-ws-policy-20061117/#nested_policy
_expression
> [2]
> http://www.w3.org/TR/2006/WD-ws-policy-20061117/#policy_assert
ion_parameter
> [3]
> http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#levera
ging-nested-policy
> 
> David Illsley
> Web Services Development
> MP211, IBM Hursley Park, SO21 2JN
> +44 (0)1962 815049 (Int. 245049)
> david.illsley@uk.ibm.com
> 
> 
> 
> From:
> "Gilbert Pilz" <Gilbert.Pilz@bea.com>
> To:
> <public-ws-addressing@w3.org>
> Date:
> 11/29/2006 11:20 PM
> Subject:
> First cut policy write up
> 
> 
> Here's a first cut at the write up for the 11/27 consensus on 
> CR33. My apologies if I have mis-phrased anything. The aim is 
> to get to a point where we can discuss the actual wording of 
> the proposal rather than the models and concepts . . .
> 
> ----------
> 
> [ rephrase first sentence of section 3 ]
> 
> [ strike sections 3.1.2 and 3.2 ]
> 
> 3.2 WS-Policy Assertions
> 
> The other mechanism for indicating that a binding or endpoint 
> [ note: open issue on policy attachment options ] conforms to 
> the WS-Addressing specification is through the use of the Web 
> Services Policy - Framework [WS-Policy] and Web Services 
> Policy - Attachment [WS-PolicyAttachment] specifications. [ 
> insert appropriate references ]. This specification defines 
> the following three policy assertions:
> 
> 3.2.1 UsingAddressing Assertion
> 
> In addition to the use described in section 3.1, the 
> wsaw:UsingAddressing element MAY also be used as a policy 
> assertion. The wsaw:UsingAddressing policy assertion is 
> semantically equivalent to the wsaw:UsingAddressing WSDL 
> extension. Note that the semantics indicated by the use of 
> wsdl:required="true" in the WSDL extension (i.e. the fact 
> that Message Addressing Properties are required for all 
> request messages) are not available to the 
> wsaw:UsingAddressing policy assertion. The absence of the 
> wsaw:UsingAddressing policy assertion within a policy alternative does
> *not*
> indicate that addressing is not supported; it simply 
> indicates the lack of any affirmation of support for WS-Addressing.
> 
> 3.2.1 AnonymousResponses Assertion
> 
> This element MAY be used as a policy assertion. The 
> appearance of this element within a policy alternative 
> indicates that the endpoint will accept request messages with 
> response endpoint EPRs that contain the anonymous URI 
> ("http://www.w3.org/2005/08/addressing/anonymous") as the 
> value of [address]. The absence of the 
> wsaw:AnonymousResponses policy assertion within a policy 
> alternative does *not* indicate that the endpoint will not 
> accept request messages with response endpoint EPRs that 
> contain the anonymous URI as an address; it simply indicates 
> the lack of any affirmation of support for anonymous URIs.
> 
> 3.2.2 NonAnonymousResponses Assertion
> 
> This element MAY be used as a policy assertion. The 
> appearance of this element within a policy alternative 
> indicates that the endpoint will accept request messages with 
> response endpoint EPRs that contain something other than the
> 
> anonymous URI as the value of [address]. This assertion is 
> deliberately vague; it's presence indicates that a 
> non-anonymous addresses might be accepted but doesn't 
> constrain what such an address might look like. A receiver 
> can still reject a request that contains an address that it 
> doesn't understand or that requires a binding it doesn't 
> support. As with the other assertions, the absence of the 
> wsaw:NonAnonymousResponses policy assertion within a policy
> 
> alternative does *not* indicate that the endpoint will not 
> accept request messages with response endpoint EPRs that 
> contain something other than the
> 
> anonymous URI address.
> 
> 3.2.3 Policy Examples
> 
> The above policy assertions are designed to be used either 
> independently or in conjunction with one another. The 
> following examples illustrate some possible
> combinations:
> 
> <wsp:Policy>
>   <wsaw:UsingAddressing>
> </wsp:Policy>
> 
> This policy indicates that the subject supports the use of 
> WS-Addressing.
> If a
> fault is generated as a result of sending a request message 
> to an endpoint with this effective policy, that fault will 
> not be due to the simple fact that the request message 
> includes WS-Addressing headers. Note that nothing is said 
> about either supporting or not supporting the use of 
> anonymous or non-anonymous URIs.
> 
> <wsp:Policy>
>   <wsaw:AnonymousResponses>
> </wsp:Policy>
> 
> This policy indicates that the subject supports the use of 
> WS-Addressing and, in particular, will accept request 
> messages with response endpoint EPRs that contain the 
> anonymous URI. If a fault is generated as a result of sending 
> a request message to an endpoint with this effective policy, 
> that fault will not be due to the fact that the request 
> message includes WS-Addressing headers nor will it be due to 
> the fact that the response endpoint EPRs contain the 
> anonymous URI as an address. Note that nothing is said about 
> either supporting or not supporting the use of non-anonymous URIs.
> 
> <wsp:Policy>
>   <wsaw:UsingAddressing>
>   <wsaw:AnonymousResponses>
> </wsp:Policy>
> 
> The above policy is semantically equivalent to the previous 
> example. Note that this example could be the result of 
> combining two separate policies (e.g.
> one
> attached at a wsdl:binding and the other at a wsdl20:endpoint (or
> wsdl11:port)) into a single effective policy.
> 
> <wsp:Policy>
>   <wsaw:NonAnonymousResponses>
> </wsp:Policy>
> 
> <wsp:Policy>
>   <wsaw:UsingAddressing>
>   <wsaw:NonAnonymousResponses>
> </wsp:Policy>
> 
> The above two policies are identical ways of expressing the 
> fact that the subject supports the use of WS-Addressing and, 
> in particular, will accept request messages with response 
> endpoint EPRs that contain URIs other than the anonymous URI. 
> If a fault is generated as a result of sending a request 
> message to an endpoint with either of these policies, that 
> fault will not be due to the fact that the request message 
> includes WS-Addressing headers nor will it be due to the mere 
> fact that the response endpoint EPRs contain a non-anonymous 
> URI as an address. Note that nothing is said about either 
> supporting or not supporting the use of the anonymous URI.
> 
> -------------
> 
> - gp
> 
> 
> 
> 
> 


Received on Monday, 4 December 2006 20:41:47 GMT

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