- From: David Illsley <david.illsley@uk.ibm.com>
- Date: Wed, 6 Dec 2006 14:50:48 +0000
- To: public-ws-addressing@w3.org
Nested WS-Policy Assertions for WS-Addressing
Below is my proposal (borrowing heavily from the previous proposal),
followed by examples in compact and normal form. I believe that inclusion
in the specification of at least some of the examples in compact form
would be of benefit. As stated on the call I have used the name
wsaw:AddressingRequired for the container assertion rather than
wsaw:UsingAddressing as it's unclear if we can and we can have that
discussion separately. I've also left the issue of which policy subject(s)
to specify to be dealt with on the existing thread - "WS-Addr policy
attachment"
David
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 AddressingRequired Assertion
The wsaw:AddressingRequired policy assertion is a nested policy container
assertion. The meaning of this assertion when present in a policy
alternative is that WS-Addressing is required to communicate with the
subject. In order to indicate that the subject supports WS-Addressing but
does not require its use, an additional policy alternative should be
provided which does not contain this assertion. This may be done in
WS-Policy compact form by adding the attribute wsp:Optional="true" to the
AddressingRequired assertion.
3.2.1 AnonymousResponses Assertion
This element MAY be used as a policy assertion nested within the
AddressingRequired 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 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 nested within the
AddressingRequired 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 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.
NOTE: If both AnonymousResponses and NonAnonymousResponses are supported
and the intention is to allow either to be used care should be taken to
ensure there is an alternative which includes just AnonymousResponses as a
nested assertion and an alternative with just NonAnonymousResponses as a
nested assertion so that a subject which supports only one will have a
compatible policy [WS-Policy Primer 3.4] (e.g. 3, 4 below).
Also, given that the lack of either of these assertions
(AnonymousResponses and NonAnonymousResponses) does not indicate lack of
support, it is suggested that a subject that does not have a strict
compatibility requirement that an interacting subject understands or is
concerned with these assertions provides an alternative without either
assertion (e.g. 3 below).
3.2.3 Examples (Compact Form)
1. Subject supports addressing, no statement on supported response EPRs
<wsp:Policy>
<wsaw:AddressingRequired wsp:Optional="true">
<wsp:Policy></wsp:Policy>
</wsaw:AddressingRequired>
</wsp:Policy>
2. Subject requires addressing be used, no statement on supported response
EPRs
<wsp:Policy>
<wsaw:AddressingRequired>
<wsp:Policy></wsp:Policy>
</wsaw:AddressingRequired>
</wsp:Policy>
3. Subject supports addressing, explicitly (and optionally) supports anon
and non-anon response EPRs
<wsp:Policy>
<wsaw:AddressingRequired wsp:Optional="true">
<wsp:Policy>
<wsaw:AnonymousResponses wsp:Optional="true" />
<wsaw:NonAnonymousResponses wsp:Optional="true" />
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:Policy>
4. Subject requires addressing, requires explicit support of anon or
non-anon
<wsp:Policy>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsaw:AnonymousResponses />
<wsaw:NonAnonymousResponses />
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:Policy>
5. Subject requires addressing and use of non-anon response EPRs
<wsp:Policy>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsaw:NonAnonymousResponses />
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:Policy>
Examples (Normal Form)
1. Subject supports addressing, no statement on supported response EPRs
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All/>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All />
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
2. Subject requires addressing be used, no statement on supported response
EPRs
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All />
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
3. Subject supports addressing, explicitly (and optionally) supports anon
and non-anon response EPRs
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All/>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All />
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:AnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:NonAnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:AnonymousResponses />
<wsaw:NonAnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
4. Subject requires addressing, requires explicit support of anon or
non-anon
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:AnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:NonAnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
5. Subject requires addressing and use of non-anon response EPRs
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:AddressingRequired>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<wsaw:NonAnonymousResponses />
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsaw:AddressingRequired>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
David Illsley
Web Services Development
MP211, IBM Hursley Park, SO21 2JN
+44 (0)1962 815049 (Int. 245049)
david.illsley@uk.ibm.com
Received on Wednesday, 6 December 2006 14:51:05 UTC