W3C home > Mailing lists > Public > public-ws-addressing-eds@w3.org > January to March 2007

2004/ws/addressing ws-addr-wsdl.xml,1.112,1.113

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
Message-Id: <E1HBqTO-0002F8-HO@lionel-hutz.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">&lt;wsp:Policy&gt;
+     &lt;wsam:Addressing&gt;
+         &lt;wsp:Policy/&gt;
+     &lt;/wsam:Addressing&gt;
+ &lt;/wsp:Policy&gt;</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">&lt;wsp:Policy&gt;
+     &lt;wsam:Addressing&gt;
+         &lt;wsp:Policy&gt;
+             &lt;wsam:AnonymousResponses/&gt;
+         &lt;/wsp:Policy&gt;
+     &lt;/wsam:Addressing&gt;
+ &lt;/wsp:Policy&gt;</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">&lt;wsp:Policy&gt;
+     &lt;wsam:Addressing&gt;
+         &lt;wsp:Policy&gt;
+             &lt;wsam:AnonymousResponses wsp:Optional="true"/&gt;
+         &lt;/wsp:Policy&gt;
+     &lt;/wsam:Addressing&gt;
+ &lt;/wsp:Policy&gt;</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">&lt;wsp:Policy&gt;
+     &lt;wsam:Addressing&gt;
+         &lt;wsp:Policy/&gt;
+     &lt;/wsam:Addressing&gt;
+ &lt;/wsp:Policy&gt;</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">&lt;wsp:Policy&gt;
+     &lt;wsam:Addressing&gt;
+         &lt;wsp:Policy&gt;
+             &lt;wsam:AnonymousResponses wsp:Ignorable="true"/&gt;
+         &lt;/wsp:Policy&gt;
+     &lt;/wsam:Addressing&gt;
+ &lt;/wsp:Policy&gt;</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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:41 GMT