.NET Web Services expand on the concept of distributed processing to build components whose methods can be invoked across the Internet. These components can be built in any .NET language, and they communicate using open protocols that are platform-independent.
For example, a stock exchange server might provide a web service method that takes a stock ticker symbol as a parameter and returns a quote. An application might combine that service with another service from a different company that also takes a stock symbol but that returns background data about the company. The application developer can concentrate on adding value to these services, rather than duplicating the same service for his own application.
The list of web services that might be useful to developers and end users seems boundless. A bookstore might provide a web service that takes an ISBN and returns the price and availability of a title. A hotel’s web service might take a date range and number of guests and return a reservation. Another web service might take a telephone number and return a name and address. Yet another might provide information about the weather or shuttle launches.
Microsoft has announced a number of commercial .NET services as part of its Project Hailstorm initiative. Among these are its Passport service for identifying and authenticating users (see http://www.passport.com), as well as services for managing storage, notification, appointments, and a host of other applications. These services, as well as the ones you write, can be integrated with your applications just like any other business object.
In such a world, a single application might draw on and stitch together the services of hundreds of small web services distributed all over the world. This takes the Web to an entirely new dimension: not only is information retrieved and exchanged, but also methods are invoked and applications are executed.
What is needed to make web services possible is a simple, universally accepted protocol for exposing, finding, and invoking web service functions. In 1999, Simple Object Access Protocol (SOAP) was proposed to the World Wide Web Consortium. SOAP has the advantages of being based on XML and of using standard Internet communications protocols.
SOAP is a lightweight, message-based protocol built on XML, HTTP, and SMTP. Two other protocols are desirable, but not required, for a client to use a SOAP-enabled web service: a description of the methods provided by a particular service that can be understood and acted upon by clients, and a description of all such services available at a particular site or URL. The first of these is provided in .NET by the Web Service Description Language (WSDL) protocol, jointly developed by Microsoft, IBM, and others. Two other protocols have been proposed for discovery: UDDI, a joint effort by a number of companies including IBM and Microsoft, and Discovery, a proprietary offering from Microsoft.
WSDL is an XML schema used to describe the available methods—the interface—of a web service. Discovery enables applications to locate and interrogate web service descriptions, a preliminary step for accessing a web service. It is through the discovery process that web service clients learn that a service exists, what its capabilities are, and how to properly interact with it. A Discovery (.disco) file provides information to help browsers determine the URLs at any web site at which web services are available. When a server receives a request for a .disco file, it generates a list of some or all of the URLs at that site that provide web services.
The
plumbing necessary to discover and invoke web services is integrated
into the .NET Framework and provided by classes within the
System.Web.Services.WebService
namespace.
Creating a web service requires no special programming on your part;
you need only write the implementing code, add the
[WebMethod] attribute, and let the server do the
rest. You can read about attributes in detail in Chapter 18.
You make
use of a web service by writing client code that acts as though it
were communicating directly with the host server by means of a URL.
However, in reality, the client interacts with a
proxy
.
The job of the proxy is to represent the server on the client
machine, but to bundle client requests into SOAP messages that are
sent on to the server and to retrieve the responses that contain the
result. Proxies and the details of dealing with objects on other
machines are covered in detail in Chapter 19.