Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
WSDL Overview
Imagine that for whatever reasons, you have chosen to allow Web-based access to a set of services. Maybe you have e-commerce application or a simple API to a network enabled device. Depending on the request you may return a SOAP response, an XML document, or an image. How do you tell the user this information? You can use paper documentation and let the user program against that information. You can provide language specific libraries that create the requests the "right way." How do you describe the interface and data types to your clients? You have a few choices: either write your own interface description language (IDL) or use the Web Services Description Language (WSDL). Let's take a look at WSDL, an XML format for describing network-based services.
Some people in the SOAP community see WSDL as ornamentation for something that could be done with XML Schema Documents (XSD) alone. In a way, that faction is correct. You could specify the type data as well as incorporate some attributes or other elements into the schema that describes the Web service end-points. But, how would you build tools to use these specialized documents? Would you try to alter the XSD specification? Would you find some way of making a SOAP-specific extension to XSD to avoid altering XSD itself? When SOAP came out, we did not see a lot of acceptance of the "just XSD" approach. Instead, IBM, Microsoft, and other companies tackled the end-point definition problem by creating various SOAP definition document types. After just a few months of independent existence, these ideas were consolidated into WSDL. Why? The creators of the SOAP tools, Open Source advocates as well as corporate entities, wanted a way to specify the following things:
The exchange method (response/request, solicit/response, one-way, multicast, etc.).
The input and output message types (document or procedure oriented).
The location of the service (i.e. the endpoint).
Message schema.
Fault information.
The WSDL 1.1 specification is mute on the subject of how to discover the location of a WSDL document. The specification only details what the documents mean and how to compose them. Universal Description, Discovery and Integration (UDDI) provides the discovery mechanism, WSDL tells you how to use what you found. If you find yourself wondering why WSDL might be a good thing, you have not had to answer questions such as:
"How do I transmit an XML document as my sole response?"
"How do I send a picture as my response?"
"How do I send a gigabyte of data without base64 encoding it?"
You see, the SOAP specification never says that you can return something other than SOAP as a response. It never says you cannot do this either. For whatever reasons, many people have assumed that if SOAP goes out, SOAP must come back. WSDL clears up this misconception and provides a mechanism for you to tell your callers what to expect as a return value. It uses three existing specifications to do all this: SOAP 1.1, HTTP GET/POST, and MIME.
Many of the toolkits rely on WSDL files to let them create proxies to handle all the Web Service specific items. Some toolkits, such as SOAP::Lite and the Microsoft SOAP Toolkit v2 create these proxies at runtime. Others create the proxies using a tool and the developer includes the generated code in their project. One of the neat things about WSDL is that if it represents a standardized interface, the proxy can be used to access Web Services located on many different machines. For example, let's assume that meteorologists formulated an interface that allows clients to request the temperature in Celsius anywhere in the world by passing in a latitude and longitude value. As long as the interface requirements do not change, you only need to point your proxy at a different machine and it should continue to work. Most toolkits allow this behavior (i.e. the endpoint attribute can be modified at runtime).