Section 15.1. How Web Services Work

15.1. How Web Services Work

Web services allow two programs to exchange XML documents. Microsoft has implemented a Remote Procedure Call (RPC) model on top of this architecture, and for the purposes of this book, we will treat web services as a way for a server to expose methods to a client.

There is a competing description of web services in which it is described in terms of messaging. From this perspective, a contract defines the content and type of the messages, and the web service is developed to implement that contract. Many developers believe that this approach yields a web service with fewer interoperability problems since all parties know in advance what types they can pass back and forth.

Though the tools in VS2005 are moving toward making this design approach more feasible , Microsoft's core tools still encourage and facilitate the RPC model.


The web services infrastructure has several defining characteristics:

  • Both the web service server and the client application are 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 almost always SOAP, though it is technically possible to communicate via HTTP-GET or HTTP-POST requests . SOAP messages consist of self-describing , text-based XML documents.

  • 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 (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 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 and the next will explain and demonstrate all of the concepts outlined in Figure 15-1.

In addition to creating and consuming the web service, there are other aspects to consider:



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 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, i.e., 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, through discovery or other means, it must make a document available that describes the protocols it supports (typically SOAP) and the programmatic interface to its usage. The Web Services Description Language (WSDL) describes all of the exposed methods and properties, including each method's parameters and return type.



Security

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

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 12 discusses 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 will provide 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 that make up both web pages and services are text files. They can be created and edited in any text editor, and class files can be compiled using a command-line tool from a command prompt.

  • Both web pages and services can be created in VS2005.

  • Both web pages and web services can use either the code-behind or in-line coding model. 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. (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.

While a web page is defined by its .aspx file, a web service is defined by its .asmx file.

Think of a web service as a class in which some (but not necessarily all) of the methods are exposed to clients over the Internet.

You can easily test an .asmx file by entering its URL into any browser, as in this example:

 http://localhost/websites/StockTickerInLine.asmx 

The result is 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 C#, VB2005, and C++.

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

15.1.2. The Proxy

Before a client application can use a web service, a proxy must be created. A proxy is a stand-in for the actual code you want to call. It is responsible for marshalling the call across the 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 a method on a local object. 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.

The proxy class is compiled into an assembly, which must be registered with the consuming application. In the next chapter, you will see several ways to do this, ranging from a fully automated technique using VS2005 to a series of manual steps, either using VS2005 or not.

The consuming application is called the client , and the proxy is located on the client's machine. Once the proxy is created and registered with the client, all the client has to do to use your web service is make a method call against that proxy object as though it were a call against a local object.



Programming ASP. NET
Programming ASP.NET 3.5
ISBN: 0596529562
EAN: 2147483647
Year: 2003
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net