Web Service Fundamentals

Web Services (sometimes called XML Web Services) are the heart of Microsoft .NET. They represent the ultimate in distributed componentscomponents that you access over the Web, although they might be located anywhere in the world. A Web Service does not have a user interfaceit is code for other applications to call. Think of it as similar to a COM component that offers services to other components . One service might have a number of methods that all relate in some way. For example, a doctor's office might offer a Web Service that does the following:

• Indicates whether a given block of time is available or fully booked

• Indicates whether a specific doctor is scheduled to be in the office on a specific day

• Provides the next available block of time, given the requested length of the block

Another Web Service from the same office might, after verifying a user's identity, allow an application to do the following:

• Book an appointment for the user

• Confirm an appointment for the user

• Cancel or reschedule an appointment for the user

Whatever visual aspects you might imagine around these queries and requests come from the application that consumes the Web Servicethe Web Service itself does not provide, for example, a clickable calendar. An application designed for a large screen and a high-bandwith connection will have a very different user interface from one designed for a cell phone; both rely on the Web Service for access to the booking system at the doctor's office, but they display that information very differently.

When choosing the methods that you will offer, it's best to avoid a "chatty" model, where the application requests information one piece at a time. Connections over the Internet are likely to be a bottleneck, and because each request and response carries a certain amount of overhead, you'd like as much real information in there as possible. So, for example, if your Web Service offers information about training classes, don't use a method that returns the title, another that returns the price, and a third that returns the length of the course; instead return all this information at once and have the requesting application present it to the user. This is sometimes called a " chunky " interface because it returns large chunks of information at once.

The sample Web Service in this chapter offers two functions: one takes built-in types and the other uses managed types supported by the .NET Framework. Later in the chapter, you'll see the XML that represents this data. The two functions are as follows :

• Factor(int i, double d) returns true if d multiplied by an integer equals i . For example 1.5 times 2 is 3, so Factor(3,1.5) returns true . Factor(4,1.5) returns false .

• Week(int i) returns a DateTime structure representing the date of Monday of the specified week (1-based) of this year. For example, in 2004, Week(1) returns January 5th, 2004.

In reality, these are not great ideas for Web Services. They would work fine as methods of a class you developed along with the rest of your code. Real Web Services access something that the developer doesn't have access to on any other machine: typically that's information, such as the information about which timeslots in the doctor's office are booked. Sometimes Web Services offer access to proprietary code, but usually it's information. These samples have been designed so that you can run them on a single computer, which means that reading a file or otherwise accessing information on the server where the Web Service is running is exactly the same as accessing that information on the client machine. For that reason, the samples just perform simple calculations. What is important here is the techniques for writing the Web Service, an understanding of the way information is passed and returned in a Web Service call, and the techniques for consuming (using) a Web Service.