Re: WS-A Action Item: proposal for use of policy

Rogers, Tony wrote:
> I added the editorial note to 3.1.4.
> Below is some suggested language to disentangle the confusion.
> === making the meaning of the policy assertions clearer ===
> Taking section 3.1.2 as our example (3.1.3 is identical in structure). 
> Current content reads:
>
> The wsam:AnonymousResponses element MAY be used as a policy assertion 
> nested within the wsam:Addressing assertion in accordance with the 
> rules laid down by WS-Policy Framework 1.5 section 4.3.2. 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 wsam: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.
>
> I propose that we change this to:
>
> The wsam:AnonymousResponses element MAY be used as a policy assertion 
> nested within the wsam:Addressing assertion in accordance with the 
> rules laid down by WS-Policy Framework 1.5 section 4.3.2.
>
> The appearance of this element within a policy alternative indicates 
> that the endpoint expresses explicit support for request messages with 
> response endpoint EPRs that contain the anonymous URI 
> ("http://www.w3.org/2005/08/addressing/anonymous") as the value of 
> [address]. An alternative interpretation is that the endpoint 
> guarantees support for anonymous responses.
>
> The absence of the wsam: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.
>
I think this new wording is more precise. I like it.
> === clarifying use of policy intersection to find compatible policy ===
> This is new language - it might make a good replacement or extension 
> for 3.1.4:
> If a client is looking for an endpoint with compatible policy, one 
> common method used is to take the policy intersection between the 
> policy the client is looking for and the policy asserted in the WSDL. 
> The policy used by the client for this purpose must be written 
> carefully to avoid unexpected results. Note in particular that a 
> client which does not require explicit support for anonymous responses 
> should use a policy assertion which includes wsam:AnonymousResponses, 
> marked as optional - failing to do so could mean missing a compatible 
> policy. The same applies to wsam:NonAnonymousResponses.
The following analysis verifies the policy intersection for the three 
policy expressions
(A, B, and C)From Tony’s Example.

It also introduces an example using the ignorable attribute.

Section 1 reproduces Tony’s example.
Section 2 shows the intersection of A with B
Section 3 shows the intersection of C with B
Section 4 introduces a new example policy expression D,
which uses the ignorable attribute, and shows the Lax intersection of A 
with D.

-------
1 Example from Tony:
“
Example:
If the client does not require explicit support for anonymous responses,
but does require WS-Addressing, and uses Policy Assertion A:

<wsp:Policy>
<wsam:Addressing>
<wsp:Policy/>
</wsam:Addressing>
</wsp:Policy>

(client is looking for Addressing required, but is not concerned about 
explicit
support for anonymous responses)and the WSDL contains Policy Assertion B:

<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:AnonymousResponses/>
</wsp:Policy>
</wsam:Addressing>
</wsp:Policy>

(WSDL expresses Addressing required, offers explicit support for anonymous
responses) then the policy intersection will be empty, and the client 
will miss
a compatible endpoint.

The client's policy assertion should read: (Policy Assertion C:

<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:AnonymousResponses wsp:Optional="true"/>
</wsp:Policy>
</wsam:Addressing>
</wsp:Policy>

“

-------

2 Intersection of A with B

Normalized Policy Expression A:

<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— Alternative A1 -->
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All/> <!— inner Alternative A2 -->
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing?
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

Normalized Policy Expression B:

<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— Alternative B1 -->
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— inner Alternative B2 -->
<wsam:AnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing?
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>


Assertions A1 and B1 each contain a nested policy expression.

The inner nested alternative of A is (A2):
<wsp:All>
<wsam:AnonymousResponses/>
</wsp:All>

and the inner nested alternative of B is (B2):
<wsp:All/>

By the following rule from WS Policy:
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.html?content-type=text/html;%20charset=utf-8#Policy_Intersection 
:
“
*If the mode is strict, two policy alternatives A and B are compatible:
o if each assertion in A is compatible with an assertion in B, and
o if each assertion in B is compatible with an assertion in A.
“
A2 and B2 are not compatible (since an assertion in A2 is not compatible 
with
any assertion in B2).

By the following rule from WS Policy:
“
* Two policy assertions are compatible if they have the same type and
* If either assertion contains a nested policy expression, the two
assertions are compatible if they both have a nested policy expression 
and the
alternative in the nested policy expression of one is compatible with the
alternative in the nested policy expression of the other.
“
it follows that nested policy assertions A1 and B1 are not compatible, 
because
A2 and B2 are not compatible.

By the following rule from WS Policy:
“
* Two policies are compatible if an alternative in one is compatible 
with an
alternative in the other. If two policies are compatible, their 
intersection is
the set of the intersections between all pairs of compatible alternatives,
choosing one alternative from each policy. If two policies are not 
compatible,
their intersection has no policy alternatives.
“
it follows that policy A and B are not compatible since there is no 
alternative
in A compatible with an alternative in B.

Thus A Intersect B has no alternatives:

----------

3 Intersection of C with B:

Normalized Policy Expression C:
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— Alternative C1 -->
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— inner Alternative C2 -->
<wsam:AnonymousResponses/>
</wsp:All>
<wsp:All/> <!— inner Alternative C3 -->
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing?
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

Normalized Policy Expression B:
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— Alternative B1 -->
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— inner Alternative B2 -->
<wsam:AnonymousResponses/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing?
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

Assertions C1 and B1 each contain a nested policy expression.

The inner nested alternatives of C are (C2):
<wsp:All>
<wsam:AnonymousResponses/>
</wsp:All>
and (C3)
<wsp:All/> <!— inner Alternative C3 -->
while, the inner nested alternative of B is (B2):
<wsp:All/>

C3 and B2 are compatible since each is an empty alternative.

By application of the other rules the intersection of C and B is as follows:
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All/> <!— intersection of C3 and B2 -->
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing?
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

which happens to be equivalent to policy expression A.

------

4 Use of Ignorable attribute

Lets try another policy Expression D, which uses the Ignorable Attribute:
<wsp:Policy>
<wsam:Addressing>
<wsp:Policy>
<wsam:AnonymousResponses wsp:Ignorable="true"/>
</wsp:Policy>
</wsam:Addressing>
</wsp:Policy>

Normalized Policy Expression D:
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— Alternative D1 -->
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— inner Alternative D2 -->
<wsam:AnonymousResponses wsp:Ignorable=”true”/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing?
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

By application of the following rule for Lax Intersection Algorithm from 
WS Policy:
“
- If the mode is lax, two policy alternatives A and B are compatible:
* if each assertion in A that is not an ignorable policy assertion is
compatible with an assertion in B, and
* if each assertion in B that is not an ignorable policy assertion is
compatible with an assertion in A.

If two alternatives are compatible, their intersection is an alternative
containing all of the assertions in both alternatives.
“
A2 and D2 are Lax compatible, and the Lax intersection of A2 with D2 is:
<wsp:All> <!— A2 intersectLax D2 -->
<wsam:AnonymousResponses wsp:Ignorable=”true”/>
</wsp:All>

Note that if the wsdl policy supports expression D, and the client supports
expression A, their lax intersection (A intersectLax D) is:

<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsam:Addressing>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All> <!— D2 intersectLax A2 -->
<wsam:AnonymousResponses wsp:Ignorable=”true”/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsam:Addressing?
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

Note that if the wsdl policy supports expression D, and the client supports
expression A,their lax intersection is equivalent to expression D.

I think this is a better alternative than having the WSDL support B and the
client supporting C. In the end the client will have an intersected policy
which includes the ignorable assertion for anonymousResponses.


Tom Rutt

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

Received on Monday, 29 January 2007 20:13:36 UTC