Web Service Description Language (WSDL) represents an IDL describing the contract between the service requestor and the service provider in much the same way that a Java interface represents a contract between client code and an actual Java object. The crucial difference is that WSDL is platform- and language-independent and used primarily (although not exclusively) to describe SOAP services.

The WSDL 1.1 specification has been accepted at the World Wide Web Consortium (W3C) and is the predominant version for describing Web Services today. At W3C, work on the next generation of WSDL, i.e., version 2.0, has been under way for some time now. WSDL 2.0 promises to describe not only traditional SOAP Web Services, but also a wide variety of services provided over any network. W3C has published the Candidate Recommendation for WSDL 2.0. WSDL 2.0 is substantially different from WSDL 1.1. In this article, we'll dissect the WSDL 2.0 spec and point out the overall differences and some core benefits of the WSDL 2.0 specifications. We'll also point out the interoperability issues with WSDL 1.1 and detail InfWVM, a framework for seamlessly working with WSDL irrespective of the version.

The Structure of WSDL 2.0
There are significant differences between WSDL 2.0 and WSDL 1.1. WSDL 2.0 has three specifications:

• Core, which explains the abstract interfaces independent of protocol and encoding;
• Message Exchange Patterns (MEP) with predefined types of interactions; and
• Bindings pertaining to SOAP and HTTP.

In the concrete element of the description, bindings denote the transport and wire formats for interfaces. A service endpoint associates the network address with a binding. Finally, a service clusters the endpoints that implement a common interface. Figure 1 shows the conceptual WSDL component model.

Further, different operation styles and message exchange patterns can be defined and a wide variety of message definition languages can be used in addition to XML Schema, with messages bound to any protocol for which a binding specification has been written.

Modifications in WSDL 2.0
Listed below are some of the major modifications introduced in WSDL 2.0 specification

• WSDL 2.0 is infoset-based, which is more precise and heavily oriented to a component-based structure.
• An XML Information Set (Infoset) provides a reliable set of information definitions, with up to 11 different types of information items, as explained in the W3C specification at www.w3.org/TR/xml-infoset/. There is no requirement for an XML document to be valid to have information set. WSDL 2.0 provides a set of components and their associated properties for describing Web Services.
• WSDL 2.0 includes additional semantics. Hence, targetNamespace is a required attribute of the description element in WSDL 2.0, as shown in Listing 1.
• WSDL 2.0 adds the capability of including documents. Different service definition components of the same target namespace are allowed to exist in separate WSDL documents (which can be used across various service descriptions) using of include element.
• WSDL 2.0 supports additional Message Exchange Patterns or patterns. WSDL patterns define the sequence, direction, and cardinality of abstract messages sent or received by an operation.
• WSDL 2.0 has introduced the idea of Interfaces, replacing PortType. The interface operation element has name and pattern as required attributes.
• The concept of interface inheritance is also introduced in WSDL 2.0. One interface can extend one or more interfaces (multiple inheritance). This adds one more layer of reusability.
• WSDL 2.0 introduces the concept of features.The presence of a feature component in a WSDL 2.0 description indicates that the service supports the feature and may require that a client that interacts with the service use that feature.
• WSDL 2.0 supports the use of other type systems (it already supports XML Schema). Schemas are embedded into the types element of the WSDL document. Constructs in semantic models such as classes in OWL ontologies could be used to define the Web Service input and output data types.
• WSDL 2.0 also introduces the idea of operation style to apply restrictions to an operation.

