Web Services Description Language

from Wikipedia, the free encyclopedia
Web Services Description Language
File extension : .wsdl
MIME type : application / wsdl + xml
Developed by: World Wide Web Consortium
Container for: XML
Standard (s) : W3C WSDL 1.1
W3C WSDL 2.0

The Web Services Description Language ( WSDL ) is a platform, programming language and protocol-independent description language for network services ( web services ) for the exchange of messages on the basis of XML . WSDL is an industrial standard of the World Wide Web Consortium (W3C).


WSDL is a metalanguage that can be used to describe the functions, data, data types and exchange protocols offered by a web service . Essentially, the operations that are accessible from outside are defined, as well as the parameters and return values ​​of these operations. In detail, a WSDL document contains functional information on:

  • the interface
  • Access log and deployment details
  • All information necessary to access the service, in machine-readable format

However, it does not include:

Descriptive elements

Structure of a WSDL file

Services are defined by six main XML elements:

types ( data types )
Definition of the data types that are used to exchange the messages .
message (message)
Abstract definitions of the transmitted data, consisting of several logical parts, each of which is linked to a definition within a data type system.
portType (interface types )
A set of abstract operations (four types of messages exchanged):
  • One way: The service receives an input message from the client.
  • Request-response: The service receives a request (input message) from the client and sends a response (output message).
  • Solicit-response: The service sends a message and expects a response from the client.
  • Notification: The service sends an output message.
In WSDL 2.0 the name was changed to Interface.
binding (binding)
Determines the specific protocol and data format for the work steps and messages that are given by a certain port type.
port (port)
Specifies an address for a binding, i.e. a communication interface, usually a URI . In WSDL 2.0, the name was changed to Endpoint.
service (service)
Summarizes the set of ports of a port type.

In addition, these six main elements are divided into the group of abstract and concrete definitions.

Abstract definitions:

  • Types
  • Messages
  • PortTypes (from WSDL 2.0: Interfaces)

Concrete definitions:

  • Bindings
  • Ports (from WSDL 2.0: Endpoints)
  • Services

The definition of concrete content distinguishes WSDL from the existing interface description languages such as IDL . So far, these had only described the interfaces abstractly.


WSDL is often used in combination with SOAP and the XML schema to offer web services on the Internet. A client calling a web service can read WSDL to determine what functions are available on the server. All the special data types used are integrated in the WSDL file in XML form. The source code that is necessary to assemble the sent objects on the client side can be generated automatically from the WSDL file. The client can now use SOAP to ultimately call a function listed in WSDL.

Application example

An example is intended to illustrate how the individual sections of a WSDL document are linked to one another. In this example, a service is implemented that returns the current trading value of this share after receiving a share name.

 <definitions name="StockQuote"

       <schema targetNamespace="http://example.com/stockquote.xsd"
           <element name="TradePriceRequest">
                      <element name="tickerSymbol" type="string"/>
           <element name="TradePrice">
                      <element name="price" type="float"/>

    <message name="GetLastTradePriceInput">
        <part name="body" element="xsd1:TradePriceRequest"/>

    <message name="GetLastTradePriceOutput">
        <part name="body" element="xsd1:TradePrice"/>

    <portType name="StockQuotePortType">
        <operation name="GetLastTradePrice">
           <input message="tns:GetLastTradePriceInput"/>
           <output message="tns:GetLastTradePriceOutput"/>

    <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="GetLastTradePrice">
           <soap:operation soapAction="http://example.com/GetLastTradePrice"/>
               <soap:body use="literal"/>
               <soap:body use="literal"/>

    <service name="StockQuoteService">
        <documentation>My first service</documentation>
        <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
           <soap:address location="http://example.com/stockquote"/>



A function “GetLastTradePrice” is defined by the element <operation>inside <portType>, which receives input data ("input") and returns output data ("output"). Input data is the name of the share, output data is the value of the share. The order of the <input> and <output> elements specifies that this operation should become a request-response operation. If you change the order (e.g. first <output> then <input>) or if you leave out one of the two elements completely, the “Message Exchange Pattern (MEP)” also changes. This enables z. For example, you can also define operations that only issue a request and do not wait for a response.

As a programmer, you still have to determine which parameters are expected for the input and output. This is done through the <message>element. In our example, the “GetLastTradePrice” operation is referenced in the <input> tag to the “GetLastTradePriceInput” message.

In the <message>element, individual parameters are combined into a group so that they are available for several operations. In our example, the message element “GetLastTradePriceInput” has only one parameter <part>, which is of the type “TradePriceRequest”. The “GetLastTradePrice” operation therefore only needs one parameter. If within Message “GetLastTradePriceInput” would e.g. If, for example, another parameter is defined for stock exchange, our operation would require 2 parameters accordingly. As with a function, you can force the entry of these parameters with use="required"or use="optional"handle it optionally.

Now the types (string, integer, own type) have to be defined for the parameters. The types are defined separately within the <types>..</types>tags. Complex and simple data types can be defined in accordance with XSD . “TradePriceRequest” is a complex data type that expects a character string ("(character) string"). Presumably a complex type has been defined here for reasons of extension, although a simple data type character string would have sufficed.

Between <binding>..</binding>the message format and protocol is defined. The protocol is specified in the "transport" attribute, which in our example is SOAP . You can also specify whether the message should be sent in "rpc style" or "document style" and how the input and output should be coded. With the "document style" only data is sent to the responsible service ("service"), while with the "rpc style" a certain method including its parameters is sent, which is to be called at the end point.

In the element <service>, an end point "(port)" is by means of a bindings bound to our operations and set the address at which to this port can reach.

Stage of development

On March 15, 2001, the World Wide Web Consortium published the Web Service Description Language (WSDL) Note Version 1.1. Version 2.0 was published on June 26, 2007, which is divided into two parts for the language definition (“Core Language”) and additions (“Adjuncts”).

Extensions and delimitation to other developments

WSDL only specifies the syntactic elements of a web service, i. H. the way in which a client can access the corresponding web service. Semantic specifications of a web service going beyond this are often desirable, however; Information about the response time, costs of a service, security regulations and more precise specifications of the effects of an operation are required in particular for the automatic discovery and orchestration of services. To describe these parameters, there are extensions to WSDL such as WSDL-S or WSLA , on the one hand, and developments such as OWL-S or WSMO , which define ontologies for the semantic description of web services. These ontologies are much more powerful when describing web services, but they are correspondingly complex. In the OGSA (Open Grid Services Architecture), a standard description for grid services, GWSDL (Grid-extended WSDL) is defined as an extension that allows formalized service status (i.e. status of service instances) to be added to the interface definition .

See also

Web links