Section 7.2. Architectural Concepts

7.2. Architectural Concepts

The WS-Policy framework consists of two specifications: WS-Policy and WS-PolicyAttachment. The WS-Policy specification describes the grammar for expressing policy alternatives and composing them as combinations of domain assertions. The WS-Policy specification also describes the basic mechanisms for the merging of multiple policies that apply to a common subject and the intersection of policies to determine compatibility.

The WS-PolicyAttachment specification describes how to associate policies with a particular subject. It gives normative descriptions of how this applies in the context of WSDL and UDDI, and it provides an extensible mechanism for associating policies with arbitrary subjects through the expression of scopes. The next section explores attachment in more detail.

7.2.1. Policy Framework

A policy in the WS-PolicyFramework is the expression of a set of valid policy alternatives. Policy alternatives describe the acceptable combinations of constraints and requirements, which govern the interaction between a service and a requester or the access to a resource. A policy assertion represents each behavior (a discipline-specific constraint or requirement, such as following a reliable messaging protocol of encrypting messages). Therefore, a policy alternative is a combination of assertions, possibly from multiple disciplines. The policy does not specify to which subject the policy must be applied (the policy subject). It is merely a self-contained description of the constraints and requirements.

You can express the set of policy alternatives in a given policy in a compact form using policy operators, as described next. These choices enable you to group assertions or optionally include them within a group. You then define a normative algorithm for the translation of an arbitrary policy into its normal or enumerated form to facilitate the intersection of policy sets to find viable policy options for two parties that are trying to determine if they have comparable policies.

The Policy Container

The primary component of the WS-Policy Framework is the policy container, which is represented by the Policy element. This element is a container for collections of assertions or combinations of assertions that represent a set of valid policy alternatives. Assertions are combined through policy operators. Policies can be named using the Id attribute to enable referencing and reuse.

Policy Operators

The WS-Policy specification defines two operators and a modifying attribute to enable policy authors to group assertions into valid combinations.

ExactlyOne Operator

This operator means that oneand only oneof its contained assertions or operators might be considered as part of an alternative at any one time. Consider the following:

 <wsp:Policy>   <wsp:ExactlyOne>       <wsse:SecurityToken>           <wsse:TokenType               wsse:x509v3           </wsse:TokenType       </wsse:SecurityToken>       <wsse:SecurityToken>           <wsse:TokenType>              wsse:kerberosV5TGT           </wsse:TokenType>        </wsse:SecurityToken>   </wsp:ExactlyOne </wsp:Policy> 

This policy represents two valid policy alternatives: one that specifies the constraint that an X.509 security token needs to be presented, and another that specifies the constraint that a Kerberos token needs to be presented. No policy alternative allows both tokens to be presented simultaneously.

All Operator

This operator is a simple aggregation of assertions. All children must be considered part of the combined behavior.

As an example, consider the following policy.

 <wsp:Policy>    <wsp:All>       <wsse:SecurityToken>          <wsse:TokenType>wsse:x509v3</wsse:TokenType>       </wsse:SecurityToken>       <wsrm:RMAssertions>           ......       </wsrm:RMAssertions>    </wsp:All> </wsp:Policy> 

This policy has a single valid policy alternative. This alternative combines reliable messaging behavior with the requirement to present an X509 security token.

"Optional" Operator

This attribute is encoded on policy assertions to indicate that the inclusion of an assertion in the combined behaviors is optional.

 <wsp:Policy> <wsse:Integrity wsp:optional="true"> ... </wsse:Integrity> </wsp:Policy> 

Here, the policy contains two valid policy alternatives: one that includes the use of a digital signature, and one that does not (and does not specify additional behavior). The absence of the optional attribute has the default interpretation of optional="false." In other words, the assertion is required.

You can include the use of these operators and optional attributes in various combinations within a policy by nesting assertions and operators inside another operator. A policy is said to be in "normal form" when it is composed of a single ExactlyOne operator containing one or more All operators. Every policy in normal form follows this template. The WS-Policy specification describes the rules for converting a policy into normal form.

 <wsp:Policy> <wsp:ExactlyOne> <wsp:All>...<wsp:All> + </wsp:ExactlyOne> </wsp:Policy> 

In a normal form policy, each valid policy alternative is contained within an All element, and all of the alternatives are contained under a single ExactlyOne operator. This means you can choose only one alternative, and that alternative is a complete expression of the combined behaviors. In other words, where any particular assertion included in the policy appears in an alternative, you must apply its behavior, and where it does not appear in an alternative, you must not apply its behavior.

The WS-Policy specification defines a normative algorithm for translating any policy expression into a normal form policy. The meaning of a policy as a collection of alternatives is defined by its corresponding normal form, as defined by the normative transformation algorithm. An example of such a transform is illustrated next, using fictitious assertions A, B, C, and D.

 <wsp:Policy>     <A/>     <B optional=true>     <wsp:ExactlyOne>              <C/>              <D/>     </wsp:ExactlyOne> </wsp:Policy> 

