Day 16: Creating Web Services
Web Service Scenarios
Imagine that you've built a component that performs simple calculation functions, like the calculator you built on Day 2, "Building ASP.NET Pages." Recall that the calculator performed simple arithmetic operations. Another Web site somewhere has built a component that can place orders to a home improvement store. Assuming these two components are Web services, a savvy developer could link them to create an application that allows a user to design her home. When the user needs to determine measurements and calculations, she uses your Web service's calculation functions. Then she places an order to the home improvement store through the other Web service. All this is accomplished from within one application, and the user doesn't need to know where the pieces of functionality came from. Figure 16.3 illustrates this example.
Web services can even be used by Internet applications. Imagine an e-commerce site that must calculate shipping charges for customers ordering supplies. Normally, this site would have to maintain an up-to-date table for calculating shipping costs based on the shipper, the shipping location, the priority, and so on. With Web services, the site can place a "call" to the shipping company directly, using a brief XML command, and receive the quotes instantly. Web services easily tie together applications that were once very difficult to assemble.
The Web Service Programming Model
As mentioned earlier, Web services use XML to communicate. But what exactly is being communicated?
New Term - The first messages that are sent usually involve a process known as discovery, which is how a client application finds and examines a Web service. The discovery process involves messages sent to and from the service that describe what the service can do. The client needs to know this before it tries to use the service. The service also tells the client what other kinds of messages it will accept.
The discovery process is not a necessary one. For instance, if a service doesn't want anyone to know about it, it can disable the discovery process. This is a protective measure so that not just anyone can use a particular Web service you've created.
Following discovery, the service must tell the client what it expects to receive (that is, which commands it will accept) and what it will send back. This is a necessary step so that both service and client know how to communicate with each other. This data is known as a Web service description. In a business object, the developer typically knows ahead of time which commands the object will support (through the documentation provided, for instance). The service description is essentially the documentation for the service in XML format.
Finally, messages are sent back and forth with commands to the service and data for the client, again in XML. Figure 16.4 illustrates the entire process.
Luckily, ASP.NET provides most of the infrastructure needed to perform all of these operations. After all, it can handle requests and responses, translate XML, and use business objects, making it ideal for Web service development. You just need to decide what your Web service will do and then build it.