- From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 01 Nov 2006 02:32:19 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv19092
Modified Files:
ws-policy-guidelines.html
Log Message:
Optional behaviors take 2
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- ws-policy-guidelines.html 1 Nov 2006 01:18:39 -0000 1.6
+++ ws-policy-guidelines.html 1 Nov 2006 02:32:16 -0000 1.7
@@ -63,7 +63,7 @@
guide to using the specifications. </p></div><div>
<h2><a name="status">Status of this Document</a></h2><p><strong>This document is an editors' copy that has
no official standing.</strong></p><p></p></div><hr><div class="toc">
-<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">Basic Concepts: What is an Assertion</a><br> 2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br> 2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 2.1.2 <a href="#consumers">Consumers</a><br> 2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 3.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>4. <a href="#compact-full">Authoring Styles </a><br>5. <a href="#modeling-guidelines">Guidelines for Modeling New Assertions</a><br> 5.1 <a href="#new-domains">New Policy Domains</a><br> 5.2 <a href="single-domains">Single Domains</a><br> 5.3 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 5.3.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 5.3.2 <a href="#nested-assertions">Nested Assertions</a><br> 5.3.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 5.4 <a href="#self-describing"> Self Describing Messages </a><br> 5.5 <a href="#optional-policy-assertion">Optional Policy Assertion</a><br> 5.6 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br> 5.7 <a href="#typing-assertions">Typing Assertions</a><br> 5.8 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br> &nsp; 5.9 <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.9.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.9.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br> 5.9.3 <a href="#assertion-evolution">Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction betwen Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenerio">Scenario and a worked example</a><br></p>
+<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#introduction">Introduction</a><br>2. <a href="#Assertions">Basic Concepts: What is an Assertion</a><br> 2.1 <a href="#assertion-roles">Roles and Responsibilities in Utilizing Policy Assertions</a><br> 2.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 2.1.2 <a href="#consumers">Consumers</a><br> 2.1.3 <a href="#providers">Providers</a><br>3. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 3.1 <a href="#assertion-target">Assertions and Their Target Use</a><br>4. <a href="#compact-full">Authoring Styles </a><br>5. <a href="#modeling-guidelines">Guidelines for Modeling New Assertions</a><br> 5.1 <a href="#new-domains">New Policy Domains</a><br> 5.2 <a href="single-domains">Single Domains</a><br> 5.3 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 5.3.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 5.3.2 <a href="#nested-assertions">Nested Assertions</a><br> 5.3.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 5.4 <a href="#self-describing"> Self Describing Messages </a><br> 5.5 <a href="#optional-policy-assertion">Policy Assertions Designating Optional Behaviors</a><br> 5.6 <a href="#considerations-for-intersection"> Considerations for Intersection and Merging </a><br> 5.7 <a href="#typing-assertions">Typing Assertions</a><br> 5.8 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL</a><br> 5.9 <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.9.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.9.2 <a href="#extending-assertions"> Factors in Extending Assertions within a Domain </a><br> 5.9.3 <a href="#assertion-evolution">Evolution of Assertions (Versioning and Compatibility)</a><br>6. <a href="#inter-policy">Inter-domain Policy and Composition Issues</a><br>7. <a href="#best-practices-attachment">Applying Best Practices for Policy Attachment</a><br> 7.1 <a href="#context-free-policies">Appropriate Attachment: Preserving Context-Free Policies</a><br> 7.2 <a href="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interacion">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenerio">Scenario and a worked example</a><br></p>
<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#security-considerations">Security Considerations</a><br>B. <a href="#xml-namespaces">XML Namespaces</a><br>C. <a href="#references">References</a><br>D. <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br>E. <a href="#change-description">Changes in this Version of
the Document</a> (Non-Normative)<br>F. <a href="#change-log">Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log</a> (Non-Normative)<br></p></div><hr><div class="body"><div class="div1">
<h2><a name="introduction"></a>1. Introduction</h2><p>WS-Policy specification defines a policy to be a collection
@@ -572,17 +572,17 @@
behavior that is expressed by a policy assertion. This approach
can be considered when messages can not be self describing.
</p></div><div class="div2">
-<h3><a name="optional-policy-assertion"></a>5.5 Optional Policy Assertion</h3><p>Optional assertions represent behaviors which may be
- engaged by a consumer. When using the compact authoring form
- for assertions, behaviors are marked by using
- <code>wsp:optional</code> attribute that has a value,
+<h3><a name="optional-policy-assertion"></a>5.5 Policy Assertions Designating Optional Behaviors</h3><p>Optional behaviors represent
+ behaviors which may be engaged by a consumer. When using the
+ compact authoring form for assertions, behaviors are marked by
+ using <code>wsp:optional</code> attribute that has a value,
"true". During the process of normalization, the runtime
- behavior is indicated by two policy alternatives, one with
- and one without containing the assertion. In a
- consumer/provider scenario, the choice of engaging the runtime
- behavior is upon the consumer although the provider is
- capable of engaging the runtime behavior.
- </p><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
+ behavior is indicated by two policy alternatives, one with and
+ one without containing the assertion. In a consumer/provider
+ scenario, the choice of engaging the runtime behavior is upon
+ the consumer although the provider is capable of engaging the
+ runtime behavior. In order to simplify reference to such
+ assertions, we just use the term optional assertions in this section. </p><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> document contains an
example that proposes the use of <cite><a href="#MTOM">MTOM</a></cite> as an
optional behavior that can be engaged by a consumer. The
primer proposes that an assertion that identifies the use of
@@ -602,7 +602,7 @@
the provider can determine whether the policy alternate that
contains the MTOM assertion is being selected.</p><p>Assertion authors should be aware that optional behaviors,
like utilizing optional support for Optimized MIME
- Serialization require some care. </p><ul><li><p>Since optional behaviors indicate optionality for
+ Serialization require some care considering the scoping of the assertion that is applicable. </p><ul><li><p>Since optional behaviors indicate optionality for
both the provider and the consumer, behaviors that must
always be engaged by a consumer must not be marked as
"optional" with a value "true" since presence of two
@@ -610,45 +610,61 @@
choose the alternative that does not contain the assertion,
and thus making the behavior not being engaged in an
interaction.
- </p></li><li><p>As demonstrated in the MIME optimization behavior,
- behaviors must be engaged with respect to messages that are
- targeted to the provider so that the provider can determine
- that the optional behavior is engaged. In other words, the
- requirement of self describing nature of messages in order
- to engage behaviors must not be forgotten with regard to
- the client's ability to detect and select the alternative if
- it is to participate in the exchange. It is recommended that
- authors not utilize optional assertions for outbound
- messages unless there is explicit, out of band mechanism
- (currently such a mechanism is outside the scope of
- WS-Policy Framework) that a client can use to indicate that
- the optional capability must be engaged. </p></li><li><p>When optional behaviors are attached with only
+ </p></li><li><p>As demonstrated in
+ the MIME optimization behavior, behaviors must be engaged
+ with respect to messages that are targeted to the provider
+ so that the provider can determine that the optional
+ behavior is engaged. In other words, the requirement of self
+ describing nature of messages [<a href="#self-describing"><b>5.4 Self Describing Messages </b></a>] in order to engage behaviors must
+ not be forgotten with regard to the client's ability to
+ detect and select the alternative if it is to participate in
+ the exchange. </p></li><li><p> The target scope
+ of an optional assertion is an important factor for
+ assertion authors to consider as it determines the
+ <em>granularity</em> where the behavior is optionally
+ engaged. For example, if the assertion is targeted for an
+ endpoint policy subject, it is expected to govern all the
+ messages that are indicated by the specific endpoint when
+ optional behavior is <em> engaged </em>. Since the
+ behavior would be applicable to policy subject that is
+ designated, it is important for the policy assertion authors
+ to choose the appropriate level of granularity for optional
+ behaviors, to consider whether a specific message or all
+ messages, etc. are targeted. </p><ul><li><p> Attaching optional
+ assertions to outbound-messages using message policy subject
+ require some care. An explicit, out of band mechanism may be
+ necessary to enable a client to indicate that
+ the optional behavior is engaged. Currently such a mechanism
+ is outside the scope of WS-Policy Framework. </p></li><li><p>When optional
+ behaviors are indicated by attaching assertions with only
one side of an interaction, such as an inbound message of
a request-response, the engagement of the rest of the
- interaction will be undefined. For example, if a
- request-response interaction only specified MTOM
+ interaction will be <em>undefined</em>. For example,
+ if a request-response interaction only specified MTOM
optimization for an inbound message, it would not be clear
whether the outbound message from the provider could also
- utilize the behavior. Therefore, the assertion authors
- are encouraged to consider how the attachment on a message
+ utilize the behavior. Therefore, the assertion authors are
+ encouraged to consider how the attachment on a message
policy subject on a response message should be treated
when optional behaviors are specified for message
- exchanges within a request response for response
- messages. Leaving the semantics undescribed may result in
- providers making assumptions (i.e. if the incoming message
- utilized the optimization, the response will be returned
- utilizing the MTOM serialization). Similarly, if
- engagement of a behavior is only specified for an
- outbound message, it may be necessary to describe the
+ exchanges within a request response for response messages,
+ using message policy subject. Leaving the semantics
+ undescribed may result in providers making assumptions
+ (i.e. if the incoming message utilized the optimization,
+ the response will be returned utilizing the MTOM
+ serialization). Similarly, if engagement of a behavior is
+ only specified for an outbound message, the policy
+ assertion authors should consider to describe the
semantics if the incoming messages also utilized the
- behavior. <cite><a href="#WS-RM">Web Services Reliable Messaging</a></cite> Policy currently allows
- the incoming messages to utilize WS-RM protocol (see
- <cite><a href="#WS-RM">Web Services Reliable Messaging</a></cite>) to be engaged although the
- assertion may only appear on an outbound message in a
- request response. </p></li><li><p>Optional assertion authors should explicitly state
- how the capability that is enabled by the assertion would be
+ behavior. This is especially important if the assertion is
+ applicable to more than one specific policy subject. One
+ approach that is currently taken by WS-RM Policy <cite><a href="#WS-RM">Web Services Reliable Messaging</a></cite> is to introduce both message and endpoint
+ policy subjects for one of its assertions and require the
+ use of endpoint policy subject when message level subject
+ is used via attachment. </p></li></ul></li><li><p>Optional assertion authors should explicitly state
+ how the behavior that is enabled by the assertion would be
engaged when they are designing their assertion, whether by
- specific headers or some other means. </p></li></ul></div><div class="div2">
+ specific headers or some other means. See also <a href="#self-describing"><b>5.4 Self Describing Messages </b></a>.</p></li></ul></div><div class="div2">
<h3><a name="considerations-for-intersection"></a>5.6 Considerations for Intersection and Merging </h3></div><div class="div2">
<h3><a name="typing-assertions"></a>5.7 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
identifying a policy assertion, assertion authors should be
@@ -1167,4 +1183,4 @@
</p></div><div class="div1">
<h2><a name="change-description"></a>E. Changes in this Version of
the Document (Non-Normative)</h2><p>A list of substantive changes since the previous publication is below:</p><ul><li><p>TBD</p></li></ul></div><div class="div1">
-<h2><a name="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td rowspan="1" colspan="1">20061030</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspa="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Fixes for Frederick's editorial comments (20061025)</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
+<h2><a name="change-log"></a>F. Web Services Policy 1.5 - Guidelines for Policy Assertion Authors Change Log (Non-Normative)</h2><a name="ws-policy-primer-changelog-table"></a><table border="1"><tbody><tr><th rowspan="1" colspan="1">Date</th><th rowspan="1" colspan="1">Author</th><th rowspan="1" colspan="1">Description</th></tr><tr><td rowspan="1" colspan="1">20060829</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Created first draft based on agreed outline and content</td></tr><tr><td rowspan="1" colspan="1">20061013</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Editorial fixes (suggested by Frederick), fixed references, bibl items, fixed dangling pointers, created eds to do</td></tr><tr><td rowspan="1" colspan="1">20061018</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial fixes for readability, added example for Encrypted parts</td></tr><tr><td rowspan="1" colspan="1">20061030</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspa="1">Fixes for Paul Cotton's editorial comments (20061020)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Fixes for Frederick's editorial comments (20061025)</td></tr><tr><td rowspan="1" colspan="1">20061031</td><td rowspan="1" colspan="1">UY</td><td rowspan="1" colspan="1">Optionality discussion feedback integration</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Wednesday, 1 November 2006 02:46:27 UTC