Overview of Web Services

At an abstract level, web services enable one application to call procedures or methods in another application. On the face of it, this is similar to the aims of Remote Procedure Calls (RPC), DCOM, Remote Method Invocation (RMI), Internet Inter-ORB Protocol (IIOP), and .NET remoting ”all of these technologies enable one application to invoke procedures in another application.

Note  

It's also possible to view these technologies as a way for two components in the same application to interact with each other. While this is definitely a common use for the other technologies I mention, it isn't the intended use of web services. Web services are designed for cross-application communication, not cross-component communication. This is because the focus of web services is interoperability. Due to this focus, web services don't offer the same performance or features as the other more platform-specific technologies listed.

More specifically , ASP.NET web services are an implementation of SOAP, which uses the Hypertext Transfer Protocol (HTTP) for communication between one application and another.

The following discussion is intended to provide some high-level background information on SOAP and web services. As we'll see, a typical .NET developer never needs to worry directly about these details, because the .NET Framework and VS .NET take care of them on our behalf .

Simple Object Access Protocol

SOAP defines the format and structure of the data packets (messages) that are sent back and forth between the applications involved. There are two primary types of message:

• A procedure call

• The results of a procedure call

When an application wants to call a procedure or a method in another application, it constructs a SOAP message that describes the method to be called and provides any parameter data. Any results from the procedure are likewise packed up into a SOAP message that's returned to the original application.

SOAP defines a couple of important things that must go into a message:

• The format of the data that's being transferred

• An envelope of metadata around the data that's being transferred

The SOAP data format is designed to be supported by virtually any platform. It defines a rich set of data types, including numbers , text, arrays, and so forth. Data of these types can be encoded into a standard XML format that can be understood by any platform that supports SOAP. The format is designed for interoperability, which means that most platforms will have more complex data types or structures that can't be readily encoded into SOAP XML.

The SOAP envelope contains metadata describing the nature and purpose of the message. We can think of the envelope as being like a "header" for the actual data; it's a little like an HTTP header. The envelope can be quite complex and it's extensible. This means that we can add arbitrary additional data into the envelope ”a feature we'll use later in the chapter to pass security credentials along with our method call.

Note  

Originally, SOAP was conceived as a way to make calls on objects ”hence that word "object" in the acronym ”but this isn't the case now, and the acronym is falling into disuse: SOAP is just SOAP. There need not be any objects anywhere in your system in order to use SOAP ”it simply allows one application to call a procedure in another application. Whether that procedure is a method of an object or a routine written in COBOL doesn't matter.

Message-Based Communication

A key point to remember is that SOAP only defines the XML that makes up the message; it doesn't describe how that message should be delivered from one application to another. It's down to some other mechanism to deliver a SOAP-formatted request message from one application (the consumer) to the other (the publisher). The publisher application then runs the requested procedure. Any results from that procedure are packaged up into another SOAP-formatted message, which is returned to the onsumer as shown in Figure 10-3.

Figure 10-3: XML messages are passed to and from the service

The most common approach today is for the applications to communicate via HTTP, but the SOAP data format can be transferred via email, MSMQ, raw sockets, text files, instant-messaging technology, or any other way that you can think of to get the data from one application to the other.

SOAP and Web Services

This then is where web services come into play. Web services allow consumers to connect to them using the HTTP protocol. Each procedure call is an isolated event in which the consumer connects to the service, makes the call, and gets back the result.

However, using web services over HTTP is about more than just passing SOAP XML messages back and forth. While that's at the core of the process, there are a number of supporting features that are very important, including the following:

• Describing the nature of a web service

• Generating consumer-side proxies for a web service

• Discovery of the web services on a machine

• Managing directories of web services

Describing a web service means generating a list of all the procedures (often called web methods ) that are available to consumers, along with the data types of the parameters those procedures require, and the data types of any return values. There's a standard for describing this information: Web Services Description Language (WSDL). WSDL is an XML dialect that describes a web service. When we (or VS .NET on our behalf) need information about a web service, we retrieve a WSDL document.

The primary reason for retrieving a WSDL document is to create a consumer-side proxy for the web service: an object on the consumer machine that looks like the web service. Any method calls we make on this proxy are automatically packaged into SOAP XML and sent to the publisher application as shown in Figure 10-4. This is really no different from how we use client-side proxy objects in remoting, DCOM, or any other similar technology.

Figure 10-4: Web-service interaction is abstracted behind a proxy object

The next challenge we face is exactly how to find these WSDL files and/or their associated web services. It's all very well making them available, but how are potential consumers to discover that they exist? Happily, the web-services technology defines a formal mechanism by which web services can be discovered . Along with this, there's the Universal Description, Discovery, and Integration standard (UDDI), which allows us to create directories of web services. UDDI provides an index of available web services, which we can then contact directly to get their WSDL so that we can create a proxy.

SOAP, Web Services, and the .NET Framework

As .NET developers, we typically don't think about the creation of SOAP messages and envelopes. Nor do we really think about the details of delivering a SOAP message via HTTP. All this is handled on our behalf by the .NET Framework and its support for web services.

To create a publisher (an application that exposes web services), we simply create an ASP.NET Web Services project and write some code. Alternatively, we can just add a web service to an existing ASP.NET web application. In either case, apart from adding a couple of special attributes to our code, we don't usually have to do any difficult work.

For instance, we might write the following code in a web service within an ASP.NET application:

 [System.Web.Services.WebService(   Namespace="http://ws.lhotka.net/PTService/ProjectTracker")] public class ProjectTracker : System.Web.Services.WebService {   [WebMethod(Description="Get Resource Name")]   public string GetResourceName(string id)   {     string name;     // Retrieve name     return name;  } } 

When this ASP.NET application is compiled, VS .NET will automatically generate all the extra files needed to provide access to this method via web services. This includes the ability to generate WSDL descriptions for the web service dynamically.

Equally, a typical .NET developer doesn't need to worry about creating consumer-side proxy objects. If we're using VS .NET, we simply add a web reference to the web service. VS .NET then automatically retrieves the WSDL describing the web service and generates the proxy. If we're not using VS .NET, the .NET Framework offers the soapsuds.exe command-line utility, which can also create the proxy.

Because of the tight integration of web services into the .NET Framework and VS .NET, we can avoid dealing with the details of publishing and consuming web services. This means that we can focus on how to use them in our business applications, rather than worrying about how to make them.

Now that we have a basic understanding of the technologies behind web services, let's discuss where they fit into our overall application architecture.