W3C Workshop on Constraints and Capabilities for Web Services
Copyright © 2004 IONA Technologies, PLC
IONA Technologies PLC
October 12, 2004
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:
The following sections explore each of these requirements in detail, followed by a use case that shows the importance of each requirement.
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>
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>
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.
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>
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.
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.
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.
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.
<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>
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.