Messages are typically described using XML Schema [XML Schema], though other schema languages are permitted, as well as non-XML Infoset-based type systems.

For our example, we would define the following three messages:

<xs:schema targetNamespace="http://accurateweather.example/msgs"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="http://accurateweather.example/msgs"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">
  <simpleType name="FahrenheitDegree">
    <xs:restriction base="xs:decimal"/>
  </simpleType>
  <xs:element name="location">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="country" type="xs:string"/>
        <xs:element name="state" type="xs:string"/>
        <xs:element name="city" type="xs:string"/>
      </xs:sequence> 
    </xs:complexType>
  </xs:element>
  <xs:element name="temperature">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="location"/>
        <xs:element name="date" type="xs:dateTime"/>
        <xs:element name="value" type="FahrenheitDegree"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="temperatureOk">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="valid" type="xs:boolean"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

An interface describes the set of messages that a service agent sends and receives. Related message are logically grouped in interface operations.

An operation is an interaction with the service consisting of a set messages exchanged between the service and the other roles involved in the interaction, in particular the service requester. There exists two types of messages: ordinary messages, and fault messages that may be generated as a result of an event occurring during the execution of a message exchange that disrupts the normal flow of messages.

<interface name="GetTemperature">
  <operation name="location" safe="true"
             pattern="http://www.w3.org/2004/08/wsdl/in-out"
             style="http://www.w3.org/2004/08/wsdl/style/uri-style">
    <input messageLabel="In" element="s:location"/>
    <output messageLabel="Out" element="s:temperature"/>
  </operation>
</interface>
<interface name="CompleteInterface" extends="m:GetTemperature">
  <operation name="set" pattern="http://www.w3.org/2004/08/wsdl/in-out">
    <input messageLabel="In" element="s:temperature"/>
    <output messageLabel="Out" element="s:temperatureOk"/>
  </operation>
</interface>

WSDL 2.0 describe a service from the point of view of the service itself. Messages are going in (input messages) and out (output messages). The sequence and cardinality of abstract messages listed in an operation is called a message exchange pattern (MEP). Unlike WSDL 1.1, [WSDL Version 2.0: Predefined Extensions] carefully describe the sequence, direction (in or out) and cardinality of the messages that are involved in the exchange, as well as identifying the parties involved. The eight following MEPs are defined in [WSDL Version 2.0: Predefined Extensions]:

Other MEPs may be defined and used by an interface operation.

WSDL 2.0 includes the concept of operation style in order to apply restrictions to an operation. An operation style asserts that message schemas in a particular operation conform to certain rules.

[WSDL Version 2.0: Core] defines an RPC style for such interactions. [WSDL Version 2.0: Bindings] defines URI and Multipart styles in order to specify constraints to be able to express messages in a request URL or as a POSTed form when using HTTP/1.1.

WSDL 2.0 allows an interface to extend one or more other interfaces. In such cases, the interface contains the interface operations of the interfaces it extends, along with any additional operations it defines.

An interface can reuse the definitions of operations from other interfaces using the derivation mechanism, but operation overloading is not allowed.

WSDL 2.0 allows one to specify that an operation is safe, i.e. that the requester agent does incur any obligation beyond the interaction or not (see Example 2, “Definition of the weather service interface”).

This is useful as hints to the bindings: for example, an safe operation may be bound to an HTTP GET request (see Example 5, “HTTP binding of the GetTemperature interface”). One can also foresee optimizations such as caching, pre-fetching and re-fetching of information, etc.

[WSDL Version 2.0: Predefined Extensions] defines the Application Data Feature (see also the section called “Features and properties”) to enable the description of application-defined additional data declarations outside of the normal data channel (e.g. the SOAP body).

This allows to express additional information in SOAP 1.2 or HTTP headers. Bindings to other protocols may be defined.

