Constraints and Capabilities for Web Services
Sun Microsystems, Inc. Position Paper

Copyright © 2004 Sun Microsystems, Inc. All Rights Reserved.

A. Introduction

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:

  1. Binding of constraints and capabilities to web service descriptions and protocols,
  2. Negotiation and composition of CCs
  3. Language for expressing CCs,

We then address an expanded use case with a specific proposal. The position paper concludes with a list of key requirements.

B. Bindings


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.

Levels of abstraction

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.

Binding of a CC statement to a SOAP header or WSDL file

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).

Client-side CC statements

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.

C. Negotiation and Composition

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.

Service Brokers

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.

Incremental negotiation

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.

D. Language

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:

E. Proposal

Use Case

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 possible syntax example:

<ClientCC CCID="zzzz">
      <endpoint>[service endpoint]</endpoint>
          <function functionId="string-equal">
            <Attribute AttributeId="Messaging:ReliableMessaging"/>
          <function functionId="string-is-in">
             <Attribute AttributeId="Privacy:P3PPolicy/>
             <function functionId="string-bag">
            <function functionId="string-equal">
              <Attribute AttributeId="WS-Security:EncryptionMethod"/>

Negotiation and composition mechanism

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.

F. Key requirements

Editor: Anne Anderson <Anne.Anderson@Sun.COM>
Updated: 04/08/27 (YY/MM/DD)
Version: 1.19