• All WSDL constructs have been made extensible via both elements and attributes. WSDL 2.0 provides two extensibility mechanisms: an open content model thatallows XML elements and attributes from other (non-WSDL) XML namespaces to be interspersed into a WSDL document and via features and properties. Both mechanisms use URIs to identify the semantics of the extensions. For extension XML elements and attributes, the namespace URI of the extension element or attribute acts as an unambiguous name for the semantics of that extension. For features and properties, the feature or property is named by a URI.
• Legacy type definitions like DTD and RelaxNG, which have been in the industry a long time, have been made reusable with support for these definition types in the type definition. It gives an additional level of support for other semantic concepts in the future, e.g. OWL classes. This addresses a key restriction in WSDL 1.1 in the type definition.
• The lack of interface reusability was one of the major drawbacks of WSDL 1.1 that's addressed by WSDL 2.0. In WSDL 1.1 if we need to deploy an operation across multiple interfaces, it has to be replicated. Even the interfaces declared across different documents can be reused in the existing documents via import or include mechanisms in WSDL 2.0.
• Multiple services can be declared in the same document, which helps to explore more than one service out of a single WSDL.
• Previously, since WSDL 1.1 wasn't component-based, instances were used as singletons. Moreover, the component-based WSDL 2.0 has added more compatibility and support for Grid Services, based on a specialized GWSDL, which were started based on WSDL 1.1.
• Ambiguity in defining operations has been removed by making Qname, i.e, (namespace, local name) tuple unique.
• The inadequacy of the fault description supported by SOAP 1.1 is addressed and replacedment by the SOAP 1.2 fault format.
• In operations, WSDL 1.1 had no mechanism to enforce any restrictions, a shortcoming that is also addressed by 2.0. It includes the concept of operation style to apply restrictions to an operation. An operation style asserts that message schemas in a particular operation conform to certain rules.

  Even though 'import' provides a mechanism to get the definitions from a different target space, there was no mechanism available to get the definitions from the same target space. This has been addressed by 'include' in WSDL 2.0

• WSDL 1.1 had hardwired support for Message Exchange Patterns (MEPs). Only four types of MEPs were supported:
  - Input-output
  - Output-input
  - Input only
  - Output only

  These MEPs corresponded roughly to thefollowing traditional interaction patterns:
  - Request-Response
  - Publish-Subscribe
  - One-way invocation
  - Event

  WSDL 2.0 supports additional MEPS or patterns. It supports the following eight patterns:
  1.  In-only -> consists of only a single message.
  2.  In-out -> consists of an input message followed by an output message.
  3.  Request-Response -> is identical to an in-out pattern except that the in-out message travels on the same channel.
  4.  In-multi-out -> consists of an input message followed by one or many output messages.
  5.  Out-only -> consists of only an output message.
  6.  Out-in -> consists of an output message followed by an input message.
  7.  Out-multi-in -> consists of an output message followed by multiple input messages.
  8.  Multicast-solicit-response -> consists of an input message followed by one or two input messages.
  

• WSDL 1.1 didn't support any mechanism for capturing the non-functional requirements of a service. WSDL 2.0 features are introduced for annotating with non-functional or specialized characteristics. WSDL 2.0 features might include "reliability," "security," "correlation," and "routing" related details. The presence of a feature component in a WSDL 2.0 description indicates that the service supports the feature and may require that a client that interacts with the service use that feature. Each feature is identified by its IRI. WSDL2.0's feature concept is derived from SOAP 1.2's abstract feature concept. The feature looks like Listing 2:
• The SOAP binding for WSDL 2.0 is much simpler and it's easier to write bindings than with WSDL 1.1. The HTTP and XML binding in WSDL 2.0 has also been improved.

In the case of exposing an already existing service using the WSDL 2 specification, one might just have to convert the old WSDL to the new WSDL 2 specification and re-host the WSDL. Since the SOAP engine on the sever side hosting the service doesn't require the WSDL to do its processing, there seems to be no interoperability issues associated with it. Nevertheless, most SOAP engines support automatic generation of the WSDL once a service is deployed. Hence there might be a need to generate WSDL based on the WSDL 2 specification. But this component will be independent of other SOAP engine components and hence can be made available as a plug-in component from SOAP engine vendors and plugged into any of their existing versions of the SOAP engines.