Because Web services are, like Web applications, loosely coupled, Web service conversations aren't guaranteed to make sense. You might get a sentence from three minutes ago, after four other sentences have gone past, or you might not hear from them again after the first line.

When you stop to think about it, louse coupling makes sense: Web service calls are just like navigation in a Web page. Sometimes you click a link and then close your browser, and sometimes you click the link twice. Web applications are up to the whim of the user, and so are Web services.

For this reason, a client of a Web service must be loosely coupled to the service. For example, you don't want to make a user wait until a Web service call is complete. You must call x asynchronously and have the result show up when it is ready.

Fortunately, .NET handles the asynchronous call. You just tell your application that you're calling a service asynchronously and then provide a delegate for the service to call when it's ready. As long as you handle the code properly, the service will work as expected.

In this example, you can see that we implemented the loose coupling with an asynchronous call:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            //Here YOU are calling the service
   asynchronously.

AddStuffReference.ServicelSoapClient client = new
      AddStuffReference.ServicelSoapClient();
               client.AddStuffCompleted += new
      EventHandler(client_AddStuffCompleted);
               client.AddStuffAsynchf"This is the stuff");
           }

          //This method is called when the response comes back.
         //No timers or anything.  .NET handles it for you.
         void proxy_AddStuffCompleted(object
      sender, AddStuffReference.ServicelSoapClient.
      AddStuffCompletedEventArgs e)
           {
              bool result = e.Result.ToString();
           }
     }
}

In client-server development, an interface defines a contract of sorts between the domain model and the user interface. That contract can be used to drive development in the same way as a contract is used to drive a business deal. If you know what I require and I know what you require, we can quickly and easily make a deal.

A Web service is required to have an interface that conforms to the Web Services Description Language (WSDL) standard. WSDL describes expected inputs and allowed outputs just as an interface would, creating a contract between the service provider and the client.

In .NET, your contract is created automatically from the code for the service. If you call a service in the browser (which isn't the way it's designed to be called — I tell you more about that topic later in this minibook) from the development machine, you see the test screen shown in Figure 1-1. Even though the browser gains some basic important information about the service, it isn't the contract. The contract is shown behind the Service Description link.

Clicking the Service Description link appends the text ?WSDL to the URI, and the Web browser shows the contract. This contract is used by the client system to determine exactly which information the service wants and how it will respond to input. Though the WSDL is displayed in a browser, as shown in Figure 1-2, the interesting part is the XML that's behind the screen.

Figure 1-1. The default service overview.

Figure 1-2. The Service Description in WSDL.

For compilable languages, the client machine does essentially the same thing no matter which platform it's on (Java or Basic or PHP or Ruby): At compile time, it reads the WSDL and creates a proxy that the client talks to. This:

Although the chunky-versus-chatty services issue might sound like a face-off between candy bars, it isn't.

Rather than perform small, incremental operations via Web services, you use them to make large, sweeping "strokes." The length of individual calls might be larger, but the number of communications is fewer, which reduces network overhead.

Suppose that an application changes the settings of a piece of hardware located miles away from it — perhaps your home heating system (which is a good use of a service). The client application (your computer) is absolutely local, the remote device (your heater) is certainly remote, and a network (probably the Internet) is in the middle. If you have a service with a series of individual controls, such as TurnFanOn and TurnFanOff, it's a common interface for a local application, such as connecting a heater directly to your computer.

The following chunk of code gives an example of that chatty sort of interface:

namespace HomeHeater
{
    public class Chatty : IChatty
    {
        public bool TurnFanOn()
        {
            return true;
        }
        public bool TurnFanOff()
        {
            return true;
        }

public bool SetTemperature(int newTemperature)
       {
            return true;
       }
       public bool SetFanSpeed(string newFanSpeed)
       {
           return true;
     }
 }

The interface in this example is chatty (in case you couldn't tell from its class name). Every time you change a knob on the controller, a call is made to a service. Move the temperature to 72 degrees and call the service. Turn the fan to its High setting and call the service. Turn the temperature back down to 71 degrees and call the service. The client "chats" with the service.

Nothing is intrinsically wrong with this implementation. For a service, though, with more network overhead for every call, it isn't the best way to build methods. Instead, you want your client to change settings and then pull a big lever on the side to make all the changes at one time.

A chunky interface provides a domain model for the client to use, with properties to set. Then, after all settings are in the model object, you send the whole shootin' match to the service. It looks like this:

namespace HomeHeater
{
    public class Chunky : IChunky
    {
        public bool UpdateHeaterSettings(HeaterModule
   heaterModule)
        {
            return true;
        }
    }
    public class HeaterModule
    {
        public int Temperature { get; set; }
        public bool FanOn { get; set; }
        public string FanSpeed { get; set; }
    }
}

Now, no matter how often you make changes, the service is called only when you "pull the big lever" (update it). Whether this action prevents users from updating after every change depends on your interface. In general, this design principle is the best one for service development.

You may wonder why anyone would bother with a concept as convoluted as Web services. I can assure you that good reasons exist and that you will want to use this technology on a project.