The WSDL 2.0 specification provides a binding for the SOAP Version 1.2 Recommendation [SOAP Version 1.2], which did not exist in WSDL 1.1. The use of SOAP Version 1.2 modules can be specified, and the new fault description format provided by SOAP 1.2 is supported.

SOAP messages being transferable by a variety of underlying protocols, the WSDL SOAP 1.2 binding allows one to specify which underlying protocol should be used. The binding specification in [WSDL Version 2.0: Bindings] also defines the use of HTTP as an underlying protocol, reusing some properties of the new HTTP binding (see the section called “HTTP binding”).

Below is an example of the use of the SOAP 1.2 binding.

<binding name="SoapBinding" interface="m:CompleteInterface"
	 type="http://www.w3.org/2004/08/wsdl/soap12"
         wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"/>
  <operation ref="m:location"/>
  <operation ref="m:set">
    <input messageLabel="In">
      <wsoap:module uri="http://accurateweather.example/mySecurityExtension"/>
    </input>
    <output messageLabel="Out"/>
  </operation>
</binding>
<service>
  <endpoint name="SoapEndpoint" binding="m:SoapBinding"
            address="http://ws.accurateweather.example/set"/>
</service>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
  <env:Header>
    <m:sec xmlns:m="http://accurateweather.example/mySecurityExtension/h">
      <proofOfId>eotnhu934bmubutnadp32hdpugeaoduhue</proofOfId>
    </m:sec>
  </env:Header>
  <env:Body>
    <temperature xmlns='http://accurateweather.example/msgs'>
      <location>
        <country>USA</country>
        <state>MA</state>
        <city>Cambridge</city>
      </location>
      <date>2004-08-06T19:37:37Z</date>
      <value xsi:type='FahrenheitDegree'>70</value>
    </temperature>
  </env:Body>
</env:Envelope>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
  <env:Body>
    <temperatureOk xmlns='http://accurateweather.example/msgs'>
      <valid>true</valid>
    </temperature>
  </env:Body>
</env:Envelope>

For backwards compatibility purposes, the Working Group will be providing a SOAP 1.1 over HTTP binding. This specification is still under development.

The HTTP binding has been completely reworked in WSDL 2.0.

All HTTP methods are supported (GET, POST, PUT, DELETE, …). One can specify the input and output serialization, describe available transfer codings, and authentication requirements from [IETF RFC 2616], as well as whether HTTP cookies [IETF RFC 2965] are required.

The HTTP binding also provide a URL replacement syntax to serialize a message in the request URL, as illustrated in Example 5, “HTTP binding of the GetTemperature interface” and Example 6, “Example interaction using the HTTP binding”.

<binding name="HttpBinding" interface="m:GetTemperature">
  <operation ref="m:location" whttp:method="GET"
             whttp:location="{country}/{state}/{city}"/>
</binding>
<service>
  <endpoint name="HttpEndpoint" binding="m:HttpBinding"
            address="http://ws.accurateweather.example/"/>
</service>

http://ws.accurateweather.example/USA/MA/Cambridge

<temperature xmlns='http://accurateweather.example/msgs'>
  <location>
    <country>USA</country>
    <state>MA</state>
    <city>Cambridge</city>
  </location>
  <date>2004-08-06T19:37:37Z</date>
  <value xsi:type='FahrenheitDegree'>70</value>
</temperature>

WSDL 2.0 uses an open-content model which allows both elements and attributes from other namespaces to be used in a WSDL 2.0 document. This will result in additional properties appearing in the component model.

Extension elements can be marked as mandatory by annotating them with a wsdl:required attribute. The meaning an an element containing a mandatory extension is governed by the meaning of that extension.

Features and properties are the generalization of the SOAP features defined by [SOAP Version 1.2].

A feature component describes an abstract piece of functionality typically associated with the exchange of messages between communicating parties. A "property" in the Features and Properties architecture represents a named runtime value which affects the behavior of some aspect of a Web service interaction.

WSDL 2.0 allows the specification of features and properties in each of the component of the model.