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_assertion_parameter
[3] 
http://www.w3.org/TR/2006/WD-ws-policy-primer-20061018/#leveraging-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 Friday, 1 December 2006 13:03:20 UTC