1 Introduction

Policies are an essential way of expressing the qualities of a service in today's feature-rich enterprise environment. The configuration of products and services are determined by policies; the load balancing behavior and other capabilities of systems are defined by policies; the choices and nature of transport, the types and characteristics of security, the transactional nature of an interaction, the reliability of a message exchange, all are defined by policies. Because policies have proven to be critical to so many aspects of the computing ecology, they must be simple, easily and efficiently interpreted, and highly extensible for use in widely varying contexts.

Policies have proven their value in many computing infrastructures, but perhaps CORBA (Common Object Request Broker Architecture) provides the best example. That environment has had a general model for policies since 1997, with CORBA V2.2 (IONA was a major contributor to this and over two dozen subsequent specifications, implementing them and developing years of field experience in their design, use and maintenance.) Policies were originally defined just as a way of having separate configuration entities. Now they are applied in all of the ways mentioned above, with the specific policies applicable to a particular component or subsystem defined by the standard for that component or subsystem. Additionally, the standard specified the interactions of its policies with those of other components and systems — their precedence, interleaving constraints, etc. This has provided a flexible, robust system that has influenced all infrastructures since then.

We feel that there is a similar critical need for policies in Web Services products and services, and for the same reasons. Accordingly, we reviewed and analysed existing and proposed web services policy standards and developed a set of distinguishing characteristics. We then evaluated each characteristic in terms of the industry's needs. We concluded that the following are the most important characteristics:

Keep it simple! First, and most importantly, the implementation of policies must be simple, lightweight and extensible
- Extensible through parameterisation
- Clearly separating policy processing from policy representation
Keep it simple! Policy grouping should be simple, leaving Boolean operators, preference weighting, etc. to the extensibility mechanisms
Policies must be easily accessible directly from WSDL.
Policies must be able to be bound to any or all of the WSDL service components. And, oh yes, keep it simple!

The following sections explore each of these requirements in detail, followed by a use case that shows the importance of each requirement.

2 Requirements

2.1 Simple, Lightweight, Extensible Implementation

A policy may be used to express a desired behaviour, a constraint, a capability or an aspect of configuration. Since there are so many uses for policies and since policies can play a critical role in framework and plugin-type architectures, it is very important that they are as simple and as lightweight as possible. This is achieved by making each policy a first-order entity, typed by its name, by disassociating directives for processing a policy from the representation of the policy and by making them parameterisable. These three properties are required to provide flexibility, robustness and to allow extension for other, unanticipated features. For example, a policy specifying the kinds of security a particular service supports might look something like the following:

<Policy type="Security">
  <Kerberos/>
  <X509/>
</Policy>

2.1.1 Extensibility through Parameterisation

We feel that merely by its presence, a policy can indicate that a feature is supported. However, a more robust representation of a policy must contain additional information such as the range of operation of the feature, a subtype or value, or a complex structure containing multiple pieces of data to be used in processing different aspects of the policy. This information must be provided to the policy when it is created and must be immutable once part of the policy. Thus, a particular policy type can be made to serve in widely differing environments. For example,

<Policy type="Reliability">
  <OnceAndOnlyOnce>Yes</OnceAndOnlyOnce>
  <NegativeAckRequired>Yes</NegativeAckRequired>
</Policy>

2.1.2 No Processing Information Represented in the Policy

Keep it simple! The processing of everything from a policy with no parameters to one with a parameter of a complex structure can be done many ways, all involving trade-offs, such as the common one between speed and memory usage. Elegance of representation and the maintainability of the processing style is another such trade-off. The processing of an alert or interrupt-driven application can be very different from one that is processing-intensive. A single standard processing style may work fine in some use cases but be inappropriate to others. Therefore, the processing of a policy should be application or service-specific. This easily becomes an extensibility feature by making the processing directives and code a plugin associated with the policy. This would also allow a policy to be reused in multiple contexts.

Making the processing directives for policies separate and application or service-specific also simplifies the standard because it removes the need for standardizing and supporting the extensive (but, alas, always incomplete) set of operators that are required to support a single integrated standardized processing mechanism. The syntax of the policy framework is drastically simplified with the omission of complex processing models associated with rules evaluations.

2.2 Policy Grouping

We contend that W3C should define the standard form of a policy and the allowable associations for a policy, but that, in addition to proprietary policies used for configuration and application-specific work, policies, themselves, will be defined by standards organizations as part of the standards for a feature or a service. For example, security policies will be (and are) defined as part of various security standards, including ws-security. The allowed values of a policy parameter will be specified, as will the interpretation of the policy type and its value. Additionally, the relationship of one policy to others and its use in various stages of processing will be specified in the standard. Products that are compliant with the standard will implement and process the associated policies as specified by that standard.

Our review of current proposals reveals excessive complexity. An extensive set of operators in a policy framework is simply not needed since, as indicated above, the products will have encoded the necessary logic as part of implementing the given standard and as part of encoding its processing preferences and behaviour. Such operators merely make the framework more complex and more prone to error. The extensibility mechanisms are sufficient to represent and process complex policies. For example, a security standard might specify alternative cert formats as part of a security policy. The product implementation of that standard specifies, in an implementation-specific manner, which formats it supports and its preferences among them. The policy merely provides in its parameter a list of the cert formats to choose from. In other words, the separation of policy from representation and the extensibility of the parameter are sufficient to allow the process to make a choice from alternatives, based on its preferences, without the need for operators or for weighted measures of preference to be encoded into the policy framework.

