Section 6.5. WSDL v2.0

6.5. WSDL v2.0

WSDL 1.1 was submitted to the W3C in late 2001, and the W3C Web Service Description Working Group was formed in early 2002 to standardize WSDL. WSDL 2.0 is the standard version of WSDL that the W3C is currently finalizing.

In many ways, WSDL 2.0 is a much simpler, less powerful, yet more usable service description language than WSDL 1.1.

6.5.1. Overall Language Structure

The basic structure of WSDL 2.0 is similar to WSDL 1.1, but it has some important and subtle differences. First, the language of 2.0 is defined in a syntax-independent manner using a WSDL component model. Although that does not directly affect end users of WSDL 2.0, it does affect tool builders and implementers. The overall syntactic structure is shown in Figure 6-2.

Figure 6-2. Syntactic structure of the WSDL 2.0 language.

A WSDL 2.0 document consists of a set of definitions contained within a <description> element. The biggest immediate syntactic difference is the elimination of the <message> construct. Instead, operation definitions now directly refer to XML Schema element declarations. Some of the more important changes are discussed in detail next.

6.5.2. Interface Extensions

Interface extensions in WSDL 2.0 allow you to define a new interface by extending one or more interfaces. This is similar to interface extensions in traditional object-oriented programming languages. One difference is that there is no notion of overloaded operations. However, this feature is likely to be used heavily, especially because of the change that a service must now implement exactly one interface. (See Section 6.5.5.)

6.5.3. Elimination of <message>

The <message> problems were dealt with by eliminating that construct. Instead, XML Schema global element declarations represent the information to be exchanged. Although that at first appears to support only XML structured data, extensions are also defined for XML Schema to allow first-class description of binary formats, such as MIME data. Thus, WSDL 2.0's default data structuring mechanism provides full support for XML and MIME structured data. Other forms must be handled via extensibility.

Eliminating the <message> construct has made it easy to bind WSDL operations to SOAP messages, thus eliminating a major point of pain from WSDL 1.1. At the same time, RPC-style operations must now be described with a somewhat second-class form (by indicating that the input and output element schemas have been defined to follow a certain style) as compared to WSDL 1.1. That was a conscious trade-off made with the belief that as Web services evolves, it will be centered more toward document exchanges than RPCs.

An example of an input-output operation is shown next.

 <interface name="ExampleInt">    <operation name="op1">       <input element="x:input-element"/>       <output element="y:output-element"/>    </operation> </interface> 

6.5.4. Message Exchange Patterns

WSDL 1.1 had somewhat arbitrarily chosen four message exchanges (one-way, request-response, output-only, and solicit-response) as the only interesting patterns of message exchange. In WSDL 2.0, this issue is completely clarified with the concept of message exchange patterns. An operation now conforms to a message exchange pattern and indicates one or more messages that will be sent or received during that exchange. The definition of the pattern indicates the order of the messages in addition to the source and destination.

WSDL 2.0 defines eight sets of patterns. However, only two are bound by the bindings included in the specification (in-only and in-out, which correspond to the one-way and request-response patterns of WSDL 1.1, respectively).

6.5.5. Services

Services in WSDL 2.0 have been defined with specific semantics to avoid the problems of WSDL 1.1. A service is now a collection of endpoints, in which all the endpoints implement the same single interface. An endpoint is what used to be called a port, but with cleaner semantics.

Restricting a service to support only one interface has given it strict semantics, but at the loss of some functionality. However, the introduction of interface extensions has recovered much of that loss.

An example of a service that offers an interface via two different bindings at two endpoints is given next.

 <service name="ExampleService"interface="x:ExampleInt">    <endpoint name="b1" binding="y:Binding1"               address="http://foo.com/bar1"/>    <endpoint name="b2" binding="z:Binding2"               address="mailto:[e-mail]"/> </service> 

6.5.6. Features and Properties

Features and properties are a controversial feature of WSDL 2.0. Features and properties associate nonfunctional characteristics of a service description to its WSDL description. For example, features and properties can indicate that a service requires authentication or that its messages must be sent reliably.

The controversy arises because of overlap with the WS-Policy family of specifications. (See Chapter 7, "Web Services Policy.") The authors of WS-Policy feel that such characteristics go beyond WSDL and are beyond the scope for the WSDL working group to produce.

As WS-Policy moves toward standardization, this overlap of functionality is expected to be resolved in favor of the WS-Policy approach for describing nonfunctional characteristics.