| Yesterday you learned how to use Web Services to build services that can be accessed over the Internet. For example, a site might want to offer a set of financial calculation functions. Once this Web service is designed and deployed on the site's Web server, anyone can come along and benefit from its functionality.  | Suppose the developer of a banking Web site wants to use one of these financial calculator services to do interest calculations for CDs. His banking application must consume your service in other words, access and use its methods. Consumption simply means that a client uses the methods available from a Web Service. The site's visitors can use the calculator without ever knowing where it came from. |
When you go to a gas station, the attendants are providing you a service. Therefore, you're the consumer of the service. You can take advantage of any resources the gas station has to offer, such as a gas pump, the attendants' time and service, and any other convenience items they sell. (Naturally, you have to pay for these services, but that's irrelevant at this point.) This saves you the trouble of building your own gas pump or servicing your own car. The consumer of a Web Service can do the exact same thing. It visits a service and consumes any resources that are available. Your computer could access a word processing service, for example. All the features of that service would be available to you, and you wouldn't have to buy and install a word processor yourself. A Web service consumer can be nearly any application: a desktop computer, an ASP.NET page, or even a mobile device such as a cell phone! Today's lesson focuses on using ASP.NET pages as the consumers for Web services. There are three stages in consuming a Web service: Gathering information about the service, a process known as discovery. Generating a proxy of the service. Using the proxy to invoke the available services. Caution Don't confuse a Web Service client with an Internet client. The former is an application or Web site that consumes a Web Service. The latter is an application that is used to browse the Web, such as a browser. A Web Service client accesses services, whereas a Web client accesses Web sites. The two are distinct, and you should fully understand the difference before attempting to build service clients.
Recall from yesterday that discovery is the process by which a client finds out about a Web Service. When you go to a new restaurant, first you read the menu to see what they serve. Consumers do the same for Web Services. They need to know what a service does before they use it. This information is provided by the service description of the Web Service (see yesterday's lesson). Recall that this description is an XML file generated by the service. The client accesses this file to find out about the service; in other words, it reads the menu of features. The client then creates its own copy of the menu for use later. Recall the .disco files from yesterday. These files are intended solely to aid clients. They provide links to the service descriptions available on a server that the client can use to find its way around. Note that a client can skip these .disco files if it already knows the exact URL of the service description. Generating a proxy of the service is an interesting step. Here's an analogy: You want to go to a restaurant, but you can't because you don't have a valid driver's license. However, you convince your mother to take you in her car. She's acting on your behalf by taking you somewhere you can't go on your own. In other words, she's a proxy between you and the restaurant. Web Service consumers are very similar. They know there's a service out there to consume, but they can't get to it themselves. They need a proxy to assist them. This proxy provides the mechanisms that transport information back and forth from the service to the client. When you access a service from your ASP.NET page, you want it to be easily available. You don't want to have to worry about how to send XML messages, or transform your commands into the proper formats, or retrieve the returned data. Ideally, you want to be able to access the service as though it were a business object on your own computer, which means you only have to create an instance of the object. Thus, you generate a proxy of the service. This is a class that resides on your computer and encapsulates all the complex functionality needed to communicate with the service. It allows you to interact with the service just as you would with any other object. In fact, the proxy will contain methods and properties that correspond to the ones provided by the service, and they will be named identically. Thus, if you know which methods the service offers, you can call the proxy with the same names. Figure 17.1 illustrates the process of using a proxy. Figure 17.1. The proxy acts as an intermediary between a client and a service.
The proxy is generated from information in the service description. This tells the proxy everything it needs to know about how to send commands and what to expect in return. You'll learn more about this later today, in "Consuming a Web Service Through an ASP.NET Page." Finally, the consumer can use the Web Service's methods through the proxy class, just as it would any other object. All of this is transparent to an end user, and it isn't difficult for a developer to implement. Figure 17.2 illustrates the steps involved from the consumer's side. Figure 17.2. Consuming a Web Service involves three steps.
Note The most common consumers for Web Services are Web pages and other Web Services, although it's not uncommon for regular, desktop-based applications to access services as well.
| 
