Simply stated, computers need to share data. Many scenarios bear this out: Businesses need to share information with partners. Divisions need to send data to other divisions. Consumer applications need to work with other consumer applications.

Recently, Microsoft identified several different application types that could use Web services:

A typical use of Web services would be a help desk application. Help desk applications are often small Windows applications that enable help desk operators to query for internal customer data, and then update this data with whatever information they gather during the course of a help desk call. The developers of this type of application need to pull out information about each employee who calls from the central employee database. They also need to pull out and modify data from their own help desk database.

Distributed application development is the art and engineering of getting data from one machine to another. This data can be of almost infinite variation: purchase orders, customer data, digits 100 through 200 of pi, and so on. There have been many technologies for building applications that can send data back and forth. CORBA (Common Object Request Broker Architecture), RMI (Remote Method Invocation), and DCOM (Distributed Component Object Model) are just a few.

However, all of these have had flaws, and none has ever caught on for ubiquitous and heterogeneous environments. Most haven't even tried to make that a design goal. For example, DCOM is based on COM (Component Object Model), which is a binary standard that has virtually no deployment outside of the Microsoft Windows platform. Although using DCOM across platforms is technically possible, it is wishful thinking to think that DCOM would ever be employed in such an environment. No one has ever really tried and succeeded in a stable and cost-effective manner.

Common Object Request Broker Architecture, or CORBA, is a distributed technology (actually, a specification of a technology) that can and does work in heterogeneous environments. However, for many reasons, including that many developers find it difficult to implement CORBA-based applications and services, CORBA has never really caught on.

Simple Object Access Protocol, or SOAP, is a new step in the world of distributed applications. Web service technologies such as SOAP have made much quicker inroads for distributed application development than did earlier technologies. Among the many reasons for SOAP's success, the most important are that it

The sections that follow closely examine these reasons for SOAP's success.

The Web architecture assumes and deals gracefully with failure, latency, and all kinds of other real-world problems. This is a major strength and one that Web services have for the most part inherited. When you launch a Web browser, you expect that a number of the pages, graphics, and other files that you try to download will challenge you for credentials, or will have moved locations, or simply will no longer exist. Web services are challenged with the realities of this environment.

Assuming failure is a more advanced concept than it seems at first. For example, imagine you are building an application that will download a movie. As the size of your movie increases, the likelihood of some of the packets getting lost increases as well. As the developer of this application, you have a few choices: You can re-download every frame if you lose any one frame, you can ask for just the frames you missed, or you can skip them. Clearly the first choice isn't the best one, but deciding between the next two is difficult.

At its most basic level, the Web makes the last choice: It forgets about what it loses. This is an interesting choice, and it seems like the wrong one on the face of it. But the alternative requires a huge investment in infrastructure to make it work. Clearly, sometimes you need a thick and durably reliable infrastructure, but not always.

Imagine how much more traffic would be generated if your browser acknowledged every image it was downloading, and then the server resent until you received the image. As another example, consider the ubiquitous 404 error code: Built into the HTTP specification itself is the idea that a file may be missing from the server.

The Web is also hugely concurrent. It's the most concurrent system ever seen in computers. Every Web server and every client is operating in parallel. But programming for concurrency is extremely difficult. This is one of the ironies of modern Web development: The system itself is by definition almost unmanageably hard to develop for. The essential challenge is to handle state in an effective manner that takes into consideration the principle of assuming failure.

Web services are a set of technologies that enable you to develop distributed applications which take both failure and concurrency into account. Before we examine in more detail how Web services do this, let's take a moment to define what a Web service is.

The Significance of Loose Coupling

Another powerful feature of Web services is how easily they allow you to build loosely coupled systems. Loosely coupled is another term that is difficult to define precisely. In general, when I say loosely coupled, I mean that a system exhibits both implementation independence and versioning without breakage.

Implementation independence is an easy enough concept to get across. If I want to implement the same Web service on machine A to machine B, then it shouldn't matter that machine A is a Java/UNIX program and machine B is a C#/Windows program. This is a basic requirement of Web services.

Versioning ease via loose coupling is a little harder to describe and grasp at first. Clearly, a machine running a version 1 client can expect to interoperate with a version 1 server. But what about mismatched versions? If machine A is running version 1 of a service and sends a message to machine B, which is running version 2, then machine B should be able to receive and understand the message. Of course, Web services don't make this possible in every case because there is always the human element to deal with: business rules and other facts of the real world. Regardless, versioning without breakage is a genuine goal, and a powerful one. Figure 1.1 gives an example of this.

Figure 1.1. Versioning Web Services

A core concept of Web services (in particular, the wire protocol: SOAP) is that they are very modular. One flaw of many other attempts at distributed application development specifications has been a reliance on getting everything into one specification. For example, if you don't need transactions, then there is no need to implement them. SOAP doesn't try to be a complete distributed application technology. It has many, many holes, and this is by design.

