Emerging Technology Briefs: WSDL
Emerging Technology Briefs, developed by O'Reilly Research, offer a single-page summary of recent developments in a technology topic that we have been following. O'Reilly Research also publishes full-length industry reports, including "Planning for Web Services: Obstacles and Opportunities" by Clay Shirky, from which some of the material for this brief was drawn. The report's Executive Summary is available online.
Web Services Description Language (WSDL) describes the technical details of how a Web Service works, detailing the technical requirements for uses such as its Internet address and port, method names and associated arguments, data types, and so on.
WSDL is the de facto description mechanism in the current Web Services SOAP/WSDL/UDDI trinity (or quaternity if you assume HTTP as the default transport mechanism).
A WSDL document is composed of one or more service descriptions, each in turn composed of a collection of messages, port types, and bindings. A Message is an abstract description of what the exchanged data looks like. A Port Type is a collection of operations, not unlike a programming language library of functions. A Binding associates a Port Type with an appropriate transport protocol, the most common being HTTP.
The WSDL 1.1 specification exists as a World Wide Web Consortium (W3C) Note, co-submitted by representatives of Microsoft and IBM. While WSDL is not endorsed by the W3C as a standard, just about every player in the Web Services space has embraced WSDL and incorporated it into their frameworks and products.
While XML is the lingua franca of Web Services and SOAP provides the de facto packaging and encoding of structured data, neither speak to the semantics of exchanged data and remotely-called procedures.
Of course, one doesn't necessarily need yet another complex data format to expose or consume a Web Service; in many cases, a telephone call or some well-written documentation will do nicely. It's when one tries to automate Web Services and incorporate them into toolkits or applications that out of band developer-to-developer or business-to-business communication won't quite cut it.
Because a WSDL document produces a uniform XML-based technical description (as opposed to a simple but ad hoc description), a WSDL description can be both machine-readable and modified -- WSDL's native XML can be particularly hard on the eyes -- to be human-readable.
Given that a WSDL description is, after all, an XML document, one can simply build write one by hand. Its also rather easy to get away with consuming simple Web Services without need of WSDL descriptions at all. The majority of developers, however, make use of toolkits capable of reading and writing WSDL to take advantage of what they have to offer while abstracting away the majority of lower-level details.
WSDL support, while not nearly as ubiquitous as support for SOAP, is appearing at some level in many Web Services toolkits.
For instance, the Perl SOAP::Lite module constructs a local copy (a "proxy" or "stub") of a remote service object using the service's WSDL document as its template. The programmer then addresses requests to the local version, which in turn communicates silently with the remote server on the program's behalf. The following small snippet of sample code queries the Google search service:
Microsoft's .NET Web Services provide a collection of well-integrated tools and programming-language-level functions for consuming and producing WSDL documents.
WSDL 1.1, the version of WSDL in widespread use today, was published as a W3C Note in March of 2001 and may be taken, for all intents and purposes, to represent current thinking in Web Services description by the W3C's Web Services Activity.
The principal advantage of WSDL, as with SOAP, is its wide acceptance as a fundamental component of Web Services. Initial complaints about the complexity of writing WSDL documents have largely been set aside by toolkits producing WSDL automatically as a side-effect of building a Web Service.
One disadvantage of a WSDL file is that it separates service documentation from the service itself, thus creating additional work to discover technical specifications. It also creates a situation where the Web Service code itself can be updated without updating the WSDL file, a situation that would make WSDL files "stale," relative to the services they are describing. Some Web Services programming environments such as .NET attempt to undo this by automatically generating WSDL files.