Components of a Web Service

Web services are based on well-established networking protocols and a few newer technologies. In truth, you really don't have to know much about any of these technologies because .NET handles them, for the most part, in the background for you. In fact, the first few Web services I wrote were in complete blissful ignorance of these technologies. But, of course, true to my developer nature, I wanted to see what happens behind the curtain.

Basically, for a Web service to function, you need

• A communication protocol so that the service and its consuming client can communicate

• A description service so that the consuming client will be able to understand how to use the Web service

• A discovery service so that the consuming client can find the Web service

In the following sections you'll take a look at each requirement in a little more detail.

Communication Protocols

Communication between .NET Web services and client consumers is handled via generic HTTP using port 80. If you know something about Internet technology, you will recognize this as the same communication method used by standard Web browsers. Thus, if your system supports a Web browser, it can also support Web services. This is a key aspect of Web services, as other distributed application methods use their own specific communication protocols and ports.

Communication between a Web service and a consumer client is always initiated by the client. Clients communicate with the Web service over HTTP in two different ways:

• HTTP POST commands

• SOAP

If you have done any Web server programming, you should be quite comfortable with using HTTP POST commands. In fact, you used them with ASP.NET in the previous chapter but, just as you will see with Web services, this was hidden from you. Normally, you will not use this method when implementing Web services because it is limited to simple data types for passing between the client and the service.

Caution

Make sure you are using HTTP POST and not HTTP GET. HTTP GET is supported by Web services, but you need to change your default machine.config file. (You must uncomment the line <add name="HttpGet"/>.) My guess is that Microsoft plans to phase this out, so I recommend that you don't use HTTP GET, and except for basic Web service testing, I don't really see any reason to use HTTP GET anyway.

SOAP is a powerful XML-based protocol that packages up a method to be executed, along with any parameters it requires for implementing. This package is then sent using a standard HTTP request to the Web service. Upon the completion of the execution of a method, SOAP packages up any return values and sends them back to the client using a standard HTTP response.

The best part of SOAP, at least when it comes to .NET, is you get it for free, in almost all cases, as you have to know nothing about it so long as you code within the Common Language Specification (CLS) specified by .NET. As you will see later in this chapter when I show how to send a DataSet from a Web service to a client, it is possible to transmit fairly complex data objects using SOAP.

Description Service

It's all well and good that you send stuff back and forth between the client and the Web service. But before this communication can take place, the client needs some way to find out what it can request the Web service to do and what format the request needs to be in. (The format is also known as the method signature.) You might think that you could use SOAP to handle the descriptive service, but SOAP was not designed to describe method signatures, only package them for transport.

The Web service provides this description of its interfaces using the relatively new standard called the Web Services Description Language (WSDL). Like SOAP, WSDL is XML based. But instead of packaging like SOAP, WSDL actually describes the method signatures. In fact, WSDL describes method signatures in such detail that Visual Studio .NET imports the WSDL's XML definitions and uses them to provide IntelliSense help.

Like all the previous technologies for Web services, WSDL is completely handled by Visual Studio .NET.

Discovery Service

Even if you can communicate between a client and a Web service and describe how this communication needs to take place, it's all still moot if the client doesn't know where to find the required Web service it needs to execute. This is the job of the discovery service. .NET provides two discovery services:

• Web Services Discovery tool (DISCO)

• Universal Description, Discovery, and Integration (UDDI)

DISCO is used to describe each Web service in any given virtual directory and any related subdirectories. Originally, .NET was going to use DISCO as its primary method of discovery, but with the advent of the superior UDDI, DISCO has become optional. It is still created automatically by Visual Studio .NET for those who want to stick with DISCO, but I think it will most probably disappear in the future.

UDDI's scope is more far-reaching than DISCO's. With UDDI, you register your Web service with a central agency. Once your Web service is registered, third parties can search the agency to locate your registered Web service.