Web Service Description Language

Given a connection protocol (HTTP) and wire format (XML + SOAP), the final ingredient making Web services a viable technology is the notion of a service description. Even though two endpoints agree on the connection protocol and the wire format, the client still has to know how to set up the call to a service.

Services advertise their capabilities via another XML formalization named Web Service Description Language (or WSDL as it's commonly called). WSDL specifies the target URL of the service, the format in which the service expects to see methods packaged, and how the messages will be encoded.

If You Couldn't Use ASP.NET…

Just as there's nothing stopping you from writing code to handle HTTP requests from scratch, you could handle Web service requests from handwritten code. You could write a Web service armed with a only a decent XML parser and a socket library (for communicating over your server's communication ports). The work involved includes the following:

  1. Listening to port 80 to receive method calls

  2. Parsing the incoming XML stream, unpacking the parameters

  3. Setting up the incoming parameters and performing the work

  4. Packing a suitable XML SOAP response and sending it to the caller

  5. Advertising the service's capabilities via WSDL

After the second or third time implementing a service by hand, you'd probably come to the following conclusion. Much of the work involved in making a Web service work is repetitive and might as well be pushed into a library. That's exactly what ASP.NET does. ASP.NET will handle the details of making a Web service through the System.Web.Services.Service class.