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_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 Monday, 4 December 2006 20:38:58 UTC