By focusing on simplicity and extensibility, it's possible to create distinct specifications for security, transactions, reliability, and so on without drowning in complications. Applications can combine features from specifications they need, including custom modules.

One of the design tenets of this book is that leveraging modularity is critical. Your own designs for Web services should follow a pattern similar to the standards. There are several rules by which to live:

You may have noticed that I used the term message passing earlier. At a very fundamental level, Web services are expressed in messages that are sent from one process to another. Typically (and I would argue that this is a near requirement), those messages are XML based. The message is the core piece of Web services. It is like the function in the C programming language: Just as you can't discuss C without discussing functions, you can't discuss Web services, in particular SOAP, without talking about messages.

As a matter of fact, we can mimic function calls with messages—two to be exact. We can map the first message, the request, to the function call with the parameter values, and express the return value and out parameters as a response message. When we combine a set of messages into a logical unit in this way, we call them an operation. The request–response operation is the most common in the Web services world. Listing 1.1 shows a typical SOAP message (in this case a request for a stock quote).

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
   <SOAP-ENV:Header>
       <t:SessionOrder
         xmlns:t="http://example.com"
         xsi:type="xsd:int" mustUnderstand="1">
           5
       </t:SessionOrder>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
       <GetStockQuote
         xmlns="http://someexample.com">
           <Price>MSFT</Price>
       </GetStockQuote>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The difficult thing about messages is that they are essentially asynchronous and very concurrent. Nothing in the SOAP specification or the Web architecture in general guarantees that a machine on a network will receive the messages I send in the same order in which I sent them.

Dealing with asynchronous and concurrent behavior is difficult. However, most current Web service implementations already have been fairly successful at mapping the more familiar synchronous programming model on top. This programming model is appropriate for many uses, but never forget that you are really dealing with something unlike a call stack in a computer with a single processor. You are dealing with a much more complex system.

As noted earlier, the Web architecture assumes failure. Web services inherit HTTP's design principle regarding failure, and attempt to improve on it. The SOAP specification has an entire section devoted to describing exactly how errors can be communicated. Of course, programmatic errors (either in the system or in the application) aren't the only kind of failures you can experience.

For example, when you surf, you will often find that the page you are trying to access no longer exists. In other words, you'll see the Web master's dreaded 404 Not Found error. There is actually a large set of similar errors that HTTP presupposes may occur, such as pages moving either temporarily or permanently.

Web services inherit this idea of assuming failure and build on it. A significant section of the SOAP specification is about SOAP faults. A SOAP fault is a special message type used specifically for sending errors; Listing 1.2 shows an example. SOAP also specifies faults for an interesting set of failures. For example, SOAP defines the error you are supposed to send when you don't understand a SOAP header.

HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Body>
       <SOAP-ENV:Fault>
           <faultcode>SOAP-ENV:MustUnderstand</faultcode>
           <faultstring>Something bad happened.</faultstring>
       </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Microsoft, IBM, and others have created a set of specifications and technologies surrounding their vision for Web service architecture of the future. These specifications fill in the gaps that SOAP and WSDL don't address. You can easily identify these specifications, as they follow the naming scheme WS-technology, where the technology is something like security. This architecture is a vision that is shared across the industry and includes many of the ideas presented in this chapter so far, such as modularity and building on Web standards.

This Web service architecture includes a distinct and credible vision for how all of the modular pieces are to be plugged together. This vision is for a set of related specifications that are

We've looked at why standards and modularity are a good idea. Federated designs are useful because they eliminate one of the key problems with most client-server applications: the reliance on a server.

Imagine you have a customer relations application that needs to retrieve customer information from a central server. With most distributed application technologies, you would be hard pressed to come up with a more federated design that would allow you to roll over in case of failure. Web services enable developers to create a more flexible design with ease. Gnutella, Freenet, and UDDI (Universal Description, Discovery, and Integration) are all popular distributed applications that are also federated ones. In part, their popularity is because of this nonlocalized design.

Another goal of Web service architecture is to be general purpose. In other words, a mature Web service architecture can be applicable both to high-end server machines and to compact devices such as a cell phone. This general-purpose design means that the standards you use and learn now will be applicable to a wide range of scenarios and targets.

The baseline specifications are the standards on which the Web service architecture builds to provide many of the other features needed in many distributed applications. The protocols that form the basis of the Web service architecture include SOAP, WSDL, and UDDI.

You can think of XML and HTTP as pre-baselines. But SOAP, UDDI, and WSDL are really where the Web services world begins in earnest. Chapter 2 (XML Web Services Standards) details how these standards are linked together, and how they provide a simple, modular architecture for building, describing, and finding Web services.

The term Web services refers to a set of technologies that are the future of distributed computing. The reasons why they are so apt for distributed computing include the following: