RE: Draft: Response to the Last Call comments by WS-Policy to the WS-Addressing Metadata document 1.0 from Ashok Malhotra on 2007-04-23 (public-ws-addressing@w3.org from April 2007)

From: Ashok Malhotra <ashok.malhotra@oracle.com>
Date: Mon, 23 Apr 2007 12:42:01 -0700
To: "Bob Freund" <bob@freunds.com>, "[WS-A]" <public-ws-addressing@w3.org>
Message-ID: <20070423124201755.00000004468@amalhotr-pc>
The normal form of the examples is overly verbose.  I have corrected the syntax below.  In addition the first two examples in 3.1.4 seem to be duplicates

 


3.1.4 Examples (Compact Form)


Example 3-46. Subject supports WS-Addressing, no statement on supported response EPRs

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing>

      <wsp:ExactlyOne>

      <wsp:All>

              <wsp:Policy/>

      </wsp:All>

      </wsp:ExactlyOne>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

 

 

The following policy will intersect with a policy that either supports WS-Addressing (with no constraints) or supports WS=-Addressing with Anonynous responses because of the Optional='true on Anonymous responses.  Is this what you want?

 

Example 3-7. Client looking for an endpoint which supports Addressing, and which supports anonymous responses

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<AnonymousResponses Optional=true />

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

 

 

All the best, Ashok 

________________________________

From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Bob Freund
Sent: Monday, April 23, 2007 11:28 AM
To: [WS-A]
Subject: Draft: Response to the Last Call comments by WS-Policy to the WS-Addressing Metadata document 1.0

 


3. Indicating Use of WS-Addressing


This specification supports a mechanism for indicating, in a WSDL description, that the endpoint conforms to the WS-Addressing specification. That mechanism uses WS-Policy Framework [WS Policy 1.5 - Framework].


3.1 WS-Policy Assertions


The mechanism for indicating that a binding or endpoint conforms to the WS-Addressing specification is through the use of the Web Services Policy - Framework [WS Policy 1.5 - Framework] and Web Services Policy - Attachment [WS Policy 1.5 - Attachment] specifications. This specification defines three policy assertions.

The wsam:Addressing policy assertion applies to the endpoint policy subject.

For WSDL 1.1, these assertions may be attached to wsdl11:port or wsdl11:binding. For WSDL 2.0, they may be attached to wsdl20:endpoint or wsdl20:binding.

A policy expression containing the wsam:Addressing policy assertion MUST NOT be attached to a wsdl:portType or wsdl20:interface. The wsam:Addressing policy assertion specifies a concrete behavior whereas the wsdl:portType or wsdl20:interface is an abstract construct.


3.1.1 Addressing Assertion


The wsam:Addressing 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. The wsam:Addressing assertion indicates that there are no restrictions on the use of WS-Addressing unless otherwise qualified by assertions in its nested policy expression. 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 wsam:Addressing assertion. 

 


3.1.2 AnonymousResponses Assertion


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 alternativethe wsam:Addressing policy assertion indicates that the endpoint expresses explicitrequires support for request messages with to use response endpoint EPRs that contain the anonymous URI ("http://www.w3.org/2005/08/addressing/anonymous") as the value of [address]. In other words, the endpoint guarantees support forrequires the use of 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. 

The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the value of [address] in place of the anonymous URI; this value MUST be accepted.


3.1.3 NonAnonymousResponses Assertion


The wsam:NonAnonymousResponses element MAY be used as a policy assertion nested within the Addressing assertion in accordance with the rules laid down by WS-Policy Framework 1.5 section 4.3.2. The wsam:NonAnonymousResponses policy assertion MUST NOT be used in the same policy alternative as the wsam:AnonymousResponses policy assertion.

The appearance of this element within a policy alternativethe wsam:Addressing assertion indicates that the endpoint expresses explicit support forrequires request messages with to use response endpoint EPRs that contain something other than the anonymous URI as the value of [address]. In other words, the endpoint guarantees support forrequires the use of non-anonymous responses. This assertion is deliberately vague; its presence indicates that some non-anonymous addresses will 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 wsam: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; it simply indicates the lack of any affirmation of support for them. 

