WSDL

WSDL stands for Webservice Description Language. It's an XML format which is used to document Webservices. WSDL contains everything what one requires to invoke a webservice. It has the location of the service. The operation that needs to be invoked and what kind of message needs to be send as part of request and what message one can expect as part of response. The message can be in SOAP format however WSDL is written in such a way that it can send the message in other format also. WSDL is meant for programmatic consumption. An application can read a WSDL and can generate the artifacts which can help it to call the web service. Let's look in a sample WSDL which is generated for webservice to convert Celsius to Fahrenheit and vice-versa

The WSDL file is as shown below:

<definitions targetNamespace="http://ws.lalit.com/" name="TemperatureConvertorService">

<types>

  <xsd:schema>

     <xsd:import namespace="http://ws.lalit.com/" schemaLocation="http://localhost:8081/tempConv?xsd=1"/>

   </xsd:schema>

</types>

<message name="celsiusToFarenheitOp">

   <part name="parameters" element="tns:celsiusToFarenheitOp"/>

</message>

<message name="celsiusToFarenheitOpResponse">

   <part name="parameters" element="tns:celsiusToFarenheitOpResponse"/>

</message>

<message name="farenheitToCelsiusOp">

   <part name="parameters" element="tns:farenheitToCelsiusOp"/>

</message>

<message name="farenheitToCelsiusOpResponse">

   <part name="parameters" element="tns:farenheitToCelsiusOpResponse"/>

</message>

<portType name="TemperatureConvertor">

   <operation name="celsiusToFarenheitOp">

      <input message="tns:celsiusToFarenheitOp"/>

      <output message="tns:celsiusToFarenheitOpResponse"/>

   </operation>

   <operation name="farenheitToCelsiusOp">

      <input message="tns:farenheitToCelsiusOp"/>

      <output message="tns:farenheitToCelsiusOpResponse"/>

   </operation>

</portType>

<binding name="TemperatureConvertorPortBinding" type="tns:TemperatureConvertor">

   <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>

   <operation name="celsiusToFarenheitOp">

   <soap:operation soapAction=""/>

      <input>

         <soap:body use="literal"/>

      </input>

      <output>

         <soap:body use="literal"/>

      </output>

    </operation>

    <operation name="farenheitToCelsiusOp">

       <soap:operation soapAction=""/>

       <input>

          <soap:body use="literal"/>

       </input>

       <output>

          <soap:body use="literal"/>

       </output>

    </operation>

</binding>

<service name="TemperatureConvertorService">

   <port name="TemperatureConvertorPort" binding="tns:TemperatureConvertorPortBinding">

      <soap:address location="http://localhost:8081/tempConv"/>

   </port>

</service>

</definitions>

WSDL contains the following 7 elements as part of XML:

• types
• import
• message
• portType
• operations
• binding
• service

These elements are wrapped inside the root element definitions.

In the above XML the defintions is the top level element.

<definitions targetNamespace="http://ws.lalit.com/" name="TemperatureConvertorService">

types

In types, the element types are defined. These types are used to exchange the message between client and server. In the example above the types defined are:

<types>

  <xsd:schema>

     <xsd:import namespace="http://ws.lalit.com/" schemaLocation="http://localhost:8081/tempConv?xsd=1"/>

  </xsd:schema>

</types>

Here the schema is defined in another xsd which can be accessed at http://localhost:8081/tempConv?xsd=1

<xs:schema version="1.0" targetNamespace="http://ws.lalit.com/">

<xs:element name="celsiusToFarenheitOp" type="tns:celsiusToFarenheitOp"/>

<xs:element name="celsiusToFarenheitOpResponse" type="tns:celsiusToFarenheitOpResponse"/>

<xs:element name="farenheitToCelsiusOp" type="tns:farenheitToCelsiusOp"/>

<xs:element name="farenheitToCelsiusOpResponse" type="tns:farenheitToCelsiusOpResponse"/>

<xs:complexType name="farenheitToCelsiusOp">

  <xs:sequence>

    <xs:element name="arg0" type="xs:double"/>

  </xs:sequence>

</xs:complexType>