Similarly, many of the proposed policy standards have made the indication of usage more complex than it needs to be. A policy may be tagged as "required" or not. If the policy exists in a policy set and is not "required", it is optional. If it's not in the set, it isn't supported at this time for this operation, etc. A Boolean "required" flag is all that's needed for defining the usage of a policy.

The syntax of the policy framework is drastically simplified with the omission of complex processing models associated with rules evaluations, order of precedence calculations and multiple selection criteria. As a result of this simplification, the policy framework becomes less error-prone and more flexible for use in different environments. As the first requirement says — keep the framework simple and let the extensibility mechanisms deal with arbitrary complexity. Use simple lists that the requestor can choose from and there is no need for more. A list of choices is the "value" of the policy. (Note that each choice can be a complex data type. The relevant standard will define the value; the implementation of the service, if it supports the standard, will know how to process the value. For example,

<Policy type="Security" required="true">
  <Kerberos/>
  <X509/>
</Policy>

2.3 Policy Language and Association

We believe that it is very important that the language of policies be tied to WSDL 2.0, as an extension of WSDL or as part of the Features and Properties syntax. This is important for general adoption of the standard, for ease in extending and enhancing the standard, and to keep companies from having to develop a special-purpose policy parsing and processing engine. Policies must be able to be written inline, related to the definition of a portType, Operation, Binding, etc.) and be able to be itself a Web resource, external to a service's definition and referenced through an address. The external reference is necessary for reuse of a policy. This, in essence, is W3C's main job with respect to Policies — to define their form and representation, their allowed associations and their use. Standards created by this and other organizations will define their own policies using this form, representation, associations and use. WS-Security will be a prime example when they modify their standard to support a compliant form.

2.4 Binding to a Service

Policies for a given service and a particular interaction should be able to be associated with any or all elements of the following list. The list, taken from WSDL 2.0 Features and Properties but with the addition of the service component, is in increasing order of specificity. If a policy of the same type is found in both an earlier and a later component, the later policy overrides the earlier.

The service component
The interface component
The specific interface operation component
The specific message reference component
The binding component
The specific binding operation component
The specific binding message or fault reference component

A client figures out what policies apply to a particular request (i.e. develops an "Effective Policy Set") by examining the server's applicable components listed above and overriding as specified. This Effective Policy Set is just a simple list of the policies that apply to a particular interaction or configuration behavior.

3 Use Case

A Web service wishes to stipulate that clients are required to support a reliable messaging protocol and encrypt a specific header with WS-Security using an X.509 or user name security token in order to send an acceptable request message. Furthermore, the service has a P3P policy associated with its operations. Such constraints and capabilities might be associated with the Web service via a SOAP header or a WSDL file.

As the service is initialising itself, it generates a standardized policy named ReliableMessaging. This name is standardized. Two parameters are passed in to the generation procedure — a flag indicating if the policy is required and a list of the standard names for the protocols that the service supports. These names are ordered by the service's preference for the protocols, but the actual choice will be made according to the client's preference, so this ordering is just an optimisation technique, not required. The generated policy will contain the "required" boolean value and the list of supported protocols. A reference to the policy is placed at the Service component level in a manner as defined in 2.4, above.
Also, while the service is in its initialisation phase, it generates standardized policy named Security. This name is standardized. The parameters to the generation are a flag indicating the policy is required and a list that gives the standard names for the protocols supported (X.509 and a user name security token protocol, both names standardized by their respective standards groups). A reference to the policy is placed in the binding for the request messages. A reference to this policy is placed at the interface component level as indicated in 2.4 so all operations will inherit it.
Finally, also in the initialisation phase, the service generates a standardized policy named Privacy. The "required" flag is false and the parameter is a list with a single element standardly named P3P. A reference to this policy is placed at the interface component level.
When a client wishes to send a request to the service, it retrieves the service's WSDL definition and searches for and processes policies as defined in 2.4, above, creating an ephemeral "effective policy set" — the policies that are effective for the particular request. A set required flag in some of the policies indicate to the client that it must choose among the items in each required policy's value list and use the indicated mechanism, property, etc. An unset flag indicates the service supports the standard but the client needn't choose to use any of the items in its value list. Since the P3P policy is not required, the client can ignore it. However, if the client supports P3P it knows that it can expect particular information to be accessed and possibly saved by the service and may choose not to execute the request.

<interface name="......>
  <Policy type="Security" required="true">
    <Kerberos/>
    <X509/>
  </Policy>
  <Policy type="Reliability" required="true">
    <OnceAndOnlyOnce>Yes</OnceAndOnlyOnce>
    <NegativeAckRequired>Yes</NegativeAckRequired>
  <Policy type="P3P"
  </Policy>
  <operation name=".....>
    <input>
    <output>
  </operation>
  ...
</interface>
 ...
<binding name=".......>
    ...
  <soap:binding style=".......>
    <soap:header use="..." message="..." part="..." policy="Security" .../>
  ...
</binding>

4 Conclusion

As indicated by the use case, a set of complicated indications of intention, requirement, support and use can be expressed in simple ways. This is more desirable than a complicated scheme involving complex processing models associated with rules evaluations, order of precedence calculations and multiple selection criteria. It makes the policy framework must more lightweight and flexible.

IONA Technologies Position Paper