The None URI ("http://www.w3.org/2005/08/addressing/none") may appear as the value of [address] in place of a non-anonymous address; this value MUST be accepted.


3.1.4 Examples (Compact Form)


Example 3-1. Subject supports WS-Addressing, no statement on supported response EPRs

<wsp:Policy>

<wsam:Addressing wsp:Optional="true">

<wsp:Policy/>

</wsam:Addressing>

</wsp:Policy>

Example 3-2. Subject requires WS-Addressing, no statement on supported response EPRs

<wsp:Policy>

<wsam:Addressing>

<wsp:Policy/>

</wsam:Addressing>

</wsp:Policy>

Example 3-3. Subject supports WS-Addressing, explicitly (and optionally) supports anonymous and non-anonymous response EPRs

<wsp:Policy>

<wsam:Addressing wsp:Optional="true">

<wsp:Policy>

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

<wsam:NonAnonymousResponses wsp:Optional="true"/>

</wsp:Policy>

</wsam:Addressing>

</wsp:Policy>

Example 3-4. Subject requires WS-Addressing, requires explicit support of anonymous or non-anonymous response EPRs

<wsp:Policy>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsam:AnonymousResponses/>

<wsam:NonAnonymousResponses/>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:Policy>

Example 3-53. Subject requires WS-Addressing and explicit supportrequires the use of non-anonymous response EPRs

<wsp:Policy>

<wsam:Addressing>

<wsp:Policy>

<wsam:NonAnonymousResponses/>

</wsp:Policy>

</wsam:Addressing>

</wsp:Policy>


3.1.5 Examples (Normal Form)


Example 3-46. Subject supports WS-Addressing, no statement on supported response EPRs

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All/>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All/>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

Example 3-57. Subject requires WS-Addressing, no statement on supported response EPRs

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All/>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

Example 3-8. Subject supports WS-Addressing, explicitly (and optionally) supports anonymous and non-anonymous response EPRs

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All/>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All/>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:AnonymousResponses/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:NonAnonymousResponses/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:AnonymousResponses/>

<wsam:NonAnonymousResponses/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

Example 3-9. Subject requires WS-Addressing, requires explicit support of anonymous or non-anonymous response EPRs

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:AnonymousResponses/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:NonAnonymousResponses/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

Example 3-610. Subject requires WS-Addressing and explicit support ofrequires the use of non-anonymous response EPRs

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:NonAnonymousResponses/>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>


3.1.6 Finding Compatible Policies


When a client is looking for an endpoint with compatible policy, one common method used is to take the policy intersection between the policy which the client is looking for, and the policy asserted in the WSDL document; a non-empty intersection is sought. The policy used by the client must be written carefully to avoid unexpected results. This is most obvious when the client is not looking for explicit support of a particular kind of response; failing to take care could mean missing a compatible policy.


Example 3-7. Client looking for an endpoint which supports Addressing, and which supports anonymous responses

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing>

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<AnonymousResponses Optional=true />

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

Example 3-8. Client looking for an endpoint which supports Addressing, and does not require support for responses (will intersect with anything)

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<wsam:Addressing> <-- supports all response types -->

<wsp:Policy> 

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

<wsp:All>

<wsam:Addressing> <-- requires Anonymous responses -->

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<AnonymousResponses />

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

<wsp:All>

<wsam:Addressing> <- requires nonAnonymous responses -->

<wsp:Policy>

<wsp:ExactlyOne>

<wsp:All>

<NonAnonymousResponses />

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>

</wsam:Addressing>

</wsp:All>

</wsp:ExactlyOne>

</wsp:Policy>


 


 


For more detailed descriptions of the use of wsp:Optional, wsp:Ignorable, and strict and lax intersection, please refer to the WS-Policy Primer [WS Policy 1.5 - Primer].
Received on Monday, 23 April 2007 19:44:16 UTC