- From: Maryann Hondo via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 21 Sep 2007 22:05:28 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv5801
Modified Files:
ws-policy-guidelines.html
Log Message:
Implemented the changes proposed by Editors' action 358 issue 5044- attachment best practices
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -d -r1.103 -r1.104
--- ws-policy-guidelines.html 13 Sep 2007 21:06:27 -0000 1.103
+++ ws-policy-guidelines.html 21 Sep 2007 22:05:26 -0000 1.104
@@ -125,13 +125,14 @@
5.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br>
5.4.2 <a href="#nested-assertions">Nested Assertions</a><br>
5.5 <a href="#Ignorable">Designating Ignorable Behavior</a><br>
- 5.5.1 <a href="#d3e812">Ignorable behavior in authoring</a><br>
- 5.5.2 <a href="#d3e825">Ignorable behavior at runtime</a><br>
+ 5.5.1 <a href="#d3e822">Ignorable behavior in authoring</a><br>
+ 5.5.2 <a href="#d3e835">Ignorable behavior at runtime</a><br>
5.6 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br>
- 5.6.1 <a href="#d3e840">Optional behavior at runtime</a><br>
+ 5.6.1 <a href="#d3e850">Optional behavior at runtime</a><br>
5.7 <a href="#levels-of-abstraction">Considerations for Policy Attachment</a><br>
5.7.1 <a href="#general-attachment-guidelines">General Guidelines</a><br>
5.7.2 <a href="#wsdl-attachment-guidelines">Considerations for Policy Attachment in WSDL</a><br>
+ 5.7.3 <a href="#UDDI-attachment-guidelines">Considerations for Policy Attachment in UDDI</a><br>
5.8 <a href="#interrelated-domains">Interrelated domains</a><br>
6. <a href="#versioning-policy-assertions">Versioning Policy Assertions</a><br>
6.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br>
@@ -194,9 +195,9 @@
<h2><a name="best-practices-list" id="best-practices-list"></a>2. List of Best Practice Statements</h2><p>The following Best Practices appear in this document with discussion and examples, and are summarized here for quick reference:</p><ul><li><p><a href="#bp-assertion-semantics"><b>1. Semantics Independent of
Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-compatibility-tests"><b>2. Define assertions relevant to compatibility tests</b></a></p></li><li><p><a href="#bp-ignorable-for-not-related-to-compatibility-tests"><b>3. Mark Ignorable Assertions not related to compatibility</b></a></p></li><li><p><a href="#bp-semantics-and-form"><b>4. Semantics Independent of the Form</b></a></p></li><li><p><a href="#bp-assertion-start"><b>5. Start with a Simple Assertion</b></a></p></li><li><p><a href="#bp-unique-qnames"><b>6. Use Unique QNames</b></a></p></li><li><p><a href="#XMLOutline"><b>7. Provide an XML definition</b></a></p></li><li><p><a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a></p></li><li><p><a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a></p></li><li><p><a href="#ignorableAssertions"><b>10. Document Use of the Ignorable
Attribute in XML </b></a></p></li><li><p><a href="#bp-assertion-xml-allow-optional"><b>11. Assertion Authors should allow use of wsp:Optional</b></a></p></li><li><p><a href="#bp-not-necessary-to-understand-a-message"><b>12. Define message format only</b></a></p></li><li><p><a href="#bp-assertion-duplication"><b>13. Avoid Duplication of Assertions</b></a></p></li><li><p><a href="#bp-assertion-parameters"><b>14. Use Parameters for Useful
- Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms"><b>21. Leverage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>22. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>23. Identiy Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>24. Specify WSDL Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>25. Choose the Most Granular WSDL Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>26. Define Rules for Attachment of an Assertion
- type to Multiple WSDL policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>27. Specify Preferred WSDL Attachment Point</b></a></p></li><li><p><a href="#bp-WSDL-policy-multiple-instance-semantics"><b>28. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>30. Independent Assertions for Different Versions of a
- Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>31. Document changes to policy
+ Information</b></a></p></li><li><p><a href="#bp-dependent-behaviors"><b>15. Use Nested Assertions for Dependent Behaviors</b></a></p></li><li><p><a href="#bp-declare-nested-assertions"><b>16. Enumerate Nested Assertions</b></a></p></li><li><p><a href="#bp-discourage-domain-specific-intersection"><b>17. Discourage Domain Specific Intersection</b></a></p></li><li><p><a href="#bp-limit-optional-assertions"><b>18. Limit use of Optional Assertions</b></a></p></li><li><p><a href="#bp-entire-mep-for-optional"><b>19. Consider entire message exchange pattern when specifying Assertions that may be optional</b></a></p></li><li><p><a href="#bp-indicate-optional-assertion-use"><b>20. Indicate use of an Optional Assertion</b></a></p></li><li><p><a href="#bp-reusableAssertions"><b>21. Reusable Assertions</b></a></p></li><li><p><a href="#bp-semantics-multiple-same-type"><b>22. Describe Semantics of Multiple Assertions of Same Type</b></a></p></li><li><p><a href="#bp-leverage-defined-attachment-mechanisms"><b>23. Levrage Defined Attachment Mechanisms</b></a></p></li><li><p><a href="#bp-use-defined-policy-subjects"><b>24. Use Defined Policy Subjects</b></a></p></li><li><p><a href="#bp-identify-policy-subjects"><b>25. Identify Policy Subjects</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL Policy Subject(s)</b></a></p></li><li><p><a href="#bp-WSDL-consider-scope"><b>27. Consider Scope of Attachment Points</b></a></p></li><li><p><a href="#bp-WSDL-policy-subject-Granularity"><b>28. Choose the Most Granular WSDL Policy Subject</b></a></p></li><li><p><a href="#bp-WSDL-multiple-policy-subjects"><b>29. Define Rules for Attachment of an Assertion
+ type to Multiple WSDL policy subjects</b></a></p></li><li><p><a href="#bp-WSDL-preferred-attachment-point"><b>30. Specify Preferred WSDL Attachment Point</b></a></p></li><li><p><a href="#bp-UDDI-tmodels"><b>31. Use defined tModels when appropriate</b></a></p></li><li><p><a href="#bp-specify-composition"><b>32. Specify Composition with Related Assertions</b></a></p></li><li><p><a href="#bp-independent-assertions"><b>33. Independent Assertions for Different Versions of a
+ Behavior</b></a></p></li><li><p><a href="#bp-policy-subject-change"><b>34. Document changes to policy
subject</b></a></p></li></ul></div><div class="div1">
<h2><a name="Assertions" id="Assertions"></a>3. What is an Assertion? </h2><p>An assertion is a piece of metadata that describes a
capability related to a specific WS-Policy domain. Sets of domain-specific assertions
@@ -383,10 +384,10 @@
<ul><li><p>The definition of the assertion's semantic
(See best practice <a href="#AssertionDefinitions"><b>8. Specify Semantics Clearly</b></a>).</p></li><li><p>The specification of the set of valid policy subjects to which an
assertion may be attached
- (See best practice <a href="#bp-WSDL-policy-subject"><b>24. Specify WSDL Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy
+ (See best practice <a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL Policy Subject(s)</b></a>).</p></li><li><p>The scope of the assertion in the context of a particular policy
subject (See best practices in Section <a href="#levels-of-abstraction"><b>5.7 Considerations for Policy Attachment</b></a>).</p></li><li><p>Any composition considerations if the assertion is used with
other assertions in a context
- (See best practice <a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a>).</p></li></ul>
+ (See best practice <a href="#bp-specify-composition"><b>32. Specify Composition with Related Assertions</b></a>).</p></li></ul>
</p><p>
The WS-Policy Attachment specification defines a number of different
policy subjects to which an assertion can be attached. For attaching to
@@ -851,16 +852,16 @@
certificate will not be able to use this provider solely on the basis
of intersection algorithm alone.</p></div></div><div class="div2">
<h3><a name="Ignorable" id="Ignorable"></a>5.5 Designating Ignorable Behavior</h3><div class="div3">
-<h4><a name="d3e812" id="d3e812"></a>5.5.1 Ignorable behavior in authoring</h4><p>
+<h4><a name="d3e822" id="d3e822"></a>5.5.1 Ignorable behavior in authoring</h4><p>
The Policy Framework provides an intersection algorithm that has two defined modes for processing (lax and strict). The Framework also defines an attribute (wsp:Ignorable) that can be used to influence whether assertions are part of the compatibility assessment between two alternatives. [see <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> and <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>]. Assertion authors should consider whether the behavior represented by the Assertion they are defining can be safely ignored for the purposes of intersection, and should follow <a href="#DefineIgnorable"><b>9. Document Ignorable Behavior</b></a> and <a href="#ignorableAssertions"><b>10. Document Use of the Ignorable
Attribute in XML </b></a> to include this guidance in the assertion's definition.</p></div><div class="div3">
-<h4><a name="d3e825" id="d3e825"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
+<h4><a name="d3e835" id="d3e835"></a>5.5.2 Ignorable behavior at runtime</h4><p>Regardless of whether the assertion allows the ignorable attribute, assertion authors should
indicate the semantic of the runtime behavior in the description of the assertion.
</p><p>
As said in <a href="ws-policy-primer.html#strict-lax-policy-intersection">section 3.4.1 Strict and Lax Policy Intersection</a> in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>, "Regardless of the chosen intersection mode, ignorable assertions do not express any wire-level requirements on the behavior of consumers - in other words, a consumer could choose to ignore any such assertions that end up in the resulting policy after intersection, with no adverse effects on runtime interactions." Therefore, any assertion that is marked with ignorable should not impose any wire-level requirements on the part of consumers. Assertion Authors are reminded that regardless of whether an assertion is marked as ignorable, policy consumers using strict intersection will not 'ignore' the assertion.
</p></div></div><div class="div2">
<h3><a name="optional-policy-assertion" id="optional-policy-assertion"></a>5.6 Designating Optional Behaviors</h3><div class="div3">
-<h4><a name="d3e840" id="d3e840"></a>5.6.1 Optional behavior at runtime</h4><p>Since optional behaviors indicate optionality for
+<h4><a name="d3e850" id="d3e850"></a>5.6.1 Optional behavior at runtime</h4><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 this would allow the
@@ -946,34 +947,52 @@
communicate the policy assertions should not affect or imply additional
semantics in the interpretation of Policy alternatives. If it did, each
policy assertion would need to be written with different (and possibly
- unknown) attachment mechanisms in mind.
- </p><div class="boxedtext"><p><a name="bp-leverage-defined-attachment-mechanisms" id="bp-leverage-defined-attachment-mechanisms"></a><span class="practicelab">Best
-Practice 21: Leverage Defined Attachment Mechanisms</span></p><p class="practice">
- Assertion Authors should leverage defined attachment mechanisms when
- possible to extend the deployment of their policy assertions and ensure
- that there are no additional semantics implied by their
- assertions.</p></div><p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments
- specification when possible. </p><div class="boxedtext"><p><a name="bp-use-defined-policy-subjects" id="bp-use-defined-policy-subjects"></a><span class="practicelab">Best
-Practice 22: Use Defined Policy Subjects</span></p><p class="practice"> Assertion
- Authors should leverage defined policy subjects when possible to
+ unknown) attachment mechanisms in mind. Since multiple attachment mechanisms
+ may be used, a policy alternative created during the process of calculating
+ an effective policy can contain multiple instances of the same policy
+ assertion type ( i.e., the SignedParts assertion). It is therefore also
+ important for the policy authors to define what it means if multiple
+ assertions are present.
+ </p><div class="boxedtext"><p><a name="bp-reusableAssertions" id="bp-reusableAssertions"></a><span class="practicelab">Best
+Practice 21: Reusable Assertions</span></p><p class="practice">
+ Assertion Authors are encouraged to create policy assertions that
+ can be used regardless of attachment mechanism.</p></div><p>For example, a security policy expression can be assigned a key reference and
+ be attached to a UDDI binding or can be embedded in a WSDL document. </p><div class="boxedtext"><p><a name="bp-semantics-multiple-same-type" id="bp-semantics-multiple-same-type"></a><span class="practicelab">Best
+Practice 22: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">
+ Assertion Authors should specify the semantics of multiple instances
+ of the same policy assertion type in the same policy alternative and the
+ semantics of parameters and nested policy (if any) when there are
+ multiple instances of a policy assertion type in the same policy
+ alternative regardless of the mechanism used to attach them to
+ a policy subject. If there are multiple instances of a policy
+ assertion type in the same policy alternative without parameters
+ and nested policies, these have the same meaning as a single
+ assertion of the type within the policy alternative.</p></div><p> Assertion authors should review sections 3.2 and 4.5 of the Policy Framework
+ <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> for more detail
+ on the processing for multiple assertions of the same type.</p><div class="boxedtext"><p><a name="bp-leverage-defined-attachment-mechanisms" id="bp-leverage-defined-attachment-mechanisms"></a><span class="practicelab">Best
+Practice 23: Leverage Defined Attachment Mechanisms</span></p><p class="practice">
+ Assertion Authors should leverage defined attachment models when
+ possible to document the use of the policy assertions they author and ensure
+ that there are no additional semantics implied by the defined
+ attachment models for their assertions.</p></div><div class="boxedtext"><p><a name="bp-use-defined-policy-subjects" id="bp-use-defined-policy-subjects"></a><span class="practicelab">Best
+Practice 24: Use Defined Policy Subjects</span></p><p class="practice"> Assertion
+ Assertion Authors should leverage defined policy subjects when possible to
facilitate the deployment of their policy assertions. Common Policy
subjects have been defined and used by other policy assertion authors
and new policy assertions that leverage these existing subjects will be
- easier to define and group. </p></div><p>
+ easier to define and group. </p></div><div class="boxedtext"><p><a name="bp-identify-policy-subjects" id="bp-identify-policy-subjects"></a><span class="practicelab">Best
+Practice 25: Identify Policy Subjects</span></p><p class="practice">
Policy assertion authors
should unambiguously identify the appropriate policy subjects for their
assertions. If the best practices are followed, and the assertions are
scoped according to their subject, then multiple policy domains may be
combined without conflict. Each domain should define any limitations at
- the policy subject level that might impact interoperability.
- </p><div class="boxedtext"><p><a name="bp-identify-policy-subjects" id="bp-identify-policy-subjects"></a><span class="practicelab">Best
-Practice 23: Identify Policy Subjects</span></p><p class="practice">
- Assertion
- Authors should review the policy subjects defined in
- Web Services Policy 1.5 - Attachment and identify existing policy subjects when possible
- to facilitate the deployment of their policy assertions and include this
- information in the definition of the assertions.</p></div><p>
- An example of this is
+ the policy subject level that might impact interoperability.</p></div><p>
+ Assertion Authors should review the policy subjects defined in WS-PolicyAttachments
+ and identify which of the existing policy subjects can be used with the assertions
+ they define. That identification will facilitate the deployment of their policy
+ assertions and include such information in the assertion definition.
+ </p><p> An example of this practice is
the Reliable Messaging Policy Assertion document [<cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy Assertion</a></cite>]. In the Sequence STR Assertion (section
2.5.1) the Reliable Messaging Policy Assertion authors state that "The
STR assertion defines the requirement that an RM Sequence MUST be bound
@@ -999,23 +1018,24 @@
made using an endpoint then the subject is the endpoint policy subject. </p></li><li><p>If the behavior applies to any message exchange
defined by an operation then the subject is the operation policy subject. </p></li><li><p>If the behavior applies to an input message then
the subject is the message policy subject - similarly for output and fault message WSDL policy subjects.</p></li></ul><div class="boxedtext"><p><a name="bp-WSDL-policy-subject" id="bp-WSDL-policy-subject"></a><span class="practicelab">Best
-Practice 24: Specify WSDL Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant WSDL policy subjects with which
+Practice 26: Specify WSDL Policy Subject(s)</span></p><p class="practice">Assertion Authors should specify the set of relevant WSDL policy subjects with which
the assertion may be associated. For instance, if a policy assertion is to be used with
- WSDL, the assertion description should specify a WSDL policy subject - such as service,
- endpoint, operation and message.
- </p></div><p>Assertion Authors that wish to utilize WSDL policy subjects need to
+ a WSDL policy subject - such as service, endpoint, operation and message it should be stated.
+ </p></div><p>Assertion Authors that utilize WSDL policy subjects need to
understand how the assertions will be
- processed in an intersection and merging, and the implications of
- the processing for considering a specific attachment point and
- policy subject. This topic is considered in detail in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
+ processed in intersection and merging, and the specific implications of
+ the processing for a specific attachment point and policy subject.
+ This topic is considered in detail in <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
</p><p> For a given WSDL policy subject, there may be several
attachment points. For example, there are three attachment
points for the endpoint policy subject: the port, binding and
portType element. Assertion Authors should identify the
- relevant attachment point when defining a new assertion. To
- determine the relevant attachment points, Assertion Authors should
- consider the scope of the attachment point. For example, an
- assertion should only be allowed in the portType element if
+ relevant attachment point when defining a new assertion.
+ </p><div class="boxedtext"><p><a name="bp-WSDL-consider-scope" id="bp-WSDL-consider-scope"></a><span class="practicelab">Best
+Practice 27: Consider Scope of Attachment Points</span></p><p class="practice">To determine the relevant attachment points, Assertion Authors should
+ consider the scope of the attachment point.
+ </p></div><p>
+ For example, an assertion should only be allowed in the portType element if
the assertion reasonably applies to any endpoint that ever
references that portType. Most of the known policy assertions
are designed for the endpoint, operation or message policy subject.
@@ -1032,7 +1052,7 @@
policy attachments to WSDL policy subjects of broader scope and granularity
should be done only after careful evaluation.
</p><div class="boxedtext"><p><a name="bp-WSDL-policy-subject-Granularity" id="bp-WSDL-policy-subject-Granularity"></a><span class="practicelab">Best
-Practice 25: Choose the Most Granular WSDL Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular WSDL policy subject
+Practice 28: Choose the Most Granular WSDL Policy Subject</span></p><p class="practice">Assertion Authors should choose the most granular WSDL policy subject
to which the behavior represented by a policy assertion applies.
</p></div><p>
For authoring convenience, Assertion Authors may allow the
@@ -1043,7 +1063,7 @@
when multiple instances of the same assertion are attached to different
WSDL policy subjects in order to avoid non-interoperable behavior.
</p><div class="boxedtext"><p><a name="bp-WSDL-multiple-policy-subjects" id="bp-WSDL-multiple-policy-subjects"></a><span class="practicelab">Best
-Practice 26: Define Rules for Attachment of an Assertion
+Practice 29: Define Rules for Attachment of an Assertion
type to Multiple WSDL policy subjects</span></p><p class="practice">If an assertion is allowed to be associated with multiple WSDL policy subjects,
the assertion author should describe the rules for multiple
instances of the same assertion attached to multiple WSDL policy subjects in
@@ -1071,13 +1091,13 @@
when the policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
</p><div class="boxedtext"><p><a name="bp-WSDL-preferred-attachment-point" id="bp-WSDL-preferred-attachment-point"></a><span class="practicelab">Best
-Practice 27: Specify Preferred WSDL Attachment Point</span></p><p class="practice">If an assertion can be attached at multiple attachment points
+Practice 30: Specify Preferred WSDL Attachment Point</span></p><p class="practice">If an assertion can be attached at multiple attachment points
within a policy subject, Assertion Authors should specify a
preferred attachment point for the chosen policy subject.
</p></div><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,
+ the specific implications of a result where multiple assertions of
+ the assertion type are 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,
@@ -1089,20 +1109,31 @@
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><div class="boxedtext"><p><a name="bp-WSDL-policy-multiple-instance-semantics" id="bp-WSDL-policy-multiple-instance-semantics"></a><span class="practicelab">Best
-Practice 28: Describe Semantics of Multiple Assertions of Same Type</span></p><p class="practice">A policy alternative can contain multiple instances of the same
- policy assertion type. Assertion authors should specify the semantics of
- multiple instances of same policy assertion type in the same policy
- alternative and the semantics of parameters and nested policy (if any)
- when there are multiple instances of a policy assertion type in the same
- policy alternative.
- </p></div></div></div><div class="div2">
+ </p></div><div class="div3">
+<h4><a name="UDDI-attachment-guidelines" id="UDDI-attachment-guidelines"></a>5.7.3 Considerations for Policy Attachment in UDDI</h4><p>In general, UDDI protocol messages can be used to save TModel, businessEntity,
+ businessService and bindingTemplate definitions with policies attached. These
+ definitions can also be the target of a "find" protocol message, thus allowing
+ authors to store and retrieve policy assertions. There are two ways to associate
+ policy expressions with UDDI definitions: direct referece, and registering policy
+ as a UDDI TModel. Assertion Authors defining new assertions should consider each
+ approach.
+ </p><div class="boxedtext"><p><a name="bp-UDDI-tmodels" id="bp-UDDI-tmodels"></a><span class="practicelab">Best
+Practice 31: Use defined tModels when appropriate</span></p><p class="practice">UDDI defines the following policy subjects: Service Provider Policy,
+ Service Policy subject and Endpoint Policy subject.
+ </p></div><p>
+ When defining assertions and recommending a service provider policy
+ subject [uddi:BusinessEntity], or a service policy subject [uddi:buisnessService],
+ assertion authors are scoping the behaviors to the service
+ provider as a whole. When defining assertions and recommending an endpoint
+ policy subject [uddi:bindingTemplate, uddi:tModel], assertion authors
+ are scoping behaviors to a deployed endpoint.
+ </p></div></div><div class="div2">
<h3><a name="interrelated-domains" id="interrelated-domains"></a>5.8 Interrelated domains</h3><p>Assertion Authors need to be clear about how assertions defined in
their domain may fit with assertions for interrelated domains. Assertion Authors should not duplicate existing
assertions and should also make sure that when adding assertions those new assertions are consistent
with pre-existing assertions of any
interrelated domain. </p><div class="boxedtext"><p><a name="bp-specify-composition" id="bp-specify-composition"></a><span class="practicelab">Best
-Practice 29: Specify Composition with Related Assertions</span></p><p class="practice">Assertion authors should clearly specify how an assertion
+Practice 32: Specify Composition with Related Assertions</span></p><p class="practice">Assertion authors should clearly specify how an assertion
may compose with other related assertions, if any.</p></div><p> A
classic example of such an interrelated domain is security, because
security tends to
@@ -1145,7 +1176,7 @@
[<cite><a href="#WS-Addressing">WS-Addressing Core</a></cite>]. These equivalent behaviors
are mutually exclusive for an interaction. Such equivalent
behaviors can be modeled as independent assertions. </p><div class="boxedtext"><p><a name="bp-independent-assertions" id="bp-independent-assertions"></a><span class="practicelab">Best
-Practice 30: Independent Assertions for Different Versions of a
+Practice 33: Independent Assertions for Different Versions of a
Behavior</span></p><p class="practice">Assertion Authors should use independent assertions for modeling different
versions of a behavior.</p></div><p>The
policy expression in the example below requires the use of
@@ -1159,7 +1190,7 @@
<sp:Wss11>…</sp:Wss11>
</Policy></pre></div></div></div><div class="div2">
<h3><a name="supporting-new-policy-subjects" id="supporting-new-policy-subjects"></a>6.3 Supporting New Policy Subjects</h3><p>
- The best practice <a href="#bp-WSDL-policy-subject"><b>24. Specify WSDL Policy Subject(s)</b></a> specifies that policy authors should
+ The best practice <a href="#bp-WSDL-policy-subject"><b>26. Specify WSDL Policy Subject(s)</b></a> specifies that policy authors should
define the set of policy subjects to which policy assertions can be
attached. Over time, new policy subjects may need to be defined. When
this occurs, policy Assertion Authors may update the list of policy
@@ -1175,7 +1206,7 @@
new policy subjects are added it is incumbent on the authors to retain the
semantic of the policy assertion.
</p><div class="boxedtext"><p><a name="bp-policy-subject-change" id="bp-policy-subject-change"></a><span class="practicelab">Best
-Practice 31: Document changes to policy
+Practice 34: Document changes to policy
subject</span></p><p class="practice">If the policy subjects change over time,
the assertion description should also be versioned to reflect this
change.</p></div></div></div></div><div class="back"><div class="div1">
@@ -1524,7 +1555,7 @@
are reflected.
</td></tr><tr><td rowspan="1" colspan="1">20070518</td><td rowspan="1" colspan="1">PY</td><td rowspan="1" colspan="1">Updated Appendix E, Changes in this Version of the Document
(<a href="#change-description"><b>E. Changes in this Version of the Document</b></a>).
- </td></tr><tr><td rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-specify-composition"><b>29. Specify Composition with Related Assertions</b></a> (from
+ </td></tr><tr><td rowspan="1" colspan="1">20070520</td><td rowspan="1" colspan="1">ASV</td><td rowspan="1" colspan="1">Added Best Practice <a href="#bp-specify-composition"><b>32. Specify Composition with Related Assertions</b></a> (from
the <a href="http://lists.w3.org/Archives/Public/public-ws-policy/2007Mar/att-0069/good-practices-4-assertion-authors-03-05-2007.pdf">IBM
and MS Contribution</a> to
<a href="#interrelated-domains"><b>5.8 Interrelated domains</b></a>. Added an ed note that
@@ -1652,4 +1683,7 @@
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/353">353</a>
with the caveats and clarifications expressed in message
<a href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2007Sep/0002.html">2007Sep-0002</a>.
+ </td></tr><tr><td rowspan="1" colspan="1">20070921</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Implemented the resolution for issue
+ <a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5044">5044</a>. Editors' action
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/358">358</a>.
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Friday, 21 September 2007 22:05:58 UTC