Understanding Web Services in Visual C#

Creator Code 3 of 9 in Visual C# Understanding Web Services

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: Brokers the communication process between the client and the service Provides type safety, if it s supported Generally makes your life easier because WSDL (and the contract it provides) is an important part of a service developer s work The contract isn t legally binding (and contains only a small amount of fine print) The service provider reserves the right to change the service any time it wants, and can even forgo updating the WSDL with no fear of legal reprisal Because you re a NET developer, though, your WSDL is generated automatically

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