ASP.NET —

Remoting Over the Web

Over the last 18 tutorials we've looked primarily at how ASP.NET makes it easy to handle a wide variety of Web application scenarios. We've seen that ASP.NET handles GET and POST methods, redirecting the request to a handler. Up until now the job of the handler has been to process the incoming query string and render some output generally intended for human consumption. Developing a Web service is all about writing an application intended for consumption by another program.

Web services are Internet endpoints available most commonly through HTTP and HTTPS (Hypertext Transfer Protocol Secure). The job of a Web service is to consume HTTP requests containing XML payloads formatted as SOAP. The messages have a specific schema applied to them, which in effect may be thought of as a transportable type system. Web services are also responsible for providing metadata (Web Service Description Language) describing the messages they consume and produce.

Simple Object Access Protocol (SOAP)

While it seems obvious that the Web is an excellent medium for distributing a user interface-oriented application to the masses, it may not seem so obvious that the same technology might be used to make method calls. One of the main reasons Web services may exist now is because different enterprises can agree upon what a method call looks like, and they can all access it over already-existing HTTP connections.

Web service method calls are encoded using XML. The format that callers and services agree on is known as Simple Object Access Protocol (SOAP). The SOAP protocol is an XML formalization for message-based communication. SOAP defines how to format messages, how to bind messages over HTTP, and a standard error representation.

Transporting the Type System

The primary interoperability focus of Web services is to widen the audience of an application so that as many clients as possible can invoke methods of the service. Because the connective medium involved is the Internet, any computer that can invoke HTTP requests becomes a potential client. Paired with the ability to connect over HTTP and to format calls as XML SOAP messages, a client can make calls to any of your Web service's methods.

With the focus on interoperability between as many platforms as possible, it becomes very important that the caller and the service agree on the data types being passed back and forth. When a client calls a method containing parameters, the two endpoints might each have their own way of understanding the parameter types. For example, passing a character string between two .NET endpoints does not pose a big problem. However, passing a string between a client running a non-.NET platform and a service written using .NET does pose a problem because a character string type is almost certainly represented differently on each platform.

When calling methods between two computers using HTTP and XML, it's very important that a schema is provided on each end so that the parameter types are interpreted correctly. Fortunately, this detail has been pushed down into the Web service tools that are currently available now.

Web Service Description Language

Given a connection protocol (HTTP) and wire format (XML + SOAP), the final ingredient making Web services a viable technology is the notion of a service description. Even though two endpoints agree on the connection protocol and the wire format, the client still has to know how to set up the call to a service.

Services advertise their capabilities via another XML formalization named Web Service Description Language (or WSDL as it's commonly called). WSDL specifies the target URL of the service, the format in which the service expects to see methods packaged, and how the messages will be encoded.