As we've done with SOAP and WSDL, IBM, Microsoft, and our partners have followed the design principle of "composability" in the definition of Web service specifications. Each specification we developed solves an immediate need and is valuable in its own right. For example, developers can adopt reliable messaging to simplify their solution development or adopt BPEL4WS to define their service compositions. And while each specification stands on its own, they are designed to be combined and work with each other.

We use the term composability to describe independent specifications that can be combined to provide more powerful capabilities. That way, operating system and middleware providers can support composed capabilities. For instance, providers can integrate reliable messaging support for communicating BPEL4WS processes. This example combines two independent specifications to simplify the development of communicating processes by eliminating the need to handle message communication errors during process design.

Composability enables incremental consumption or progressive discovery of new concepts, tools and services. Developers only need to learn and implement what is necessary, and no more. The complexity of the solution increases only because the problem's requirements increase, and is not due to technology "bloat."

Composability has and continues to be one of the key design goals for Web services. Over the last several years we have defined the most basic Web service specifications (SOAP and WSDL) to inherently support composition. One of the fundamental characteristics of a Web service is a regular, multi-part message structure. This structure enables the composition of new functionality. New message elements supporting new services may be added to messages in a manner that does not alter the processing of existing functionality. For example, it is possible to independently add transaction identifiers and reliable messaging sequence numbers. The two extensions do not conflict with each other and are compatible with pre-existing message structures.

Figure 1. Composability allows for using elements on an as-needed basis.

Figure 1 shows a simple Web services message that contains elements for WS-Addressing, WS-Security, and WS-ReliableMessaging. Notice that the WS-Addressing, WS-Security and WS-ReliableMessaging elements can be used independently without altering the processing of other elements.

This characteristic enables security, reliability, and transactions to be defined in terms of composable message elements.

The notion of composition also allows for the creation of a specific set of well-defined composable Web services that support security, reliability, etc. These well-defined services specify the behavior of services necessary to support higher-level Web service functionality. An example is the Secure Token Service defined in WS-Trust that issues and validates security elements in messages.

Moreover, it is important that consumers of a service be able to determine the supported and required service assurances. The services must document their requirements and support for transactions, security, reliable messaging, etc. WS-Policy enables Web services to incrementally augment their WSDL to document what transaction, security and reliability functions they support or require. WSDL and WS-Policy enable composition for the description of services. This in turn enables the other parties to understand what message elements and higher-level services to employ when interacting with the service.

Note: As Web service specifications are being updated continuously, this section describes the specifications with a notion of composability. CSF adheres to WSE 2.0 SP3 implementation of Web service stack.