- From: Maryann Hondo via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 21 Sep 2007 22:04:18 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv5397
Modified Files:
ws-policy-guidelines.xml
Log Message:
Implemented the changes proposed by Editors' action 358 issue 5044- attachment best practices
Index: ws-policy-guidelines.xml
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.xml,v
retrieving revision 1.118
retrieving revision 1.119
diff -u -d -r1.118 -r1.119
--- ws-policy-guidelines.xml 13 Sep 2007 21:06:27 -0000 1.118
+++ ws-policy-guidelines.xml 21 Sep 2007 22:04:16 -0000 1.119
@@ -1232,42 +1232,71 @@
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.
+ 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>
+ <p role="practice" id="bp-reusableAssertions">
+ <quote>Reusable Assertions</quote><quote>
+ Assertion Authors are encouraged to create policy assertions that
+ can be used regardless of attachment mechanism.</quote> </p>
+
+ <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>
+
+ <p role="practice" id="bp-semantics-multiple-same-type">
+ <quote>Describe Semantics of Multiple Assertions of Same Type</quote><quote>
+ 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.</quote> </p>
+
+ <p> Assertion authors should review sections 3.2 and 4.5 of the Policy Framework
+ <bibref ref="WS-Policy"/> for more detail
+ on the processing for multiple assertions of the same type.</p>
+
<p role="practice" id="bp-leverage-defined-attachment-mechanisms">
<quote>Leverage Defined Attachment Mechanisms</quote><quote>
- 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.</quote> </p>
- <p>Assertion authors are also encouraged to use the policy subjects defined by the policy attachments
- specification when possible. </p>
+ 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.</quote> </p>
+
<p role="practice" id="bp-use-defined-policy-subjects">
<quote>Use Defined Policy Subjects</quote><quote> Assertion
- Authors should leverage defined policy subjects when possible to
+ 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. </quote> </p>
- <p>
+
+
+ <p role="practice" id="bp-identify-policy-subjects">
+ <quote>Identify Policy Subjects</quote><quote>
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>
- <p role="practice" id="bp-identify-policy-subjects">
- <quote>Identify Policy Subjects</quote><quote>
- 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.</quote> </p>
+ the policy subject level that might impact interoperability.</quote> </p>
<p>
- An example of this is
+ 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 [<bibref
ref="WS-RM-Policy "/>]. In the Sequence STR Assertion (section
2.5.1) the Reliable Messaging Policy Assertion authors state that "The
@@ -1284,6 +1313,7 @@
authors.
</p>
</div3>
+
<div3 id="wsdl-attachment-guidelines">
<head>Considerations for Policy Attachment in WSDL</head>
<p>A behavior identified by a policy assertion applies to the
@@ -1318,26 +1348,32 @@
<quote>Specify WSDL Policy Subject(s)</quote>
<quote>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.
+ a WSDL policy subject - such as service, endpoint, operation and message it should be stated.
</quote>
</p>
-
- <p>Assertion Authors that wish to utilize WSDL policy subjects need to
+
+ <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 <bibref ref="WS-Policy-Primer"/>
+ 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 <bibref ref="WS-Policy-Primer"/>
</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>
+
+ <p role="practice" id="bp-WSDL-consider-scope">
+ <quote>Consider Scope of Attachment Points</quote>
+ <quote>To determine the relevant attachment points, Assertion Authors should
+ consider the scope of the attachment point.
+ </quote>
+ </p>
+ <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.
@@ -1427,8 +1463,8 @@
<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,
@@ -1442,17 +1478,33 @@
assertion enable processing of the multiple occurrences properly.
</p>
- <p role="practice" id="bp-WSDL-policy-multiple-instance-semantics">
- <quote>Describe Semantics of Multiple Assertions of Same Type</quote>
- <quote>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.
+ </div3>
+ <div3 id="UDDI-attachment-guidelines">
+ <head>Considerations for Policy Attachment in UDDI</head>
+ <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>
+
+ <p role="practice" id="bp-UDDI-tmodels">
+ <quote>Use defined tModels when appropriate</quote>
+ <quote>UDDI defines the following policy subjects: Service Provider Policy,
+ Service Policy subject and Endpoint Policy subject.
</quote>
</p>
- </div3>
+ <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>
+ </div3>
</div2>
<div2 id="interrelated-domains">
<head>Interrelated domains</head>
@@ -2705,7 +2757,15 @@
with the caveats and clarifications expressed in message
<loc href="http://lists.w3.org/Archives/Public/public-ws-policy-eds/2007Sep/0002.html">2007Sep-0002</loc>.
</td>
- </tr>
+ </tr>
+ <tr>
+ <td>20070921</td>
+ <td>MH</td>
+ <td>Implemented the resolution for issue
+ <loc href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=5044">5044</loc>. Editors' action
+ <loc href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/358">358</loc>.
+ </td>
+ </tr>
</tbody>
</table>
</inform-div1>
Received on Friday, 21 September 2007 22:04:21 UTC