- From: Umit Yalsinap via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 04 Jan 2007 19:34:36 +0000
- To: public-ws-policy-eds@w3.org
Update of /sources/public/2006/ws/policy
In directory hutz:/tmp/cvs-serv16293
Modified Files:
ws-policy-guidelines.html
Log Message:
Synchronizing html with xml (version 1.23 changes)
Index: ws-policy-guidelines.html
===================================================================
RCS file: /sources/public/2006/ws/policy/ws-policy-guidelines.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- ws-policy-guidelines.html 20 Dec 2006 19:52:22 -0000 1.13
+++ ws-policy-guidelines.html 4 Jan 2007 19:34:33 -0000 1.14
@@ -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">What is an Assertion? </a><br>3. <a href="#d3e176">Who is involved in authoring Assertions? </a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> WS-Policy Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for WS-Policy Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New Assertions</a><br> &nbp; 4.3.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a>br> 4.5.1 <a href="#d3e518">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e526">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> 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 <ahref="#appropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenario">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">What is an Assertion? </a><br>3. <a href="#d3e176">Who is involved in authoring Assertions? </a><br> 3.1 <a href="#roles"> Roles and Responsibilities </a><br> 3.1.1 <a href="#domain-owners"> Assertion Authors</a><br> 3.1.2 <a href="#consumers">Consumers</a><br> 3.1.3 <a href="#providers">Providers</a><br>4. <a href="#general-guidelines">General Guidelines for Assertion Authors</a><br> 4.1 <a href="#assertion-target">Assertions and Their Target Use</a><br> 4.2 <a href="#compact-full">Authoring Styles </a><br> 4.3 <a href="#new-guidelines-domains">Considerations when Modeling New Assertions</a><br> 43.1 <a href="#minimal-approach">Minimal approach</a><br> 4.3.2 <a href="#QName_and_XML_Information_Set_representation">QName and XML Information Set representation</a><br> 4.3.3 <a href="#self-describing"> Self Describing Messages </a><br> 4.3.4 <a href="#single-domains">Single Domains</a><br> 4.4 <a href="#comparison">Comparison of Nested and Parameterized Assertions</a><br> 4.4.1 <a href="#parameterized-assertions">Assertions with Parameters</a><br> 4.4.2 <a href="#nested-assertions">Nested Assertions</a><br> 4.4.3 <a href="#which-one-to-use">Considerations for choosing parameters vs nesting</a><br> 4.5 <a href="#optional-policy-assertion">Designating Optional Behaviors</a><br> nbsp; 4.5.1 <a href="#d3e518">Optional behavior in Compact authoring</a><br> 4.5.2 <a href="#d3e526">Optional behavior at runtime</a><br> 4.6 <a href="#typing-assertions">Typing Assertions</a><br> 4.7 <a href="#levels-of-abstraction">Levels of Abstraction in WSDL </a><br>5. <a href="#lifecycle">Lifecycle of Assertions</a><br> 5.1 <a href="#Referencing_Policy_Expressions">Referencing Policy Expressions</a><br> 5.2 <a href="#extending-assertions"> 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="#apropriate-attachment-assertion-subjects">Appropriate Attachment: Identifying Assertion Subjects</a><br> 7.2.1 <a href="#interaction">Interaction between Subjects</a><br> 7.3 <a href="#identifying-assertion-sources">Appropriate Attachment: Identifying Assertion Sources </a><br>8. <a href="#scenario">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>The WS-Policy specification defines a policy to be a collection
@@ -74,7 +74,7 @@
A policy assertion is a machine readable metadata expression that
identifies behaviors required for Web services interactions.
<em>Web Services Policy 1.5 - Guidelines for Policy Assertion Authors</em>
- is a resource primarily for assertion authors and provides
+ is a resource primarily for Assertion Authors and provides
guidelines on the use of Web Services Policy 1.5 - Framework and
Web Services Policy 1.5 - Attachment specifications to create and use domain specific
assertions to enable interoperability.
@@ -90,14 +90,14 @@
non-normative guidelines for:
</p><ul><li><p>WS-Policy expression authors who need to understand the
syntax of the language and understand how to build consistent policy expressions,
- </p></li><li><p>WS-Policy assertion authors who need to know the features
+ </p></li><li><p>Assertion Authors who need to know the features
of the language and understand the requirements for
describing policy assertions.
</p></li></ul><p> Some of the guidance for authors can also be helpful for:
<ul><li><p>Consumers of policy expressions who need to understand
the requirements contained in policy assertions,
</p></li><li><p>Providers of policy expressions who need to understand
- how to use the assertions authored by policy assertion authors
+ how to use the assertions authored by Assertion Authors
</p></li></ul>
</p><p>This document assumes a basic understanding of XML 1.0,
Namespaces in XML, WSDL 1.1 and SOAP.
@@ -157,7 +157,7 @@
</p></li><li><p>Is there a requirement that a choice must be made for successful interaction?</p><p>Sometimes providers and requesters are required to engage in certain behaviors.
The use of optimization and reliable messaging are two examples.
</p></li></ul><p>There are already many examples in the industry that adhere to the above practices, such as <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite>
- and <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>. Some common characteristics from these documents may be considered as <em>best practices</em> for new assertion authors:
+ and <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite>. Some common characteristics from these documents may be considered as <em>best practices</em> for new Assertion Authors:
</p><ul><li><p>Specify both the syntax and the semantics of the assertions
</p></li><li><p>If nested or parameterized assertions are defined, be clear about their usage
</p></li><li><p> Describe the policy subjects the assertions can be attached to.
@@ -165,7 +165,7 @@
be followed so that the assertion developers defining such a
specification will be well informed and able to adequately specify assertions for their domain.
</p><p>It is expected that consumers of the metadata specified by
- the assertion authors will also benefit from understanding these
+ the Assertion Authors will also benefit from understanding these
practices as it will help them utilize the assertions in the
context of the WS-Policy framework. A result of following the
best practices will be an assertion specification that describes
@@ -186,13 +186,13 @@
<h3><a name="roles"></a>3.1 Roles and Responsibilities </h3><p>Below we capture some of the characteristics of the roles
and responsibilities for the authors, consumers and providers.
</p><div class="div3">
-<h4><a name="domain-owners"></a>3.1.1 WS-Policy Authors</h4><p> WS-Policy Domain owners or WS-Policy authors are defined
+<h4><a name="domain-owners"></a>3.1.1 Assertion Authors</h4><p>Assertion Authors are defined
by the WS-Policy Framework to be a community that chooses to
exploit the WS-Policy Framework by creating their own
specification to define a set of assertions that express the
capabilities and constraints of that target domain. The
WS-Policy Framework is based on a declarative model, meaning
- that it is incumbent on the WS-Policy authors to define both the semantics of
+ that it is incumbent on the Assertion Authors to define both the semantics of
the assertions as well as the scope of their target domain in their specification. The set
of metadata for any particular domain will vary in the granularity of assertion
specification required. It is the intent of
@@ -200,10 +200,10 @@
a way that multiple WS-Policy domains can co-exist and
consumers and providers can utilize the framework consistently across domains.
</p><p>When using the WS-Policy Framework, any
- domain author defining new WS-Policy assertions
+ Assertion Authors defining new WS-Policy assertions
must adhere to the MUST's and SHOULD's in the specification
and should review the conformance section of the specification.
- </p><p>WS-Policy Domain authors must also specify how to associate
+ </p><p>Assertion Authors must also specify how to associate
the assertions they have defined with the policy subjects
identified by the WS-PolicyAttachment specification.
</p><p>An example of a domain specification that follows these practices is the WS-SecurityPolicy
@@ -264,16 +264,16 @@
<cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> that describes service and
policy assertion evolution.
</p></div></div></div><div class="div1">
-<h2><a name="general-guidelines"></a>4. General Guidelines for WS-Policy Assertion Authors</h2><p> As authors begin the task of inventing XML dialects to represent policy assertions they can take
+<h2><a name="general-guidelines"></a>4. General Guidelines for Assertion Authors</h2><p> As Assertion Authors begin the task of inventing XML dialects to represent policy assertions they can take
advantage of WS-Policy building on XML principles and XML Schema validation in their design. WS-Policy
- relies on the QName of a policy assertion being an XML element but allows authors to optionally
+ relies on the QName of a policy assertion being an XML element but allows Assertuib Authors to optionally
provide additional semantics through nesting assertions, or specifying assertion parameters.
This section covers several aspects of assertion design and provides some answers to the following questions:</p><ul><li><p>What is the intended use of the policy assertion?</p></li><li><p>Which authoring style will be used?</p></li><li><p>Is this a new policy domain? Does it need to compose with other domains?</p></li><li><p>How complex are the assertions?</p></li><li><p>Is there a need to consider nesting?</p></li><li><p>Do optional behaviors need to be represented?</p></li></ul><div class="div2">
-<h3><a name="assertion-target"></a>4.1 Assertions and Their Target Use</h3><p>WS-Policy authors need to have some definition of what the goal is for the assertions
- they author. WS-Policy authors should also understand the
+<h3><a name="assertion-target"></a>4.1 Assertions and Their Target Use</h3><p>Assertion Authors need to have some definition of what the goal is for the assertions
+ they author. Assertion Authors should also understand the
functionality the WS-Policy framework provides and apply the
knowledge of framework processing when defining the set of assertions.
- </p><p>Assertions can be simple or they can be complex. WS-Policy authors may choose to specify one or two
+ </p><p>Assertions can be simple or they can be complex. Assertion Authors may choose to specify one or two
assertions or they may choose to specify many assertion
elements that require parameters or other nested
assertions. There are advantages to simplifying the set of
@@ -301,7 +301,7 @@
environment; when creating a domain specific
attachment in multiple WSDL files or Endpoint
References in which the same set of policies are expected to be applied.
- </p><p>Best practice: WS-Policy authors should include the following
+ </p><p>Best practice: Assertion Authors should include the following
items in the dialect specification:
</p><ul><li><p><em>The definition of the
assertion</em>. Does the assertion pertain to a specific
@@ -395,20 +395,20 @@
order to enable dynamic negotiation of business requirements
and capabilities at runtime.
</p><div class="div3">
-<h4><a name="minimal-approach"></a>4.3.1 Minimal approach</h4><p>New policy authors are encouraged to try to not overload assertions. A single assertion indicates a single
+<h4><a name="minimal-approach"></a>4.3.1 Minimal approach</h4><p>New Assertion Authors are encouraged to try to not overload assertions. A single assertion indicates a single
behavior. Sets of assertions can by grouped by an operator "all". This indicates that there is a relationship between
the assertions and they now constitute a policy alternative.
</p><p>If grouping is utilized, choices between alternatives can be indicated by
an "exactly one" operator. This basic set of operators allows
- authors a wide range of options for expressing the possible combinations of assertions within their domain.
+ Assertion Authors a wide range of options for expressing the possible combinations of assertions within their domain.
</p><p>It requires a good deal of effort to evaluate the
capabilities of a domain and capture them in a way that
reflects the options of the domain if the domain has a lot of
assertions to define. Interoperability testing of new policy
domains is recommended to ensure that consumers and providers
are able to use the new domain assertions.
- </p><p>New authors are encouraged to look at <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite> to see an example of a
- relatively simple domain that has defined three assertions. Domain authors are encouraged to look at <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example of a complex domain that has been decomposed into a set of policy expressions.
+ </p><p>New Assertion Authors are encouraged to look at <cite><a href="#WS-RM-Policy">Web Services Reliable Messaging Policy</a></cite> to see an example of a
+ relatively simple domain that has defined three assertions. Assertion Authors are encouraged to look at <cite><a href="#WS-SecurityPolicy">WS-SecurityPolicy</a></cite> to see an example of a complex domain that has been decomposed into a set of policy expressions.
</p><p>How big should an assertion be? How many assertion parameters should the assertion
enumerate? How many dependent behaviors should the assertion enumerate? It is always
good to start with a simple working policy assertion that allows extensibility. As your
@@ -416,10 +416,10 @@
your interoperability needs.
</p><p>Best practice: Start with a simple working assertion that allows extensibility.
</p></div><div class="div3">
-<h4><a name="QName_and_XML_Information_Set_representation"></a>4.3.2 QName and XML Information Set representation</h4><p>Web Services Policy language allows assertion authors to invent
+<h4><a name="QName_and_XML_Information_Set_representation"></a>4.3.2 QName and XML Information Set representation</h4><p>Web Services Policy language allows Assertion Authors to invent
their own XML dialects to represent policy assertions. The policy language relies only
on the policy assertion XML element QName. This QName is unique and identifies the
- behavior represented by a policy assertion. Assertion authors have the option to
+ behavior represented by a policy assertion. Assertion Authors have the option to
represent an assertion parameter as a child element (by leveraging natural XML nesting)
or an attribute of an assertion. The general guidelines on when to use XML elements
versus attributes apply.</p><p>The syntax of an assertion can be represented using an XML outline (plus an XML schema
@@ -443,16 +443,16 @@
policy, what ciphers (and so forth) are supported by a particular
endpoint, or those that are required in a particular message; the
latter are the intended uses of the WS-Policy framework.
- </p><p>As a result, the assertion authors should take into account that the following important concepts
+ </p><p>As a result, the Assertion Authors should take into account that the following important concepts
when designing assertions and documenting the semantics of the
assertion types.
</p><p>Firstly, an assertion type indicates a <em>runtime</em> behavior.
- </p><p>Secondly, authors need to indicate how the runtime behavior represented in the assertion type can be inferred or indicated
+ </p><p>Secondly, Assertion Authors need to indicate how the runtime behavior represented in the assertion type can be inferred or indicated
from a message at runtime. If there is a need for the behavior
to be represented in a persistent way or if there is a need for
additional data or metadata that is present in a message to be
persisted, it should be incorporated into the assertion design or
- in the message itself. In essence, the assertion authors should
+ in the message itself. In essence, the Assertion Authors should
consider how to make messages self describing when utilizing
their assertions by specifying additional properties, headers,
etc. that must be present in a message as part of their assertion design.
@@ -477,7 +477,7 @@
will determine whether a particular set of assertions
correctly characterize a domain. A new community should avoid
duplicating assertions that have already been defined as this
- will create ambiguity not clarification. New WS-Policy authors
+ will create ambiguity not clarification. New Assertion Authors
should focus on creating assertions for those specific
constraints and capabilities that do not overlap with other
domains but that communicate new functionality.
@@ -496,8 +496,7 @@
assertion beyond its type. We cover these two cases below followed by a
comparison of these approaches targeting when to use either of the approach.
</p><div class="div3">
-<h4><a name="parameterized-assertions"></a>4.4.1 Assertions with Parameters</h4><p>The framework allows WS-Policy
- domain authors to define parameters, for example, to
+<h4><a name="parameterized-assertions"></a>4.4.1 Assertions with Parameters</h4><p>The framework allows Assertion Authors to define parameters, for example, to
qualify an assertion. For some domains it will be appropriate
to specify these parameters instead of nesting assertion elements.
</p><p> Note that parameters of assertions include the following:</p><ul><li><p> Complex elements with element children that cannot be policy assertions.
@@ -517,7 +516,7 @@
taken when defining nested policies to ensure that the options
provided appropriately specify policy alternatives within a specific behavior.
</p><p>We will use the WS-SecurityPolicy to illustrate the use of nested assertions.
- </p><p>Securing messages is a complex usage scenario. The WS-SecurityPolicy authors have defined the
+ </p><p>Securing messages is a complex usage scenario. The WS-SecurityPolicy Assertion Authors have defined the
<code>sp:TransportBinding</code> policy assertion to indicate
the use of transport-level security for protecting
messages. Just indicating the use of transport-level security
@@ -575,7 +574,7 @@
of assertions is that <em>the framework intersection
algorithm processes nested alternatives, but does not consider
parameters in its algorithm</em>.
- </p><p>Domain authors should recognize that the framework can
+ </p><p>Assertion Authors should recognize that the framework can
yield multiple assertions of the same type. The <em>QName</em>
of the assertion is the only vehicle for the framework to
match a specific assertion, NOT the contents of the
@@ -593,7 +592,7 @@
compatible policy alternative then the assertions in a nested policy expression play a
first class role in the outcome. There is one caveat to watch out for: policy assertions
with deeply nested policy can greatly increase the complexity of a policy and should be
- avoided when they are not needed.</p><p>Best practice: If the domain
+ avoided when they are not needed.</p><p>Best practice: If the assertion
authors want to delegate the processing to the framework,
utilizing nesting should be considered. Otherwise, domain
specific comparison algorithms will need to be devised and be
@@ -630,7 +629,7 @@
message to determine whether the incoming message adheres to
the Optimized MIME Serialization. By examining the message,
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,
+ 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 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
@@ -647,14 +646,14 @@
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
+ 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
+ designated, it is important for the 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></li><li><p> Attaching optional assertions to outbound-messages using message policy subject
@@ -667,7 +666,7 @@
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
+ 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
@@ -677,21 +676,21 @@
(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 describing the
+ only specified for an outbound message, the
+ Assertion Authors should consider describing the
semantics if the incoming messages also utilized the
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-Policy">Web Services Reliable Messaging Policy</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 policy subject is used via attachment.
- </p></li></ul><p>Best Practice: Optional assertion authors should explicitly state
+ </p></li></ul><p>Best Practice: 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. See also <a href="#self-describing"><b>4.3.3 Self Describing Messages </b></a>.
</p></div></div><div class="div2">
<h3><a name="typing-assertions"></a>4.6 Typing Assertions</h3><p>Since a <em>QName</em> is the central mechanism for
- identifying a policy assertion, assertion authors should be
+ identifying a policy assertion, Assertion Authors should be
aware of the possible evolution of their assertions and how
this would impact the semantics of the assertion overtime. A namespace
associated with the assertion may be used to indicate a
@@ -711,7 +710,7 @@
the use of an assertion to one of these subjects.
</p><p>Thus our example encryption assertion would have a
subject of "message", and could only be attached to
- messages, where the assertion is valid. However, authors
+ messages, where the assertion is valid. However, Assertion Authors
need to be aware that <em>policy attachment subjects are
not limited to the subjects defined in WSDL</em>. The
external attachment model in WS-PolicyAttachment allows for
@@ -730,7 +729,7 @@
subject – such as service, endpoint, operation and message.</p></li></ol></div><div class="div2">
<h3><a name="levels-of-abstraction"></a>4.7 Levels of Abstraction in WSDL </h3><p>A behavior identified by a policy assertion applies to the
associated policy subject. If a policy assertion is to be used
- within WSDL, policy assertion authors must specify a WSDL
+ within WSDL, Assertion Authors must specify a WSDL
policy subject. The policy subject is determined with respect
to a behavior as follows:
</p><ul><li><p>If the behavior applies to any message exchange
@@ -738,13 +737,13 @@
subject is the service policy subject. </p></li><li><p>If the behavior applies to any message exchange
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 policy subjects.</p></li></ul><p>WS-Policy authors that wish to utilize WSDL policy subjects need to understand how the assertions will be
+ the subject is the message policy subject - similarly for output and fault message policy subjects.</p></li></ul><p>Assertion Authors that wish to utilize WSDL policy subjects need to understand how the assertions will be
processed in 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>
</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 domain authors chose to support certain capabilities at
+ 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
@@ -756,12 +755,12 @@
assumptions for attachment and engagement of behavior.
</p><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><ul><li><p> Decompose the semantics with several assertions </p></li><li><p> Rewrite a single assertion targeting a specific subject. </p></li></ul><p> For a given WSDL policy subject, there may be several
+ Assertion Authors should consider the following</p><ul><li><p> Decompose the semantics with several assertions </p></li><li><p> Rewrite a single assertion targeting a specific subject. </p></li></ul><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. Policy assertion authors should identify the
+ portType element. Assertion Authors should identify the
relevant attachment point when defining a new assertion. To
- determine the relevant attachment points, authors should
+ 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
the assertion reasonably applies to any endpoint that ever
@@ -798,10 +797,10 @@
policy assertions do not target wire-level behaviors but
rather abstract requirements, this technique does not apply.
</p></div></div><div class="div1">
-<h2><a name="lifecycle"></a>5. Lifecycle of Assertions</h2><p>WS-Policy authors need to consider not just the expression of the current set of requirements but
+<h2><a name="lifecycle"></a>5. Lifecycle of Assertions</h2><p>Assertion Authors need to consider not just the expression of the current set of requirements but
how they anticipate new assertions being added to the set. There are three aspects that govern an assertions lifecycle:</p><ul><li><p> Assertion Extensibility </p></li><li><p> Policy Language Extensibility </p><p>Over time, the Policy WG or third parties can version or extend the Policy Language with new
or modified constructs. These constructs may be compatible or incompatible with previous versions.
- </p><p> Policy authors should review the WS-Policy Primer <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
+ </p><p> Assertion Authors should review the WS-Policy Primer <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite>
and the specifications <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> <cite><a href="#WS-PolicyAttachment">Web Services Policy Attachment</a></cite>
for details on extensibility.
</p><p> The current WS-Policy language <cite><a href="#WS-Policy">Web Services Policy Framework</a></cite> provides extensibility points
@@ -809,7 +808,7 @@
<h3><a name="Referencing_Policy_Expressions"></a>5.1 Referencing Policy Expressions</h3><p>The <cite><a href="#WS-Policy-Primer">Web Services Policy Primer</a></cite> illustrates how
providers can utilize the identification mechanism defined in the Policy specification
to expose a complex policy expression as a reusable building block for
- other policy expressions by reference. Domain assertion
+ other policy expressions by reference. Assertion
authors, especially those defining complex assertions that
include nesting or complex types should consider specifying or recommending
naming conventions in order to promote reuse. Reuse through
@@ -835,7 +834,7 @@
<sp:Wss11>…</sp:Wss11>
</Policy></pre></div></div><p>Best practice: use independent assertions for modeling multiple equivalent
behaviors.</p></div></div><div class="div1">
-<h2><a name="inter-policy"></a>6. Inter-domain Policy and Composition Issues</h2><p>Domain authors must be aware of the interactions between their
+<h2><a name="inter-policy"></a>6. Inter-domain Policy and Composition Issues</h2><p>Assertion Authors must be aware of the interactions between their
domain and other domains. For example, security assertions interact
with other protocol assertions in a composition. Although
modeling protocol assertions may appear to be an independent behavior,
@@ -844,7 +843,7 @@
example utilization of WS-Security Policy with other
protocols affects transport bindings and would result in nested
policy assertions when additional protocols are composed with
- <cite><a href="#WS-Security2004">WS-Security 2004</a></cite>. Thus, domain authors should
+ <cite><a href="#WS-Security2004">WS-Security 2004</a></cite>. Thus, Assertion Authors should
be aware of the compositional semantics with other related
domains. The protocol assertions that require composition
with WS-Security should be particularly aware of the nesting
@@ -956,10 +955,10 @@
</Policy></pre></div></div><p>We have shown above that Company A offered a
second profile that included two security options. The details of
the Bindings, requires a more detailed exploration of some of the
- other features of the WS-Policy Framework. </p><p>When WS-Policy authors create sets of Policy assertions, like
+ other features of the WS-Policy Framework. </p><p>When Assertion Authors create sets of Policy assertions, like
WS-Security Policy they need to consider expressing the semantics
of their domain in a way that policy consumers, like Company A,
- can utilize them. In this case, the WS-SecurityPolicy authors
+ can utilize them. In this case, the WS-SecurityPolicy Assertion Authors
factored out common elements of security mechanisms and utilized a
feature of WS-Policy called "nested" assertions. In the case of
an <code>sp:TransportBinding</code> assertion, just indicating the use of
@@ -1052,7 +1051,7 @@
<wsp:PolicyReference id=#CompanyA-ProfileB>
<wsdl:operation name="GetQuote"> </wsdl:operation>
</wsdl:binding></pre></div></div><p>In some cases, companies may chose to implement their own
- assertions. When companies chose to become policy authors they need
+ assertions. When companies chose to become Assertion Authors they need
to consider not only the definition of the behavior that the
assertion represents but they need to consider how new assertions
will be intersected and merged with other assertions in the
@@ -1230,4 +1229,7 @@
</td></tr><tr><td rowspan="1" colspan="1">20061220</td><td rowspan="1" colspan="1">TIB</td><td rowspan="1" colspan="1">Editorial revision: completed missing parts of editorial action
<a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/96">96</a>
after editorial reviews by co-editors.
+ </td></tr><tr><td rowspan="1" colspan="1">20061226</td><td rowspan="1" colspan="1">MH</td><td rowspan="1" colspan="1">Editorial revision: reconciled terms related to "Assertion Authors"
+ <a href="http://www.w3.org/2005/06/tracker/wspolicyeds/actions/106">106</a>
+ and bug http://www.w3.org/Bugs/Public/show_bug.cgi?id=3983
</td></tr></tbody></table><br></div></div></body></html>
\ No newline at end of file
Received on Thursday, 4 January 2007 19:34:55 UTC