The World Wide Web has opened up distributed computing on a large scale. However, normal web pages only allow interaction between the client browser and the web server hosting the web page. The goal of web services is to create web-based applications that interact with other applications with no user interface. If you’re a web page developer, having such web services available can greatly increase your productivity. Imagine, for instance, you are creating a web site for a stock brokerage firm. Rather than having to integrate your back-end database with all the various databases of the different stock exchanges, your application can simply communicate with their web services, exchanging data in XML format.
Web services are very similar to web pages. The principal difference is that a web page is intended for viewing by a person, while a web service is used strictly for one program to interact with another and has no user interface.
Web services are entirely independent of the operating system or programming language used on either the server or the client side. Unlike previous technologies for distributed computing, such as DCOM, web services make it unnecessary for either end of the connection to be running the same operating system or to be programmed in the same language. For example, the server code might be written in VB.NET on Windows 2000 while the client is C++ running on a Unix machine, or vice versa. In other words, while previous technologies required that the client and server be tightly coupled, web services permit the client and server to be loosely coupled.
All that is necessary is that both server and client support the industry standard protocols HTTP, SOAP, and XML. HTTP is the protocol used by the Web. SOAP (Simple Object Access Protocol) is a lightweight, object-oriented protocol based on XML, which in turn is a cross-platform standard for formatting and organizing information.
This chapter provides a high-level view of what web services are and how they work. It describes, briefly, the standard protocols that make web services possible, as well as introducing how web services are created and consumed.
Chapter 16 covers in detail what is actually involved in creating web services. Through the development of a simple stock ticker, it demonstrates how to create a web service using either a text editor or Visual Studio .NET. It also shows you how to create a discovery file and how to deploy the web service.
Chapter 17 looks at web services from the other side of the fence, i.e., from the consumer’s point of view. This chapter builds on the stock ticker web service created in Chapter 16 to create a client web application that consumes, or uses, the stock ticker web service. Again, we demonstrate doing this using both a text editor and Visual Studio .NET.
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.
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 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.
Security for both web pages and web services is covered in detail in Chapter 19.
- 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.
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.
Creating web services will be covered in detail in Chapter 16. 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#.
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
dll 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 dll. 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.
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 DLL 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 DLL will be located on the desktop machine. In any case, once the proxy DLL 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 DLL, as though it were a call against a local DLL. Creating an application that consumes a web service will be covered in detail in Chapter 17.