Loosely Coupled Services

[Previous] [Next]

Computers communicate internally using a set of interfaces. These interfaces are usually defined by the operating system platform and by the languages in which programs are written. On modern object-oriented platforms, you can write programs that can be reused by other programs. One example is the Microsoft COM architecture. COM components are usually stored in dynamic-link library (DLL) files. Application programmers can use these components as building blocks. Think about the dialog box you see whenever you want to print a document from your word processor in Microsoft Windows. The programmer who wrote the word processor probably didn't write all the code for that dialog box. The dialog box is likely built from components that are made available by the Windows operating system and called by the word processor. In fact, that's why most dialog boxes have a consistent look in Windows.

Objects are pieces of code that perform certain tasks. Objects stand alone, so many different applications can share them. This application independence leads to lower development costs because programmers can leverage work that's already been done.

Objects usually have properties and methods. A property is some attribute of an object that you can interrogate or set to some value. For example, you might set a property of a font-selection dialog box to display only monospace fonts when the dialog box is opened.

A method is a function that an object performs when asked. A method might be getStockPrice or multiplyTwoNumbers. Depending on the method, an object might perform many different actions to produce a result. To get stock prices, for example, an object would probably connect to a database containing current stock information. The processing done by the object to create its result is none of my business; all I want is the result. This kind of black-box functionality is an important point to remember as processing moves toward platform independence.

Sometimes a method requires parameters. You don't want some arbitrary stock price; you want to indicate which company's stock information you're interested in. In such a case, you might pass the name of the stock as a parameter to the function. The method might also allow you to pass a date or time to get historical information.

On UNIX platforms, reusable objects take the form of shared objects that work in the same way as COM objects. Java platforms have Enterprise Java Beans (EJB). A Java program can call upon an EJB to perform certain services, and a Windows program can call upon a COM object to do certain things, but because the two programs speak different interface languages, they usually have trouble calling each other.

Systems that rely on proprietary objects are called tightly coupled because they rely on a well-defined but fragile interface. If any part of the communication between application and service object is disrupted, or if the call is not exactly right, "unpredictable results may occur" (to quote my IBM mainframe programmers' reference documents).

Another problem with tightly coupled systems is cross-machine communications. A Windows program that calls upon a COM object for certain services expects the COM object to be on the current machine—that is, the machine running the program that calls the object. For example, a Web server might have a service, available as a COM object, that connects to a local database to retrieve historical stock information for a company. That arrangement works fine as long as the object and the requesting program are on the same physical machine. However, if one machine provides the historical stock information and several Web servers are part of a load-balanced array, or "farm," the requesting program is not on the same machine. To deal with this problem, Microsoft developed the Distributed Component Object Model (DCOM). With DCOM, a user can access services on a machine over a network connection and get whatever information the service provides over the same connection. This kind of distributed system is also tightly coupled, but not as tightly coupled as normal COM, which requires both the object and the requesting program to be on the same machine. This distributed model is also available on other platforms, but getting service from one platform to another platform is still difficult. For example, a Windows program cannot make a DCOM call to an EJB running on a Linux box across town—although this is exactly the kind of transaction that needs to happen if Web services are to work. Companies all over the world have data that other companies could access easily. However, if a company had to call directly upon the objects that generate that data, that company would run into the cross-platform compatibility problem I mentioned earlier. I can't directly invoke your EJB from my Microsoft Visual Basic application, and you can't directly invoke methods on my COM object from your Java program. To streamline communication between these object models, we need some way to decouple platform-specific requirements from the objects that create a view of data. The solution is the Simple Object Access Protocol, or SOAP. SOAP solves the problem of multiple platform incompatibilities in accessing data.

SOAP is a syntax that allows you to build applications for remotely invoking methods on objects. SOAP removes the requirement that two systems must run the same platform or be written in the same programming language. Instead of invoking methods through a proprietary binary protocol, a SOAP package uses an open standard syntax for making method calls. That syntax is XML. (Surprise!)

All information between the requesting application and the receiving object is sent as tagged data in an XML stream. This stream is a plain-text object that can be sent via HTTP through most existing firewalls. Figure 7-3 illustrates this process.

Figure 7-3. SOAP provides a way of invoking object methods over a simple HTTP connection. The steps of this diagram are described in Table 7-1.

As you can see in Figure 7-3, a SOAP client submits a request document over HTTP to a "listener" SOAP server at another site. This listening server captures the message, interprets the request, and invokes a method on an object in its domain. That object returns something useful to our application by responding through the SOAP server to our waiting client application. Table 7-1 explains the steps illustrated in Figure 7-3.

Table 7-1. A description of the steps illustrated in Figure 7-3.

Step in Figure	Description
1	A program, acting as a SOAP client, creates an XML document that contains the information required to remotely invoke a method on an external system. Don't think that a SOAP client is a traditional client. For example, a SOAP client could be your Web server or some server-based application, but it could also be a part of a client on the desktop. A SOAP client is simply the thing that makes a request from a SOAP server. The SOAP client wraps the XML document inside a SOAP envelope and is turned into an HTTP POST request.
2	This package is sent over a standard HTTP connection.
3	A listening application—by definition, a SOAP server—receives the message. This application is usually a Web server, which is listening for SOAP requests in its normal stream of calls for HTML pages. The SOAP server parses the SOAP package and calls the appropriate object, passing as necessary the parameters that were included in the SOAP document.
4	The object performs the requested function and returns information to the SOAP server. The SOAP server packages the response in a SOAP envelope.
5	The response object is sent back to the requesting machine. Once again, the SOAP document is encapsulated in an HTTP response header.
6	The SOAP client waits for the response object. When the SOAP client receives the object, it strips the SOAP envelope and sends the response document to whatever application needs it.

Since a SOAP document is being sent over HTTP (port 80), the document can go through almost any firewall—most firewalls are configured to allow such requests to move freely. Getting information between divergent platforms does not require any manipulation to the firewall infrastructure.

It is important to note that the object being invoked does not need any kind of modification. The SOAP server's job is to interpret the SOAP XML document that comes over the HTTP connection and turn it into a language the object understands. The SOAP server, then, acts as an interpreter, speaking both the SOAP language and the language of the object being called, and translating between the two. Therefore, the object can be written in any programming language on any platform. All communications are made by using documents written in XML syntax.