The Web Services Advisor
(Edit your profile to receive in your inbox.)
An inside look at WSDL
In order for a person or company to run a Web service, basic information about that Web service needs to be provided - information such as where the service is located, how the service can be bound to, and similar information. All this information is provided by a Web Services Description Language (WSDL) document. In this column, we'll take a look at what WSDL is, how it works, and what the future may hold for WSDL.
What is WSDL?
Let's start off with the basics. WSDL is an XML-based language used to create documents that provide vital information about how Web services can be located and run. The person or company looking to run a Web service is called a requestor. In order to run a Web service, a requestor first needs to locate the WSDL document that details how to run the services. Once the document is found, it's downloaded to the requestor. The WSDL document is then examined, and based on what is found in it, a SOAP request or requests is sent out to the Web service provider. That service then sends the information requested - in essence the Web service itself - using the SOAP protocol. The nearby figure shows how all this fits together.
A requestor can get a WSDL document in a number of different ways. The document may be located in a searchable, public UDDI directory. In that instance, anyone can go to the directory, search for a Web service, and then run it.
That's rarely done today, though, because UDDI directories are rare. And even in the future, when UDDI becomes more commonplace, there will be other ways that WSDL documents can be found. WSDL documents can be located in a variety of ways, including via HTTP requests, FTP, and even via email. They can also be found in private UDDI directories. In many cases, when the Web service is one set up privately between partners, it won't be done via public UDDI directories.
A look inside a WSDL document
A WSDL document describes what a Web service is, details where the service can be located, and then provides specific instructions on how that service can be bound to and run.
In order to do that, a WSDL document includes a number of different important elements. I don't have space to go into details on every different element in a document here, but among the most important ones are:
- <type> and <message> elements These describe the information to be passed in the Web service. The <message> element is in essence the Web service itself - the information that is going to be exchanged or requested.
- <binding> This details how information is going to be passed between the requestor and the Web service, and includes information such as the protocol and data format.
- <portType> This describes the operations that will be supported by the Web service.
- <service> This details the location of the Web service.
This all may seem rather abstract, so to understand it better, let's take a look at a WSDL document. The follow WSDL document was created by the W3C, the standards-setting body of the Internet, as a way of showing how WSDL works. It details a simple Web service that provides stock quotes. The Web service performs a single operation, GetLastTradePrice, and it is deployed using the SOAP protocol.
Here's the WSDL document:
<?xml version="1.0"?> <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="https://www.w3.org/2000/10/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:StockQuoteBinding"> <soap:address location="http://example.com/stockquote"/> </port> </service> </definitions>
As you can see, it's XML-based. Take a few minutes to examine it; you won't need to know XML or WSDL intimately in order to get the gist of it. In particular, look at the <types> and <message> elements to see the kind of information that will be requested and passed. Notice how <binding> details the transport mechanism (in this instance, SOAP) and similar details. See how <portType> describes the message and operation to be performed. And notice how the <service> area gives the location of the service itself.
Where WSDL is today
WSDL has not been finalized as a standard yet by the W3C, and the most recent version of it is 1.1, submitted a little over a year ago. To see the latest version of WSDL from the W3C, head to https://www.w3.org/TR/wsdl. But while it might not yet be accepted as a standard, you can safely use it to develop Web services today, because it has become so commonly accepted.
That's not to say that WSDL isn't without controversy. It was developed jointly by IBM and Microsoft, and their sheer market presence and backing have been able to make it into a de facto standard. There are those who believe that WSDL is unnecessary for creating and deploying Web services, though, and that other ways could ultimately prove more efficient. But none have come forward, and for the foreseeable future, WSDL will remain at the heart of the Web services world.
About the Author
Preston Gralla, a well-known technology expert, is the author of more than 20 books, including "How the Internet Works," which has been translated into 14 languages and sold several hundred thousand copies worldwide. He is an expert on Web services and the author of a major research and white paper for the Software and Information Industry Association on the topic. Gralla was the founding managing editor of PC Week, a founding editor and then editor and editorial director of PC/Computing, and an executive editor for ZDNet and CNet. He has written about technology for more than 15 years for many major magazines and newspapers, including PC Magazine, Computerworld, CIO Magazine, eWeek and its forerunner PC Week, PC/Computing, the Los Angeles Times, USA Today, and the Dallas Morning News among others. As a well-known technology guru, he appears frequently on TV and radio shows and networks, including CNN, MSNBC, ABC World News Now, the CBS Early Show, PBS's All Things Considered and others. He has won a number of awards for his writing, including from the Computer Press Association for the Best Feature in a Computer Publication. He can be reached at firstname.lastname@example.org.
For More Information
- What do you think about this column? If you'd like to send feedback, you can E-mail the Editor.
- Visit our Best Web Links for Web Services for the best editor-selected resources on the Web.
- Post your technical questions, or help out your peers by answering questions, in our Discussion Forums.
- Ask the Experts! Our Web Services, XML, .NET, Java, EAI, and App Server gurus answer your toughest questions.