The normal form is as follows:

 <wsp:Policy>   <wsp:ExactlyOne>              <wsp:All> <A/> <B/> <C/> </wsp:All>              <wsp:All> <A/> <C/>      </wsp:All>              <wsp:All> <A/> <B/> <D/> </wsp:All>              <wsp:All> <A/> <D/>      </wsp:All>   </wsp:ExactlyOne> </wsp:Policy> 

Policy Vocabulary

The vocabulary of a policy is the set of all assertions that appear in the policy. Every assertion that is declared in a policy is considered part of the policy's overall vocabulary. For instance, in the last example of the previous section, the vocabulary of the policy would include assertions A, B, C, and D. As policies are merged through inclusion or through attachment to a common policy subject, so, too, are their vocabularies.

Because the vocabulary represents all the behaviors that the policy, considered as a whole, is making a statement about, each policy alternative is cast within this context. Consequently, each alternative is making an explicit statement of which behaviors within the vocabulary are part of the alternative, and (implicitly through their absence) which behaviors are not. This is the absence is negation rule of policy expressions.

It is important to note, however, that policies make no statement about behaviors whose assertions are not part of the policy vocabulary (because they are never mentioned in the policy). When intersecting policies to determine compatibility, the "absence is negation" rule applies within the scope of the policy's vocabulary.

Policy Identification and Inclusion

You can name policies using the wsp:Id attribute on the policy that is contained. Policy identifiers are unique absolute URIs. You need to assign an identifier to a policy so that other documents and definitions can reference it.

You need to reference policies in two main situations. In the first one, the contents of a policy expression can be embedded into a new policy by reference, using the PolicyReference element. The policy reference element is used within a Policy container; it carries the URI of the policy to be included, and its semantics are equivalent to textual substitution of the PolicyReference element by the contents of the included policy.

PolicyReference provides a means of aggregating policies, and it supports modularizing complex policy definitions into reusable policies that represent individual disciplines or concerns. For example, for manageability purposes, a service provider might find it desirable to model its separate quality of service domains, such as security, transactions, and reliability, as separate policies. A service provider can then combine these separate domains as required for each deployed service by including the appropriate policies under a single policy container.

Policy identifiers are also required when policies are attached to specific policy subjects. The different attachment mechanisms are discussed in more detail in section 7.2.2.

Policy Intersection

