In order to use a web service successfully, clients need to know various constraints and capabilities (CCs) of the service. The service also needs to know various CCs of the client for use in its responses. In the past, this information has often been hard-coded into specific client-service interfaces such that application developers had to study service documentation and manually implement the necessary interface parameters. The resulting client could interact with only a single service, using a static service contract.
A properly scoped and developed standard expression language for CCs, standard bindings of CCs to service descriptions and protocols, standard ways for clients and services to determine or negotiate mutually acceptable CCs, and standard ways for cooperating services to compose their CCs, have the potential for allowing flexible, dynamic client/service connections, along with a high level of interoperability.
This position paper addresses three aspects of CCs:
We then address an expanded use case with a specific proposal. The position paper concludes with a list of key requirements.
It must be possible to associate CCs with particular portTypes, interfaces, operations, bindings, endpoints, messages, and services. For some services, CCs will be specific to particular message components. CC statements must be granular and bindable at these levels. It must be possible to identify easily the CC that applies to a given message, etc.
Application users are interested in specifying abstract requirements, such as "financial statement message traffic must be authenticated and private". But the service must implement this as concrete locations, mechanisms and parameters, such as "on interfaces X and Y, use TCP with RSA client certificates; use AES encryption". These two levels of specification should be kept separate, yet should be linked for verifiability.
CC statements may be directly attached to various WSDL 2.0 elements (e.g. wsdl:interface, wsdl:operation, wsdl:binding, wsdl:endpoint, wsdl:service) using the extensibility mechanism built into the language. They will then show up in the component model as properties of the corresponding WSDL 2.0 components, where they can be accessed by tools.
Naturally, when CC statements appear at different levels, they need to be composed according to a set of predetermined composition rules. For instance, two CC statements, one associated with a wsdl:interface, the other with a wsdl:endpoint that implements that very interface, will have to be merged to create an effective CC statement for the endpoint as a whole, or one CC statement has to override the other for that endpoint. The WSDL 2.0 Features and Properties (F&P) framework provides a description of this merging process. Furthermore, by defining a 'policy' runtime property, the framework would also help formalize the relationship between the CC statements in a description and the CC headers described above. In particular, all these facilities would ultimately affect the runtime value of the 'policy' property, conceptually shared by all participating nodes.
This extensibility-based approach may also be employed in conjunction with WSDL 1.1.
These extensions elements may also be used in SOAP messages to convey dynamic CC information. Rather than advocating using them directly as SOAP headers, we prefer seeing them embedded under constructs such as service references (as defined in WSDL 2.0) or endpoint references (per the WS-Addressing specification).
In order to support automated negotiation of CC statements, clients need a way to express their CC requirements and preferences. Clients can use a simple syntax associating various binding points with their CC statements and allowing nesting for inheritance of CCs between different levels.
CC statements are not fully useful until there are automated ways for clients and services to determine a mutually acceptable set of CCs. This requirement is clear from a publicly reviewed requirements specification for web services policy languages. Negotiation requirements include the following.
In order to address GRID requirements, among others, the matching of client CCs with service CCs needs to be done by third-party "service brokers". If such third-parties are to be interoperable and maintainable, it must be possible to match any two CC statements in a standard way. CCs must not require separate semantic processing modules that might not all be available to a neutral third party.
Services may be unwilling to disclose their full CCs to clients that have not established a minimum level of acceptability. There may be multi-step protocols defined for establishing the client and server relationship. This leads to a requirement to support incremental negotiation. This requirement has implications for the binding mechanism, as secondary CC statements may need to be protected, such as with encryption.
Several web services, each having its own CCs, may cooperate to present a unified service to clients. In order to present clients with a unified CC statement representing a collective or serial set of CC statements, there is a requirement to support CC statement merging or composition.
As described under Negotiation, we believe the language for expressing CCs should support standard ways of matching and merging CCs between two CC statements. The XACML-based "Web Services Policy Language" described in An Introduction to the Web Services Policy Language (WSPL) is an example of such a language. This allows a single, standard engine to match or merge any two CC statements
WSPL as currently specified in the XACML TC draft can be easily modified to be much more powerful and flexible. For example:
Multi-stage negotiation and encrypted sub-policies: can be supported by defining new policy combining algorithms that negotiate an "inner" policy only if "outer" policies have already been satisfied.
Arbitrarily complex preference handling: as in XACML 2.0, can be supported by defining new rule combining algorithms that use parameters attached to rules. This would allow a service broker to support "fair" merge algorithms.
Separation of binding mechanism from constraint expressions: WSPL's use of the XACML "Target" mechanism to specify bindings to portTypes, etc. is not essential to the constraint language itself.
Support for CCs expressed as XML schema elements: as in XACML, WSPL could use XPath expressions to extract primitive data type values from CCs defined as XML schema elements. A new function could allow multiple constraints on a single complex element.
Because we believe matching or negotiating mutually acceptable CCs between a client and service is the primary objective in stating CCs, we believe the use case should be expanded to include this function. Therefore, we address:
A Web service wishes to stipulate that clients are required 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. Such constraints and capabilities might be associated with the Web service via a SOAP header or a WSDL file.
A client wants to attach to such a service. This client supports reliable messaging, encryption with WS-Security using Kerberos, and is willing to accept either of two P3P policies. How does the client decide automatically whether the specified service meets its requirements, and where multiple choices are available, which to use?
A WSDL extension associated with the binding used by the service endpoint is used to contain the CC statements requiring reliable messaging and indicating support for the P3P policy.
<CC CCID="xxxx">
<and>
<function functionId="boolean-equal">
<Attribute AttributeId="Messaging:ReliableMessaging"/>
<AttributeValue>True</AttributeValue>
</function>
<function functionId="string-equal">
<Attribute AttributeId="Privacy:P3PPolicy/>
<AttributeValue>Y</AttributeValue>
</function>
</and>
</CC>
A WSDL extension associated with a specific binding operation is used to contain the CC statement requiring WS-Security encryption using X.509 or a user name security token.
<CC CCID="yyyyy">
<or>
<function functionId="string-is-in">
<Attribute AttributeId="WS-Security:EncryptionMethod"/>
<function functionId="string-bag">
<AttributeValue>X.509</AttributeValue>
<AttributeValue>UserNameToken</AttributeValue>
</function>
</function>
</or>
</CC>
A possible syntax example:
<ClientCC CCID="zzzz">
<BindingPoint>
<endpoint>[service endpoint]</endpoint>
<CC>
<and>
<function functionId="string-equal">
<Attribute AttributeId="Messaging:ReliableMessaging"/>
<AttributeValue>True</AttributeValue>
</function>
<function functionId="string-is-in">
<Attribute AttributeId="Privacy:P3PPolicy/>
<function functionId="string-bag">
<AttributeValue>X</AttributeValue>
<AttributeValue>Y</AttributeValue>
</function>
</function>
<or>
<function functionId="string-equal">
<Attribute AttributeId="WS-Security:EncryptionMethod"/>
<AttributeValue>Kerberos</AttributeValue>
</function>
</or>
</and>
</CC>
</BindingPoint>
<ClientCC>
In order to determine a mutually acceptable set of CCs, the service and client CC statements are first normalized into DNF ("or" of "and") using standard algorithms.
The CCs in the two normalized CC statements are now matched (see WSPL specification for details) to see if there are compatible CCs for the service as a whole and for the particular message header. Since the client does not specify different CCs for the message, the client's endpoint CCs are used when matching the service's message CCs.
In this case, the client and service do NOT have compatible CCs. While the client and service agree on reliable messaging, and the client accepts the service's P3P policy, the client encrypts all messages to this endpoint using Kerberos, while the service requires only a particular message to be encrypted, and then using either X.509 or a user name token.
CC statement composition and matching or merging using standard semantics, and thus standard code modules,
Support for multi-step negotiation,
Support for multiple levels of policy abstraction, and, if possible, for analysis of the correctness and completeness of the mappings between levels,
Message-component-specific CC statements,
Compatibility with existing WSDL binding mechanisms.
Support for binding CCs to things other than WSDL or SOAP headers, such as to/in messages such that message senders can convey the CC that they require to be applied in the responses,
Way to identify CC statements (such as an unforgeable identifier) that can be included in messages associated with those CCs.
Way to use the same CC statements (or same syntax) used to convey CCs from a service to a client to convey CC-related configuration information from a service deployer to a configurable service.
Way to test received messages against a CC to ensure they comply.