• The Interface Specification: WSDL: You already know that WSDL tells the world how to contact your application, but you can also think of WSDL as a standard--in the sense that a phone number is a standard. You must know the phone number to communicate with the person you're calling. Likewise, your application must know the interface to communicate with a Web service. Most environments will generate WSDL files automatically--you shouldn't have to write them.
So how do you get your hands on the WSDL file of a Web service? Most will respond to a request of the form: www.mywebservice.com/someServiceURL/wsdl?
|
FYI
There are excellent tutorials on generating WSDL and Web service wrappers for both .Net and Java/Tomcat Web services. O'Reilly offers one for Java applications, "Creating Web Services with Apache Axis," at OnJava.com, and Microsoft has an excellent set of samples here.
|
Say a vendor has told you about its Wonderful Web Service; just go to the URL provided and add "/wsdl?" The response should be an XML document in the format discussed in this article.
On Your Level
Understanding the layout of a WSDL file is straightforward--if you take it a level at a time. Here, in an abstract format, is how to read WSDL files and determine the interface that a Web service provides.
• Level 1: There are only two major elements at this level: which version of XML is supported and the top-level definition statement.
XML Version: The version of the W3C XML specification to which this document conforms.
Definitions: This is where you define your service and any supporting data types. All of Level 2 fits into this piece of Level 1.
• Level 2: The Service Definition
Types: Here you define the complex data types used by the rest of the file. For example, if the output from a Web service defined in this file is a date, a time and a value, such as stock price, you will need to define the tags and XML data types for these output fields.
Message Name: In this section you define the messages your program knows how to process. It is a mapping from the external name to the internal name.
Port Type: This is the public entry point for calling applications. It defines what operations are available and what messages are used by the operations.
Binding Name: This section binds an operation to a transport mechanism. This is where you say "requests come via HTTP post messages to this URL, and responses come back via SMTP messages."
Service Name: This is the public advertisement for your service. It tells the service name and where to find it, and possibly documents it in readable form.
Level 3 further defines Level 2 elements. This is where you would say, "The transport mechanism for this Level 2 Binding Name is HTTP." Level 3 is different for each Level 2 element, so we will not explore it here.
In summary, WSDL offers three important pieces of information to the client: What messages it recognizes, what transport mechanism it uses to communicate those messages and how to contact this service. The following example is simplified from the SOAP committee's WSDL 1.1 Specification Document:
First, at what URL are these services located? This is in the "soap:Address location" field of the service definition of the WSDL file:
<soap:address location="http://example.com/
stockquote">
What messages does this Web service understand? To find out, we examine the definition for a message called "GetLastTradePriceInput," which takes a ticker symbol as input. Note that "Message Name" is defined as a Level 2 element. It has (in this example) a single Level 3 element called "part name."
<message name="GetLastTradePriceInput">
<part name="Ticker Symbol" element="String">
</message>
And finally, "What information can I expect to get back, and what format will it be in?"
The response the server will send is called "GetLastTradePriceOutput," and it passes a floating point number:
<message name="GetLastTradePriceOutput">
<part name="price" element="float"/>
</message> </pre>
RSS
