Summary

Chapter 5

Using WSDL to Document Web Services

In the previous chapter, you learned how to create a schema to describe the format of a SOAP message. You can use XML Schema to describe the layout of a message and the type of data the message contains, and the resulting schema can be used to validate the message received by the Web server. However, XML Schema alone cannot fully describe a Web service.

Let's say I have created a Calculator Web service. The Web service exposes two methods, Add and Subtract. Both methods accept two integers and return a single integer containing the result—Add returns the sum of the two integers, and Subtract returns the difference of the two numbers.

In an effort to describe how a client will interact with my Web service, I define a schema for the messages that will be exchanged between the client and the server. My schema contains a complex type definition for the request and response messages for both the Add and Subtract methods. Remember that the ultimate goal is not to have developers pore through schema definitions trying to decipher how to interact with a Web service. Instead, I want to describe my Web service in such a way that a tool can decipher it and create a proxy on the client's behalf.

In addition to the information provided by the schema, what else does a client need to know in order to invoke methods exposed by the Calculator Web service? Because the body of a SOAP message can contain anything that does not invalidate the XML, individual SOAP messages can be combined to support a wide variety of message exchange patterns. The message exchange patterns for the Calculator Web service are pretty straightforward, but a formal association between the Add and Subtract request messages and their associated response messages would remove any possible ambiguity.

A formal description of the message patterns is even more important for more complex Web services. Some Web services might accept a request but not send a corresponding response back to the client. Others might only send messages to the client.

The schema also does not contain information about how to access the Web service. Because SOAP is protocol independent, messages can be exchanged between the client and the server any number of ways. How do you know whether you should send a message over HTTP, SMTP, or some other transport protocol? Furthermore, how do you know the address to which the message should be sent?

Web Service Description Language (WSDL) is an XML-based dialect layered on top of the schema that describes a Web service. A WSDL document provides the information necessary for a client to interact with the Web service. WSDL is extensible and can be used to describe practically any network service, including SOAP over HTTP and even protocols that are not XML-based, such as DCOM over UDP.

In this chapter, I build the WSDL document that describes the Calculator Web service. Along the way, I describe the various parts of a WSDL document and the roles they play in describing the Web service.