Re: First cut policy write up

Yalcinalp, Umit wrote:
> See below. 
>   
I also like the idea of properly nested policy assertions, which are 
covered by defalt intersection
algorithm.

Tom
>  
>
>   
>> -----Original Message-----
>> From: public-ws-addressing-request@w3.org 
>> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
>> David Illsley
>> Sent: Friday, Dec 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.
>>
>>     
>
> I am really not following this point. Could you clarify?  
>
> If you do not use wsp:optional and use the standard attachment
> mechanisms, why wouldn't WS-Addressing be NOT required. 
>
> IF there is no alternative in the policy, the intersection algorithm and
> thus the client will treat WS-Addressing assertion as an addition that
> it needs to understood and thus make behavior required. 
>
>   
>> 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. "
>>
>>     
>
> I agree that the nested policy is what should be followed here. I was
> about to write a very similar email, you beat me to it. 
>
>   
>> 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
>>
>>
>>
>>
>>
>>     
>
>   


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Friday, 1 December 2006 23:36:51 UTC