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:

• Both the web service server and the client application are connected to the Internet and are able to communicate with any other device connected to the Internet.

• The data format with which the two ends of the connection communicate conforms to the same open standard. This standard is usually the SOAP protocol. SOAP messages consist of self-describing, text-based XML documents. It is also possible to communicate via HTTP-GET or HTTP-POST requests.

• The systems at the two ends of the connection are loosely coupled. In other words, web services do not care what operating system, object model, or programming language is used on either end of the connection, as long as both the web service and the consuming application are able to send and receive messages that conform to the proper protocol standard.

The logic behind the web services process is shown schematically in Figure 15-1.

Figure 15-1. What goes on behind a web service

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:

Protocol

The web service must communicate with the client, and vice versa, in a manner that both sides will understand.

Directories

Web services will be developed by literally thousands or tens of thousands of companies. Directories will be created to list these services and make them available to developers. For directories to be useful, however, there must be conventions for discovery and description.

Discovery

Potential clients will need to locate, or discover, documents that describe the web service. Thus, the service will often provide discovery documents—XML files that contain information allowing potential clients to find other files that describe the web service.

Description

Once a web service has been identified, either through discovery or other means, it must make available a document that describes the protocols it supports and the programmatic interface to its usage. The Web Services Description Language (WSDL) is used to describe the web service and all of its exposed methods with their parameters. In short, the description indicates what methods the web service exposes, what parameters those methods require, and what type of data the methods return.

Security

Many servers connected to the Internet are set up to be very conscious of security, with firewalls and other means of blocking all traffic except that which is deemed not harmful. Web services must live within these security constraints. Web services must not be portals for malicious people or software to enter your network.

Also, it is often necessary to restrict access to specific clients. For example, suppose you are developing a stock ticker for a brokerage firm. You might want to restrict access to the web service to paying clients, excluding anyone who has not paid a usage fee.

Chapter 19 discusses in detail security for both web pages and web services.

State

Like web pages, web services use HTTP, which is a stateless protocol. And as with web pages, the .NET Framework provides tools to preserve state, if the application requires this.

15.1.1 Developing a Web Service

The process of developing a web service is nearly identical to developing a web page:

• All the source files comprising both web pages and services are flat text files. They can be created and edited in any text editor, then compiled using a command-line tool from a command prompt.

• Both web pages and services can be created in Visual Studio .NET.

• Both web pages and web services can use code-behind. Code-behind is generally considered a technique intended to separate visual content from programmatic content in web pages. As such, its use in web services is less imperative, since a web service does not have any visual content. However, since Visual Studio .NET uses code-behind for every web project, whether visual or not, it gets used for web services as well. In fact, when using Visual Studio .NET to create web services, just as with web pages, code-behind is used by default. (For a full discussion of code-behind, see Chapter 6.)

• Both web pages and web services make full use of the CLR and the .NET Framework.

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#.

Figure 15-2. Testing the .asmx file in a browser

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.

Figure 15-3. Web service proxy operation

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

The consumer of a web service can be a desktop application, a web page, or another web service. All that is required is that the consumer be able to send and receive SOAP or HTTP packages.

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.