<xs:complexType name="farenheitToCelsiusOpResponse">

  <xs:sequence>

    <xs:element name="return" type="xs:double"/>

  </xs:sequence>

</xs:complexType>

<xs:complexType name="celsiusToFarenheitOp">

  <xs:sequence>

    <xs:element name="arg0" type="xs:double"/>

  </xs:sequence>

</xs:complexType>

<xs:complexType name="celsiusToFarenheitOpResponse">

  <xs:sequence>

    <xs:element name="return" type="xs:double"/>

  </xs:sequence>

</xs:complexType>

</xs:schema>

import

In the WSDL above there is no import element. The import element is used to bring the details from another WSDL defined by import. This import is different from the import we saw above in types section. The types section import is used to bring schema definitions of types. The WSDL import element must declare two attributes: namespace and location. The value of namespace must match the targetNamespace declared by the WSDL document imported. The location attribute must point to an actual WSDL document and cannot be empty or null.

message

message element describe the payload of the message used by webservices.The message element can be a request or a response. This distinction is done at operation.

<message name="celsiusToFarenheitOp">

   <part name="parameters" element="tns:celsiusToFarenheitOp"/>

</message>

<message name="celsiusToFarenheitOpResponse">

   <part name="parameters" element="tns:celsiusToFarenheitOpResponse"/>

</message>

<message name="farenheitToCelsiusOp">

   <part name="parameters" element="tns:farenheitToCelsiusOp"/>

</message>

<message name="farenheitToCelsiusOpResponse">

   <part name="parameters" element="tns:farenheitToCelsiusOpResponse"/>

</message>

The webservice style (RPC or Document) do differentiate here that how we are going to define part. In this case which is document type, the part is defined by using element. In case of RPC style the message definition would look like

<message name="GetProductPriceResponse">

   <part name="price" type="xsd:float" />

</message>

type is used to define the part.

portType and operation

The simplest analogy to port Type and operation is the interface and its operation in Java.Most of code generators map the WSDL in the similar way.

<portType name="TemperatureConvertor">

   <operation name="celsiusToFarenheitOp">

      <input message="tns:celsiusToFarenheitOp"/>

      <output message="tns:celsiusToFarenheitOpResponse"/>

   </operation>

   <operation name="farenheitToCelsiusOp">

      <input message="tns:farenheitToCelsiusOp"/>

      <output message="tns:farenheitToCelsiusOpResponse"/>

   </operation>

</portType>

operation uses message to define the request and response. As mentioned earlier, here we decide whether the message acts as a request or as a response. WSDL supports operation overloading similar to Java method overloading. Two operations may have same name, provided their input and output message differ. However this does not conforms to Basic Profile. Two or more porttypes can however define operation with same name. It's like having two different interfaces with same operation name.

binding

binding is the place where we attach the message to protocols. In this case we are binding the webservice with SOAP over HTTP.

<binding name="TemperatureConvertorPortBinding" type="tns:TemperatureConvertor">

   <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>

      <operation name="celsiusToFarenheitOp">

         <soap:operation soapAction=""/>

         <input>

            <soap:body use="literal"/>

         </input>

         <output>

            <soap:body use="literal"/>

         </output>

      </operation>

    <operation name="farenheitToCelsiusOp">

        <soap:operation soapAction=""/>

        <input>

           <soap:body use="literal"/>

        </input>

        <output>

           <soap:body use="literal"/>

        </output>

    </operation>

</binding>

This piece confuses a lot but just take it in this way that WSDL designers attempted to make the definition very generic so that the message can travel on any protocol. With binding you can make it to travel with SOAP on HTTP or anything else.Also binding element tells about RPC or Document style. With frameworks like JAX-WS the debate between RPC and Document style is more theoretical. Also the encoding style is defined here. Basic Profile only accepts literal style as encoding brings problem in interoperability.

service

service element is the place where we define the physical location of the webservice as per the binding.

<service name="TemperatureConvertorService">

   <port name="TemperatureConvertorPort" binding="tns:TemperatureConvertorPortBinding">

      <soap:address location="http://localhost:8081/tempConv"/>

   </port>

</service>

Please see the video also for the concepts