Web Services are not self-describing. A Web Service requires an additional file to describe its methods, parameters, and data types. This is the purpose of the Web Service Description Language - WSDL. Therefore, a WSDL document gives potential users of a Web Service all they need to know to access the Web Service including location, parameter information, and protocol support.
When potential users want to use a Web Service, they are pointed to the URI of the Web Service's WSDL document, either manually or through some automated mechanism (UDDI or DISCO). Typically, the software developer does not use a Web Browser to access the WSDL document and then manually creates code to access the Web Service (although this is possible). Instead, developers point their IDE to a WSDL file or use a utility that accesses the WSDL file, and then create code to access the Web Service according to the WSDL specification. This code is called the Web Service proxy. A Web Service proxy gives the programmer an easy way to interface with the Web Service by encapsulating the complexity of constructing the appropriate call and sending it to the network. From that point, there is no need for the WSDL file because the Web Service description is encoded in the proxy file:
Therefore, the WSDL file must always be a complete and accurate description of the Web Service is describes. If it is not, consumers will not be able to successfully access the Web Service.
In most cases, a WSDL file uses XML to describe its Web Service including its methods, method parameters, data types, and the network bindings and protocols that can be used to communicate with it. A WSDL file has five major sections plus the <definitions> element that wraps them together. These sections are described below:
This section defines which data types are used in the Web Service and where to find definitions for those types. In many cases, this section refers to the XML Schema Definition (XSD) type definitions.
This section abstractly defines the incoming and outgoing messages by grouping together the parts for that particular message. For example, a SOAP message sent as a Web Service request might be described like this:
<message name=""MyWebServiceSOAPIn">
<part name="parameters" element="s0:MyInput1"/>
<part name="parameters" element="s0:MyInput2"/>
<part name="parameters" element="s0:MyInput3"/>
<part name="parameters" element="s0:MyInput4"/>
</message>
This description enables the remainder of the document to reference the collection of parameters as MyWebServiceSOAPIn. It allows a degree of reuse in the document, thereby potentially making the document smaller.
This section creates an abstract definition that combines the protocol (SOAP, HTTP-Get, HTTP-Post) with the operations (function names) it supports and the messages used by those operations as defined in the Message section. Again, like the Message section, this section is a form of reuse. This combination of protocol, operation, and a message can be identified by a name. The following figure shows a visual representation of the relationship between the PortTypes section and the other sections of the WSDL document:
Bindings create a concrete relationship protocol (SOAP, HTTP-Get, HTTP-Post) with a data format for a particular port type. This section is where the PortType points to an actual URI for the transport mechanism (SOAP) or to the appropriate HTTP verb (Get or Post). Also, it's where you tell the Web Service clients how to package information they will be sending and receiving for a particular operation (method call). The following figure is a visual representation of the relationship between the Bindings section and other sections of the WSDL document:
Services bring together all the different ports with their concrete locations that are all considered part of the same service. In other words, Services section tells Web Service users that they can use different protocols to access the Web Service. It supplies the addresses to use when accessing each Web Service. The following figure is a visual representation of how the Services section relates to other sections of a WSDL file:
The <definitions> element primarily wraps all the other WSDL sections together, and establishes the namespaces for the most commonly used protocols, data types, schemas, and so on that are used in the remainder of the document. Remember that a namespace is just a qualifier used to remove ambiguity and avoid naming collisions. The URI for a namespace is not necessarily used to find special definitions or processing instructions for the document's parser.
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:s0="http://tempuri.org/"
targetNamespace="http://tempuri.org/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
...
</definitions>
The following code snippet shows an example of the Types section in a WSDL document:
<types>
<s:schema attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
<s:element
name="SquareValue">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="nNum" type="s:int" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="SquareValueResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="SquareValueResult" type="s:int" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="int" type="s:int" />
</s:schema>
</types>
Note that the Types section defines the data elements used in the remainder of the WSDL document in an XSD format, as indicated by the s: namespace qualifier that resolves to the XSD URI.
Note that the <s:schema /> element has several attributes. attributeFromDefault and elementFromDefault are set to qualified indicating that throughout the document, both elements and attributes must be qualified with a namespace. The targetNamespace attributes indicates that as elements are defined, they should be referenced by the namespace "http://tempuri.org" which is shortened to s0 as defined in the <Definitions> element at the beginning of the WSDL document.
Note that two data elements are defined as complex types and one data element is defined as a simple type. The main distinction between complex and simple types are their child elements and sub-nodes. simple types have neither.
Also note that the .NET Framework created SquareValue and SquareValueResponse automatically to describe the group of inputs (SquareValue) and outputs (SquareValueResponse) that were defined in the Web Service. These types will be used in the Messages section of the WSDL document.
The following code snippet is an example of a Messages section:
<!-- SOAP Messages -->
<message name="SquareValueSoapIn">
<part name="parameters" element="s0:SquareValue" />
</message>
<message name="SquareValueSoapOut">
<part name="parameters" element="s0:SquareValueResponse" />
</message>
<!-- HTTP Get Messages -->
<message name="SquareValueHttpGetIn">
<part name="nNum" type="s:string" />
</message>
<message name="SquareValueHttpGetOut">
<part name="Body" element="s0:int" />
</message>
<!-- HTTP Post Messages -->
<message name="SquareValueHttpPostIn">
<part name="nNum" type="s:string" />
</message>
<message name="SquareValueHttpPostOut">
<part name="Body" element="s0:int" />
</message>
There are six message tags, defining input and output messages for the protocol types made available in the Web Service (SOAP, HTTP-Get, HTTP-Post). Note that SOAP messages use the complex types defined in the Types section, whereas the Get and Post versions of the message use the simple type instead.
The messages defined here are used in the PortTypes section
<!-- SOAP -->
<portType name="Service1Soap">
<operation name="SquareValue">
<input message="s0:SquareValueSoapIn" />
<output message="s0:SquareValueSoapOut" />
</operation>
</portType>
<!-- HTTP Get -->
<portType name="Service1HttpGet">
<operation name="SquareValue">
<input message="s0:SquareValueHttpGetIn" />
<output message="s0:SquareValueHttpGetOut" />
</operation>
</portType>
<!-- HTTP Post -->
<portType name="Service1HttpPost">
<operation name="SquareValue">
<input message="s0:SquareValueHttpPostIn" />
<output message="s0:SquareValueHttpPostOut" />
</operation>
</portType>
The PortTypes section serves the purpose of associating an operation name with the input and output messages as defined in the Messages section.
<!-- SOAP -->
<binding name="Service1Soap"
type="s0:Service1Soap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
<operation name="SquareValue">
<soap:operation soapAction="http://tempuri.org/SquareValue" style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<-- HTTP Get -->
<binding name="Service1HttpGet"
type="s0:Service1HttpGet">
<http:binding verb="GET" />
<operation name="SquareValue">
<http:operation location="/SquareValue" />
<input>
<http:urlEncoded />
</input>
<output>
<mime:mimeXml part="Body" />
</output>
</operation>
</binding>
<!-- HTTP Post -->
<binding name="Service1HttpPost"
type="s0:Service1HttpPost">
<http:binding verb="POST" />
<operation name="SquareValue">
<http:operation location="/SquareValue" />
<input>
<mime:content type="application/x-www-form-urlencoded" />
</input>
<output>
<mime:mimeXml part="Body" />
</output>
</operation>
</binding>
The Bindings section serves to associate a <portType> element, a protocol, the operation name, and the actual message content's format. The Binding section deals with the concrete facts of how to interact with the Web Service. For this reason, the Bindings section is probably the most important section in the WSDL document.
<service name="Service1">
<!-- SOAP -->
<port name="Service1Soap" binding="s0:Service1Soap">
<soap:address location="http://localhost/Chapter4CS/Service1.asmx" />
</port>
<!-- HTTP Get -->
<port name="Service1HttpGet" binding="s0:Service1HttpGet">
<http:address location="http://localhost/Chapter4CS/Service1.asmx" />
</port>
<!-- HTTP Post -->
<port name="Service1HttpPost" binding="s0:Service1HttpPost">
<http:address location="http://localhost/Chapter4CS/Service1.asmx" />
</port>
</service>
The final section of the WSDL associates the bindings from the previous section with an acutal concrete URI. It also serves the purpose of tying together all the different binding into essentially the same service, called Service1 in this example.
The Bindings section of the WSDL document is different for the SOAP and the HTTP-based protocols. For example, the SOAP binding has information about the format of the SOAP message's body (whether encoded or not). The HTTP binding contains information about the verb (GET or POST) and the way the data should be packaged when sent or interpreted when received.