Constraints and capabilities for web services is a vast area. For example, declaring system level services (SLS) or quality of service (QoS) options for a service may involve declaration of policies from the perspective of the web service or its clients. It may also be affected by agreements between service providers that are governed by legal and business considerations.
We argue that an assertion-based language should be used to express SLS/QoS policies. We refer to this language as the Constraints and Capabilities Language (CCL) in this paper. An assertion is a statement about a single constraint, capability or property. Assertions can be divided conceptually into operational and informational assertions. Operational assertions are used to configure and provide specific SLS/QoS properties while informational assertions can be used for reasoning about SLS/QoS capabilities but do not influence the wire format i.e. they do not influence the components of the header or whether, for example, the body is encrypted or signed.
We also argue that assertions should be grouped into domains. Each domain defines an orthogonal axis of functionality. Thus, if you want the functionality offered by domain A, you can include domain A in your policy. If you want the functionality offered by domain B, you can include domain B. The inclusion of domain A does not influence whether domain B can or cannot be included. Details of the functionality depend on the assertions included within each domain and how they are composed together. In working with policies, domains may be marked as "required" or "supported". One of the alternatives in required domains must be satisfied and one of the alternatives in supported domains may be satisfied.
Each domain is identified by a namespace. Assertions defined within this namespace and may contain data values. Assertions within a single domain can be composed together in the CCL.
Allowing assertions to be composed allows a policy to express functionality using an arbitrary combination of assertions. Restricting composition to assertions from within a single domain reduces the combinatorial complexity that can arise if assertions from different domains are allowed to be composed together. It also prevents the expression of policies that do not make sense.
The essential, immediate requirement for the CCL is to allow the configuration or generation of communicating services so that they create messages conforming to some agreed upon policy. Currently, the important domains to support are security, reliability and transactions. Other domains may be added in the future. [WS-Policy] and the Features and Properties in [WSDL 2.0] do a fairly good job of meeting this requirement. But, as discussed below, they fall short in important ways.
Another requirement is to support the ability to attach declarative statements to services and service components as well as to policies and policy components. At the simplest level, humans can examine these statements and make decisions about, for example, whether a service should be used or not. At a more ambitious level, software can be used to analyze these statements and make decisions regarding, for example, service level agreements. [WSPL] and [EPAL] describe expression languages for specifying such software.
Although, as mentioned above [WS-Policy] and the Features and Properties in [WSDL 2.0] provide frameworks for expressing policies containing message-level assertions, we feel that these designs can be improved in a couple of directions.
[WS-Policy] is, essentially, a single-level framework for describing policies. Although assertions and operators (exactlyOne, oneOrMore, ...) can be contained within operators there is no ability to specify which assertions can and cannot be combined. This allows policies to be specified that are inconsistent. For example, a policy can contain a top-level exactlyOne that contains a security assertion and a transaction assertion. This means that the policy can be satisfied if either the security assertion or the transaction assertion is satisfied. Grouping assertions into domains and allowing only assertions from a single domain to appear within an operator leads to more consistent policies and limits undue combinatorial complexity.
The Features and Properties in [WSDL 2.0] represents a stopgap solution for expressing Web Services policies until an open standard emerges. Features and Properties do present a model that distinguishes between features and properties, hence implying a two-level model similar to domains and assertions. However, it is not a complete two-level model due to the lack of both operators and defined relationships between properties and features. One consequence of this is that policies do not have the ability to select between assertions within a domain: for example, you cannot write a policy using Features and Properties that can be satisfied if incoming messages provide either a X 509 certificate or a Kerberos ticket. Further, Features and Properties can only be inlined in a [WSDL 2.0] document and cannot define policies independently of [WSDL 2.0].
Broadly speaking, we favor a design with the following characteristics:
This provides a simple but powerful framework for expressing Web Services policies. Allowing assertions to be composed together allows the expression of a rich variety of policy alternatives. Restricting composability to assertions from within a single domain limits complexity and disallows the specification of certain kinds of incorrect policies.
In addition to assertions that control the content and structure of messages, there is a requirement that policies be able to express information about services and service components as well as information about other assertions. Such information could be used by humans or machines to make decisions about a service. In the simplest case, this may be a decision about whether or not to use a service, perhaps depending on the legal contract that accompanies it, which would be checked by a lawyer, or its privacy policy, which may be checked by software. At a more detailed level such information may be input to a service-level agreement negotiation.
Informational domains could be included in policies in several ways. For example, we could define a domain for privacy and an assertion in that domain that indicated the location of a [P3P] file. A policy containing such a domain and assertion could be attached to a WSDL service element to indicate that that service advertised the privacy policy delineated in the referenced file. This is illustrated in the use case below. In the same manner, policies containing assertions about auditing or logging could be attached to a WSDL message type to indicate that that message type would be audited or logged.
Another way of including an informational domain in a policy is to add it as a child element of other assertions using extensibility points. Consider a policy that includes a security domain with a UserNameToken assertion. If we wanted to indicate that the UserNameToken would be stored persistently, we could add a child element to the UserNameToken assertion to indicate that it would be stored persistently provided an appropriate extensibility point was available.
The following is a statement of the use case required for the position paper for the W3C Constraints and Capabilities Workshop:
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 a 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.
We enhance this use case by stipulating that the reliability assurance on message delivery must be "no duplicates" and "guaranteed delivery", i.e. each message is delivered once and only once.
This use case can be expressed in the above framework with the following policy. The syntax used to express the policy for the use case is notional and should not be interpreted as a normative proposal. The 'pns' prefix is bound to the policy (CCL) name space, the 'wsrm' prefix to the WS-Reliability namespace, the 'wsse' prefix to the WS-Security namespace and the prefix 'wspriv' to a Web Services privacy namespace.
<pns:Policy targetNamespace='www.oracle.com/Example/UsecasePolicy.html'>
<pns:Domain URL='.../Reliability/...'>
<pns:All>
<pns:Assertion>
<wsrm:GuaranteedDelivery>true</wsrm:GuaranteedDelivery>
</pns:Assertion>
<pns:Assertion>
<wsrm:NoDuplicateDelivery>true</wsrm:NoDuplicateDelivery>
</pns:Assertion>
</pns:All>
</pns:Domain>
<pns:Domain URL='.../Security/...'>
<pns:ExactlyOne>
<pns:Assertion>
<wsse:SecurityToken>
<wsse:TokenType>X509</TokenType>
</wsse:SecurityToken>
</pns:Assertion>
<pns:Assertion>
<wsse:UserNameToken/>
</pns:Assertion>
</pns:ExactlyOne>
</pns:Domain>
<pns:Domain URL='.../Privacy/...'>
<pns:All>
<pns:Assertion>
<wspriv:location>
www.oracle.com/P3Pfiles/Example.html
</wspriv:location>
</pns:Assertion>
</pns:All>
</pns:Domain>
</pns:Policy>
This paper describes Oracle's position on Constraints and Capabilities for Web Services. We make two main points:
The separation of assertions into informational and operational assertions and the grouping of assertions into islands of functionality (domains) is intuitively appealing and reduces complexity by limiting composability.