- From: Prasad Yendluri via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 11 May 2007 22:51:37 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv21950
Modified Files:
ws-policy-guidelines.xml
Log Message:
Updated 5.6 WSDL guidelines section to add G19 identified in AI 256 (now G24). Accounts for parts of resolution for issue 3989 corresponding to editors' action item 256 - now complete.
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.68
retrieving revision 1.69
diff -u -d -r1.68 -r1.69
--- ws-policy-guidelines.xml 8 May 2007 19:50:02 -0000 1.68
+++ ws-policy-guidelines.xml 11 May 2007 22:51:35 -0000 1.69
@@ -1213,13 +1213,15 @@
<p> In using WSDL attachment, it should be noted that the
service policy subject is a collection of endpoint policy
subjects. The endpoint policy subject is a collection of
- operation policy subjects and etc. As a result, the WSDL
+ operation policy subjects and so on. As a result, the WSDL
policy subjects compose naturally. It is quite tempting to
associate the identified behavior to a broader policy subject
than to a fine granular policy subject. For instance, it is
convenient to attach a supporting token assertion (defined by
the Web Services Security Policy specification) to an endpoint
- policy subject instead of a message policy subject.
+ policy subject instead of a message policy subject. However such
+ policy attachments to policy subjects of broader scope and granularity
+ should be done only after careful evaluation.
</p>
<p role="practice" id="bp-WSDL-multiple-policy-subjects">
@@ -1243,7 +1245,7 @@
<p>If the capability is not really suitable and may imply
different semantics with respect to attachment points, the
- assertion authors should consider the following</p>
+ assertion authors should consider the following:</p>
<ulist>
<item>
<p> Decompose the semantics with several assertions.</p>
@@ -1252,20 +1254,29 @@
<p> Rewrite a single assertion targeting a specific subject. </p>
</item>
</ulist>
+
+ <p role="practice" id="bp-WSDL-policy-scope-semantics">
+ <quote>Fully specify constraints on policy scope</quote>
+ <quote>Assertion authors must clearly describe any constraints on the
+ policy scope if not limited to policy subjects identified by the policy
+ attachment point.
+ </quote>
+ </p>
<p>The current set of subjects as mapped to the WSDL 1.1
elements, can also constrain the assertion constructs.
- For Example, in WS-RM,
- the assertion authors chose to support certain capabilities at
- the endpoint level. This resulted in the finer granularity of
- the assertion to apply at the message policy subject, but the
- assertion semantics also indicates that the if
- a sender chose to engage RM
- semantics (although not specified via attachment in WSDL at incoming
- messages), the providers will honor the engagement of RM.
- This is illustrative of how the
- assertion author can specify additional constraints and
- assumptions for attachment and engagement of behavior.
+ For Example, in WS-RM, the assertion authors chose to support
+ certain capabilities at the endpoint level. This resulted in
+ the finer granularity of the assertion to apply at the message
+ policy subject, but the assertion semantics also indicates that
+ the if a sender chose to engage RM semantics (although not specified
+ via attachment in WSDL at incoming messages), the providers will honor
+ the engagement of RM. So, the WS-RM Policy is a capability that
+ governs a target endpoints capability to accept sequences that
+ is beyond single message exchanges. This is illustrative of how the
+ assertion author can specify additional constraints and assumptions
+ for attachment and engagement of behavior. Such additional constraints
+ must be clearly specified by the assertion authors.
</p>
<p role="practice" id="bp-WSDL-preferred-attachment-point">
@@ -1282,8 +1293,8 @@
specify that as a preferred attachment point. However, this
approach only works if the policy subject is a true WSDL
construct other than some other protocol concept that is
- layered over WSDL message exchanges. For example, the WS-RM
- Policy is a capability that governs a target endpoints
+ layered over WSDL message exchanges. For example, as described previously
+ the WS-RM Policy is a capability that governs a target endpoints
capability to accept sequences that is beyond single message
exchanges. Therefore, its semantics encompasses the cases when
message level policy subjects may be used as attachment but
@@ -1291,6 +1302,34 @@
policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
</p>
+
+ <p role="practice" id="bp-WSDL-policy-multiple-instance-semantics">
+ <quote>Semantics of multiple assertions of the same kind</quote>
+ <quote>A policy alternative can contain multiple instances of the
+ same policy assertion. An assertion description should specify the
+ semantics of multiple instances of a policy assertion in the same
+ policy alternative and the semantics of parameters and nested policy
+ (if any) when there are multiple instances of a policy assertion in
+ the same policy alternative.
+ </quote>
+ </p>
+ <p>Assertion authors that utilize WSDL policy subjects need to
+ understand how the assertions will be processed in merging and
+ the specify implications of ending up with multiple assertions of
+ the same kind in an alternative, in the merged policy. For example,
+ consider the SignedParts assertion defined in WS-SecurityPolicy 1.2.
+ The definition of SignedParts assertion explicitly permits multiple
+ SignedParts assertions to be present within a policy alternative,
+ and declares it to be equivalent to a single SignedParts assertion
+ containing the union of all specified message parts. So, if a SignedParts
+ assertion is specified in a WSDL binding at the input message level
+ and subsequently an additional SignedParts assertion is specified
+ at the WSDL endpoint policy subject level, then the effective policy
+ at the endpoint could have more than one SignedParts assertion in the
+ same alternative. However, the clear semantics defined by the SignedParts
+ assertion enable processing of the multiple occurrences properly.
+ </p>
+
</div2>
<div2 id="interrelated-domains">
<head>Interrelated domains</head>
@@ -2341,7 +2380,17 @@
<loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/256">256</loc>.
</td>
</tr>
-
+ <tr>
+ <td>20070511</td>
+ <td>PY</td>
+ <td>Updated 5.6 WSDL guidelines section to add G19 identified in AI 256 (now G24).
+ Accounts for parts of resolution for
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=3989">issue 3989</loc>
+ corresponding to editors' action item
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/232">256</loc>
+ - now complete.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Friday, 11 May 2007 22:51:39 UTC