Web Services Description Language
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).
Content
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:
- Quality of Service information
- Taxonomies / ontologies for the semantic classification of the service
Descriptive elements
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.
application
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"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<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"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>
Explanation
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
- WS- * - Collection of standards that modularly expand SOAP / WSDL
- WS-Business Process Execution Language (WS-BPEL) - XML-based language for describing business processes
- Business Process Modeling Language - XML-based, platform-independent metalanguage for describing business process models
- semantic web - expansion of the World Wide Web (WWW) with machine-readable data
- Universal Description, Discovery and Integration (UDDI) - standardized directory service in the context of dynamic web services
- Web Application Description Language (WADL) - a simple alternative to WSDL for XML / HTTP applications
Web links
- W3C description of WSDL 1.1 ( Memento from December 24, 2006 in the Internet Archive )
- W3C description of WSDL 2.0
- W3C WSDL Validator
- WSDL Reading for Beginners An introduction