- From: Tony Rogers via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 30 Jan 2007 10:44:22 +0000
- To: public-ws-addressing-eds@w3.org
Update of /sources/public/2004/ws/addressing
In directory hutz:/tmp/cvs-serv8463
Modified Files:
ws-addr-wsdl.xml
Log Message:
Adjusted definitions of response assertions, Replaced section 3.1.4 (moved to 3.1.6 and changed content)
Index: ws-addr-wsdl.xml
===================================================================
RCS file: /sources/public/2004/ws/addressing/ws-addr-wsdl.xml,v
retrieving revision 1.112
retrieving revision 1.113
diff -C 2 -d -r1.112 -r1.113
*** ws-addr-wsdl.xml 29 Jan 2007 09:37:37 -0000 1.112
--- ws-addr-wsdl.xml 30 Jan 2007 10:44:20 -0000 1.113
***************
*** 310,316 ****
<div2 id="wspolicyassertions">
<head>WS-Policy Assertions</head>
- <ednote>
- <edtext>open issue on policy attachment options</edtext>
- </ednote>
<p>The mechanism for indicating that a binding or endpoint conforms to the
WS-Addressing specification is through the use of the Web Services Policy -
--- 310,313 ----
***************
*** 335,347 ****
<p>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 <b>not</b> 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. </p>
<p>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
--- 332,346 ----
<p>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.</p>
! <p> 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]. In other words, the endpoint guarantees support for anonymous responses.</p>
! <p> The absence of the wsam:AnonymousResponses policy assertion within a policy
! alternative does <b>not</b> 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. </p>
<p>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
***************
*** 352,390 ****
<p>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 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; its 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 wsam:NonAnonymousResponses policy
! assertion within a policy alternative does <b>not</b> indicate that the
! endpoint will not accept request messages with response endpoint EPRs that
! contain something other than the anonymous URI address. </p>
<p>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.</p>
! </div3>
! <div3 id="usingbothnestedassertions">
! <head>Using both AnonymousResponses and NonAnonymousResponses</head>
! <p>If both AnonymousResponses and NonAnonymousResponses are supported, and the
! intention is to allow either to be used, care should be taken to ensure that
! there are alternatives such that a subject which supports only one will have
! a compatible policy [<bibref ref="WSPolicyPrimer"/> section 3.4]. There
! should be at least an alternative which includes just AnonymousResponses as
! a nested assertion and an alternative with just NonAnonymousResponses as a
! nested assertion.</p>
! <p>Note also that the lack of either of these assertions (AnonymousResponses and
! NonAnonymousResponses) does not indicate lack of support. So 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. </p>
! <ednote>
! <edtext>We will be providing a rationale for the use of Optional in
! connection with the nested assertions, explaining how the assertions are
! used by the server and the client. We may also rephrase the description
! of the assertions to help that explanation.</edtext>
! </ednote>
</div3>
<div3 id="policyexamplesincompact">
--- 351,372 ----
<p>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.</p>
! <p> 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 something other than the anonymous URI as the
! value of [address]. In other words, the endpoint guarantees support for
! 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. </p>
! <p>As with the other assertions, the absence of the wsam:NonAnonymousResponses
! policy assertion within a policy alternative does <b>not</b> 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. </p>
<p>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.</p>
</div3>
<div3 id="policyexamplesincompact">
***************
*** 575,578 ****
--- 557,637 ----
</example>
</div3>
+ <div3 id="usingintersection">
+ <head>Finding Compatible Policies</head>
+ <p>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.</p>
+ <p>Consider the following example, where we have a client who does not care
+ whether the endpoint explicitly supports anonymous responses, and a WSDL
+ which states that the endpoint does explicitly support anonymous
+ responses.</p>
+ <example>
+ <head>Client looking for an endpoint which supports Addressing, WSDL states explicit support for anonymous responses</head>
+ <eg xml:space="preserve"><wsp:Policy>
+ <wsam:Addressing>
+ <wsp:Policy/>
+ </wsam:Addressing>
+ </wsp:Policy></eg>
+ <p>The client's policy (above) states the requirement for Addressing, but no
+ requirement for explicit support of responses.</p>
+ <eg xml:space="preserve"><wsp:Policy>
+ <wsam:Addressing>
+ <wsp:Policy>
+ <wsam:AnonymousResponses/>
+ </wsp:Policy>
+ </wsam:Addressing>
+ </wsp:Policy></eg>
+ <p>The policy attached to the endpoint in the WSDL (above) states explicit support
+ for anonymous responses. The intersection of this policy with the
+ client's policy will be empty, so the client will miss a compatible
+ endpoint.</p>
+ <eg xml:space="preserve"><wsp:Policy>
+ <wsam:Addressing>
+ <wsp:Policy>
+ <wsam:AnonymousResponses wsp:Optional="true"/>
+ </wsp:Policy>
+ </wsam:Addressing>
+ </wsp:Policy></eg>
+ <p>This is what the client's policy could be; by stating that the
+ wsam:AnonymousResponses assertion is optional, there will be a non-empty
+ intersection with endpoint policies that do and do not contain this
+ assertion.</p>
+ </example>
+ <p>Now let us consider a variation on this same situation, where the WSDL marks its explicit
+ support of anonymous responses as ignorable.</p>
+ <example>
+ <head>Client looking for an endpoint which supports Addressing, WSDL states (ignorable) explicit support for anonymous responses</head>
+ <eg xml:space="preserve"><wsp:Policy>
+ <wsam:Addressing>
+ <wsp:Policy/>
+ </wsam:Addressing>
+ </wsp:Policy></eg>
+ <p>The client's policy (above) states the requirement for Addressing, but no
+ requirement for explicit support of responses.</p>
+ <eg xml:space="preserve"><wsp:Policy>
+ <wsam:Addressing>
+ <wsp:Policy>
+ <wsam:AnonymousResponses wsp:Ignorable="true"/>
+ </wsp:Policy>
+ </wsam:Addressing>
+ </wsp:Policy></eg>
+ <p>The policy attached to the endpoint in the WSDL (above) states explicit
+ support for anonymous responses, but marks that as an ignorable
+ assertion. Now the result of the policy intersection with the client's
+ policy will depend on whether the client is using lax or strict
+ intersection. The strict intersection of this policy with the client's
+ policy will still be empty. The lax intersection, on the other hand,
+ will not be empty, so the client will find a compatible endpoint.</p>
+ </example>
+ <p>These two examples show the use of wsp:Optional and wsp:Ignorable, and how
+ they can be used to produce non-empty intersections between client and
+ endpoint policies. For more detailed descriptions of the use of
+ wsp:Optional, wsp:Ignorable, and strict and lax intersection, please refer
+ to the WS-Policy Primer [<bibref ref="WSPolicyPrimer"/>].</p>
+ </div3>
</div2>
</div1>
Received on Tuesday, 30 January 2007 10:44:30 UTC