The W3C released WSDL 2.0 as a Candidate Recommendation on January 6, 2006. The Web Services Description Group, part of the Web Services Activity, made three main documents publicly available for review:
Part 0: Primer - Intended to be a less-technical introduction to the main concepts described in the Core Language.
Part 1: Core Language - Describes the elements for the abstract concepts and the constructs for binding concrete implementations found in the Adjuncts document.
Part 2: Adjuncts - Defines the predefined extension points and mechanisms for pairing WSDL with its most likely partners SOAP and HTTP.

The Candidate Recommendation, as a draft document, is intended for platform and tool vendors responsible for implementing the proposed standard. Implementations built using this version of the specification will help identify issues and potential gaps before the final specification is released. This draft release of the specification is also worthwhile for architects and developers to help them understand the promised capabilities assuming that the platforms and tools deliver.

The Highlights
The four years it took to bring the WSDL 2.0 specification to this point is indicative of how extensive it is. The main features that are introduced are:

• A Component Model that makes a distinction between abstract and concrete portions of a WSDL document.
• XML Schema is natively supported for Message Types.
• WSDL documents can be included and imported.
• XML Types can be included and imported.
• Interfaces serve as containers for faults and operations.
• Interfaces can inherit from each other.
• Message Exchange Patterns.
• Safe Operations.
• Bindings for SOAP 1.2 and HTTP 1.1.

The Component Model
By far the most interesting piece of WSDL 2.0 is the Component Model. It holds the promise of making services easier to describe and allowing those descriptions to be more readily reused. Unfortunately, what exactly defines a "Component Model" is not that easily understood. The specification states that it's a "set of components with attached properties, which collectively describe a Web Service." Yet there's no evidence provided demonstrating why WSDL 1.1 couldn't claim to have a component model. The difference is that the structure of the elements found in WSDL 2.0 directly maps to modern programming language constructs like interfaces, classes, properties, and methods. For tool developers, this property of WSDL 2.0 makes it significantly easier to generate a WSDL 2.0 document from a service implementation and to generate a service implementation from a WSDL 2.0 document. For service developers, it becomes much easier to look at their WSDL definition and understand how it maps to their code.

The Component Model consists of the following:

• Description
• Interface
• Service
• Endpoint
• Binding
• Feature
• Property

Description
This component serves as the root container for other components, most notably interfaces, bindings, and services. Abstract and concrete components are distinctly identified and separated. The service interfaces compose the abstract elements of the document with their respective messages and operations. The binding, service, and endpoints compose the concrete elements of the document. (See Figure 1)

Interface
This component serves as a container for operations, which in turn serves as a container for messages. The importance of this feature arises from the inclusion of Message Exchange Patterns (MEPs), since an operation can consist of more than simple request and response messages.

A discussion of the predefined Message Exchange Patterns and Fault Propagation Rules is included below. One of the most discussed features of WSDL 2.0 in the industry is the ability for interfaces to extend one another. This inclusion as a feature, along with the ability to include and import WSDL, certainly makes the job of tool developers more difficult. Yet interface inheritance should increase the reusability of interfaces across an organization. (See Figure 2)

Service
This component represents the collection of endpoints where the service may be invoked.

Initial thoughts may envision that the Service component contains the bulk of the specification. However, it mainly serves to tie the service interface to one or many endpoints implementing that interface. (See Figure 3)

Endpoint
This component represents a collection of information for a given service implementation. The endpoint ties a specific binding to the specific address so the service can be invoked.

Binding
This component represents the detailed information required to access an endpoint. The binding provides the glue the makes the whole system work and provides mechanisms for defining concrete formats for faults and messages and protocol interactions for interface operations.

Feature
This component represents functionality implemented by the services that may or may not be required by service requestors. Features are scoped to a given component when that component directly declares the feature, or when a contained component declares the feature, or when a referenced component declares the feature. If the feature is declared in multiple components that bring it in scope, then the feature must be active if any of the components specifies that it's required. An example of a feature may be declaring support for a duplex channel.

Property
This component represents an out-of-band parameter affecting the service's behavior, visible or otherwise. In combination with a secure message feature, a property contained by the feature can indicate the encryption algorithm.

Message Exchange Patterns
Operations in WSDL 2.0 specify one of eight defined message exchange patterns. As part of the abstract Interface component, the binding addresses the specifics regarding the synchronous or asynchronous exchange of messages and whether those messages are exchanged over a simplex or duplex channel. Each message pattern follows one of three fault propagation rules specified as part of the Adjuncts. Before looking at the message exchange patterns, it's necessary to become familiar with the fault propagations rules that they leverage. The three Fault Propagation Rules are:

• Fault Replaces Message
• Message Triggers Fault
• No Faults

These rules are intended to specify the recipient of the fault message, which may or may not be the service requestor. Overlap with WS-Addressing is apparent and the WSDL 2.0 specification states that WS-Addressing will be "used in lieu of the recipient nominated by the ruleset."

Fault Replaces Message
This behavior is accurately captured by the name. For any node that generates a fault after receiving a message, the next message in the message exchange pattern is simply replaced with the fault.

In more complex scenarios, the fault may not be sent to the original message sender. However, with the included Message Exchange Patterns that specify a Fault Propagation Rule other than "No Faults" the end result is that faults are returned to the original sender.

At first glance this behavior is counter-intuitive, especially for developers of the message-sending node. Yet further thought reveals that in a system of related services, it may be desirable for a concrete implementation of the sending node to delivers its message asynchronously. If a fault is generated, it may be another service that's responsible for taking corrective actions. (See Figure 4)

Message Triggers Fault
This behavior means that for any node that generates a fault after receiving a message, the fault is sent to the message sender. This ruleset differs from Fault Replaces Message in several ways. First, the fault is always sent to the sender of the message that generated the fault. This may or may not be the case in Fault Replaces Message. Second, in Fault Replaces Message a node can receive a Fault instead of an expected Message; while in a service using Message Triggers Fault, a node can receive a Fault even though it wasn't expecting a message in return. (See Figure 5)

No Faults
This behavior means that for any node that generates a fault after receiving a message, the fault is discarded. (See Figure 6)

With a basic understanding of the Fault Propagation Rules, the Message Exchange Patterns in WSDL 2.0 can now be analyzed. Each of the following Message Exchange Patterns references one of the previously defined Fault Propagation Rules:

• Inbound Patterns
  - In-Only
  - Robust In-Only
  - In-Out
  - In-Optional-Out
  
• Outbound Patterns
  - Out-Only
  - Robust Out-Only
  - Out-In
  - Out-Optional-In

In-Only
This pattern is intended for fire-and-forget services and is analogous to operations in WSDL 1.1 that failed to define an output message. By using the "No Faults" fault propagation ruleset, faults are discarded.