XML —

Communication over Distributed Systems

Distributed systems commonly use two models for communication: message passing (which can be combined with message queuing) and request/response messaging system. A message passing system allows messages to be sent at any time. Once a message has been sent, the application that sent the message usually moves on. This type of system is called asynchronous. An asynchronous system typically uses messages, but it can also be based on other models. With the request/response model, the request and the response are paired together and can be thought of as a synchronous system. The request is sent by an application, and the application usually waits until a response is received before continuing. When one application calls an object on another computer by making a Remote Procedure Call (RPC), we can think of this call as synchronous request/response message passing.

The request/response model is commonly used to allow components on different computers to communicate with each other using RPCs. Over the last several years, many attempts have been made to develop a standard that would allow this communication between components on different computers. Currently, the two most commonly used standards are Distributed Component Object Model (DCOM) and the Object Management Group's Internet Inter-Orb Protocol (IIOP). Both of these standards work well; their greatest shortcoming is that they do not natively interoperate with each other. Therefore, you cannot arbitrarily make a call to a component on a server from a client without first knowing what standard that server is using. Usually, you will also have to configure the client so that it can communicate with the server, especially when there are security issues. DCOM works best when all the computers in the system are using Microsoft operating systems. An IIOP system works best when all the computers in the system use the same CORBA Object Request Broker (ORB).

NOTE
IIOP is only a specification: it will be up to individual vendors to create an implementation of the specification in the form of an ORB. There are currently many different ORBs.

When you are working on an internal system, it might be possible to limit the system to one platform or the other. Once you start working with the Internet or expanding the intranet out to extranets (for example, networks that include the corporation and its partners), it will usually be impossible to have a uniform platform across the entire system. At this point, DCOM and IIOP will no longer allow communication between any two components within the system, and neither of these two standards allows users to cross trust domains easily. Thus, for larger systems expanding across computers with multiple platforms, we need a way to enable objects to communicate with each other. The solution to this problem is SOAP.

SOAP and the Request/Response Model

The SOAP standard introduces no new concepts-it's built completely from existing technology. It currently uses HTTP as its request/response messaging transport and is completely platform independent. As you know, HTTP connects computers across the entire world. HTTP can go through firewalls and is the easiest means to transport messages to any computer in the world. It's likely that SOAP will evolve to use other protocols in the future.

A SOAP package contains information that can be used to invoke a method. How that method is called is not defined in the SOAP specification. SOAP also does not handle distributed garbage collection, message boxcarring, type safety, or bidirectional HTTP. What SOAP does allow you to do is pass parameters and commands between HTTP clients and servers, regardless of the platforms and applications on the client and server. The parameters and commands are encoded using XML. Let's take a look at how SOAP uses the standard HTTP headers.