15.1 How Web Services Work
Web services allow an object on the server to expose program logic to clients over the Internet. Clients call exposed methods on the web service using standard Internet protocols. In short, a web service is merely a function or method call over the Internet.
The web services infrastructure has several defining characteristics:
The logic behind the web services process is shown schematically in Figure 15-1.
In Figure 15-1 at position 1, a web service consumer (i.e., a program that uses a particular web service, sometimes called the consuming program) makes a call to the web service (position 2). The consumer thinks it is talking directly to the web service over the Internet. This is only an illusion.
The actual call is being made to a proxy class (position 3) which is local to the consumer. The proxy handles all the complex infrastructure of sending the request over the Internet to the server machine, as well as getting results back and presenting them to the consumer.
All of this is made possible because the proxy was previously registered with the consuming application (position 4). This is done by the developer of the consuming application.
This chapter, along with the next two chapters, will explain in detail all of the concepts outlined in Figure 15-1.
In addition to creating and consuming the web service, there are other aspects to consider. These include:
15.1.1 Developing a Web Service
However, while a web page is defined by its .aspx file, a web service is defined by its .asmx file.
Chapter 16 discusses creating web services in detail. For now, think of a web service as a web page without any user interface or visual components in which some (but not necessarily all) of the methods or functions in the web service class are exposed to outside requests as web methods. Web services allow method calls over the Internet.
Once the .asmx page is complete, the web service class must be compiled into a dynamic link library (.dll) file, the form in which it is made available to requests. You can compile either from a command prompt or through Visual Studio .NET. Both techniques have advantages and disadvantages; Chapter 16 will demonstrate both.
You can easily test the .asmx file by entering its URL into any browser, as shown in Figure 15-2. This test shows a list of usable links to each of the web methods exposed by the web service. It also displays useful information and links pertaining to its deployment, including code samples in both VB.NET and C#.
15.1.2 Creating the Proxy
Before a client application can use a web service, a proxy must be created. A proxy is a substitute, a stand-in, for the actual code you want to call. It is responsible for marshalling—or managing—the call across machine boundaries. Requests to the web service on the server must conform to the proper protocol and format, usually SOAP and/or HTTP. You could write all the code to serialize and send the proper data to the web service yourself, but that would be a lot of work. The proxy does it all for you.
The proxy is registered with the client application. Then the client application makes method calls as though it were calling a local object. The proxy does all the work of taking your calls, wrapping them in the proper format, and sending them as a SOAP request to the server. When the server returns the SOAP package to the client, the proxy decodes everything and presents it to the client application as though it were returning from local calls. This process is shown schematically in Figure 15-3.
To make this work, a developer must create the proxy and register it with the client application under development. This registration consists of a list of the exposed web methods and their signatures. The owner of the web service can add new web methods or update existing ones without changing their signature, and the existing proxy will not break.
15.1.3 Creating the Consumer
If you develop your client using Visual Studio .NET, you need only register the proxy dll with the application. If you are working from a command prompt, simply make a reference to the proxy dll when you compile the application.
If the consuming application is a web page or another web service, then the proxy will be located on the server that hosts the consuming web page or service. If the consumer application is a desktop application, then the proxy will be located on the desktop machine. In any case, once the proxy is created and registered with the consuming application, then all that application has to do to use a web service is make a method or function call against that proxy object, as though it were a call against a local object. Chapter 17 discusses in detail creating an application that consumes a web service.