The intersection of policies is defined in the WS-PolicyFramework specification as a mechanism to help determine the potential compatibility between two policies. This situation arises every time the policies of a service need to be checked against the capabilities or requirements of the service requester. For instance, during the service discovery phase, a potential service user can express his quality of service requirements in the form of a policy that services need to support. Although an exact match might not be possible (between the policy advertised by the service and the one representing the requester's requirements), the question arises of whether there is a set of compatible settings that both policies support. That alone would be enough to support the interaction from the quality of service compatibility point of view. By inspecting the structure of the two policies, you can determine whether such a compatible set might exist. The process by which this determination is done is called policy intersection, because it involves identifying the set of policy alternatives that appear in both policies. You cannot decide on actual compatibility by the intersection of policies alone; intersection simply discards clear nonmatches and returns possible matches (matching the element names of the XML representation of the assertions). You must validate the resulting common alternatives by discipline-specific engines to ensure technical compatibility.

Policy intersection selects a subset of matching alternatives that appear in both policies. Policy assertions are compared to their element-qualified names and are considered equivalent if the names match. A match in the qualified names of the assertions does not imply that the assertions match (because attributes and children of the two assertion elements might not match) but provides a first check of compatibility that needs to be further refined by checking the assertions for compatibility. In the general case, this second comparison step requires the use of discipline-specific knowledge, which is not available at the policy framework level. This is, for example, the case in the assertions that include parameters (in the form of attribute values of additional nested elements). Without an understanding of the meaning of each parameter, you cannot judge the compatibility of two parameter values. Policy intersection provides a first pass at establishing the compatibility of policies by preselecting possible matches between alternatives. Therefore, intersection is a domain-independent process for explicitly ruling out incompatible policy alternatives.

This mechanism is expected to be used in various ways. In a simple scenario, a service requester uses it to determine which of the policy alternatives that a service offers are compatible with its own technical capabilities and requirements. To do this, the requester formulates a policy that represents the type of service interactions it supports and intersects it with the actual policy offered by the service it wants to access. This process can result in one or more potential alternatives. It is advisable that you follow the intersection with validation of the matching alternative(s) using assertion-specific knowledge.

7.2.2. Attaching Policies to Web Services

In the context of Web services, policies describe the constraints on an interaction between two or more Web service endpointstypically a service provider and a service requester. However, policies that were created using the Policy container do not indicate the subject to which they apply. In WS-Policy, the association of policies with subjects is clearly separated from policy definition. That allows you to associate policies with multiple subjects and encourages you to reuse policy definitions.

WS-PolicyAttachment is concerned with the introduction of various mechanisms to associate policies with subjects. In a Web services scenario, several things might constitute a subject: a particular document, a document type, a message, a message exchange, a port type, an endpoint, a whole service, or a collection of services. The important point is that the set of possible subjects is not a closed set. Extensibility of attachment mechanisms is a fundamental requirement in WS-Policy. Two different mechanisms are introduced in this specification to satisfy this requirement:

• A generic policy annotation to be used in arbitrary XML documents. A policy annotation allows direct attachment of policies to specific subjects that are defined or described within the document. The annotation directly identifies the applicable policies.

• An external attachment mechanism that associates policies with subjects from outside the documents where the subject is defined or described.

You create policy annotations using the PolicyURIs attribute or the PolicyReference element. (Both are global definitions within the WS-Policy namespace.) The value of the PolicyURIs attribute is a list of whitespace-separated policy identifiers. The PolicyReference element contains one policy identifier. You use multiple elements when you need to attach more than one policy. You can encode the PolicyURIs attribute or the PolicyReference element, or you can nest it under an XML element to indicate that the referenced policies apply to the subject that element identifies.

WS-PolicyAttachments describes in detail how to use policy annotation in WSDL service description documents. Annotation of WSDL descriptions is a primary mechanism by which policies are attached to a service endpoint. (It is not the only mechanism, however, because you can also attach policies to a service endpoint using the external attachment method, as explained next.) Several types of WSDL definitions can constitute a policy subject. They include the message definitions, port type definitions, and WSDL bindings, among others. An attachment to a WSDL message binding using the PolicyReference element is shown in the next example.

 <binding name="stockQuoteSoapBinding"     type="tns:StockQuotePortType">    <soap:binding style="document"       transport="http://schemas.xmlsoap.org/soap/http"/>    <operation name="GetLastTradePrice">     <soap:operation soapAction=      "http://example.comGetLastTradePrice"/>     <input>         <wsp:PolicyReference URI=            "http://www.example.com/StdSecurityPolicy1"/>         <soap:body use="literal"/>       </input>       <output>         <soap:body use="literal"/>       </output>   </operation> </binding> 

Here, a security policy is attached to the input message of the "GetLastTradePrice" operation by including the PolicyReference element with the policy name URI under the <input> element of the binding. Because the scopes of WSDL definitions are naturally overlapping, the scopes of the corresponding policies overlap, too. Consider, for example, policies that are attached to a message and to a port type that contains an operation that uses the message. Both the message policy and the port type policy apply to the message as a subject, because the message is included in the scope that the port type definition defines. In general, when policies are associated with the WSDL definitions of overlapping scopes, the policy for a subject is the aggregation of all applicable in-scope policies. This is known as the effective policy of the subject. To clarify the possible usage cases and provide guidance to service developers, WS-PolicyAttachment defines a normative set of possible policy subjects in a Web service, identifies the corresponding WSDL elements that make up the overall policy description of each of them, and provides the policy aggregation mechanism that computes the effective policy.

External association of policies with subjects is done using the PolicyAttachment element. A PolicyAttachment contains a subject scope expression that identifies the set of subjects to which policies are being attached in addition to the policy to be attached. PolicyAttachment either provides an inline definition or uses one or more PolicyReference elements. The scope expression is an extensible part of the PolicyAttachment construct that allows various scenarios and disciplines to define their own expressions for describing policy subjects.

 <wsa:EndPointReference>    <wsa:Address>       http://www.example.com/StockQuote    </wsa:Address> </wsa:EndpointReference> 

WS-PolicyAttachment introduces the use of one such domain expression. As shown in the preceding example, you can encode a WS-Addressing endpoint reference as a scope expression to attach policies to the referenced endpoint.

The external attachment mechanism is particularly useful for communicating policy associations at runtime, via a message exchange. For example, in the course of their interaction, two endpoints might agree to use a certain conversational protocol during part of the interaction. The constraints on this protocol are specific to the interaction and relate to specific message instances, identifiable by their unique message identifier URIs, their sequence number if available, or by some other conversation-specific identifier. You cannot communicate this information prior to the dialogue through attachment to WSDL or UDDI; you can only communicate at runtime because that's when the identifiers are established. With the introduction of the WS-MetadataExchange specification, an endpoint can also request a policy at runtime. This late binding allows policies to reflect a finer level of granularity because the MEX request might identify the requester or the instance of a service via an EPR, which allows the provider to offer a policy expression that is targeted toward the individual requester.

WS-PolicyAttachment describes a normative use of UDDI for associating policies with Web service endpoints, giving service requesters and providers the ability to leverage the query capabilities of UDDI for discovery of endpoints based on their policy descriptions.