The Roles of Client and Server

Let's go back to that idea of locally collecting information on a client computer and sending the information across a network to a server. We are supposing that a user on a local machine will fill out an information request form. The data is sent to the vendor's server. The server processes the request and will, in turn, want to send back product information the client can view, as shown in Figure 5-1.

Figure 5-1. Transmitting objects between client and server

In the traditional client/server model, the client translates the request to an intermediary transmission format and sends the request data to the server. The server parses the request format, computes the response, and formats the response for transmission to the client. The client then parses the response and displays it to the user.

If you implement this approach by hand, there is a significant coding hassle: You have to design a transmission format, and you have to write code for conversion between your data and the transmission format.

NOTE

In this particular example, we assume that the client is a computer that interacts with a human user. However, the client could equally be a computer that runs a web application and that requires a service from a program that runs on another computer. You again have two communicating objects, the client object in the web application and the server object that implements the service. This is a very common model in practice. In the examples of this chapter, we stick to a more traditional client/server example because it makes the roles of the client and server more intuitive.

What we want is a mechanism by which the client programmer makes a regular method call, without worrying about sending data across the network or parsing the response. The problem is, of course, that the object that carries out the work is not located in the same virtual machine. It might not even be implemented in the Java programming language.

The solution is to install a proxy for the server object on the client. The client calls the proxy, making a regular method call. The client proxy contacts the server.

Similarly, the programmer of the server object doesn't want to fuss with client communication. The solution is to install a second proxy object on the server. The server proxy communicates with the client proxy, and it makes regular method calls to the server object (see Figure 5-2).

Figure 5-2. Remote method call with proxies

How do the proxies communicate with each other? That depends on the implementation technology. There are three common choices:

• RMI, the Java Remote Method Invocation technology, supports method calls between distributed Java objects.

• CORBA, the Common Object Request Broker Architecture, supports method calls between objects of any programming language. CORBA uses the Internet Inter-ORB Protocol, or IIOP, to communicate between objects.

• SOAP, the Simple Object Access Protocol, is also programming-language neutral. However, SOAP uses an XML-based transmission format.

NOTE

Microsoft uses COM, a different, lower-level protocol for interobject communication. ORB-like services are bundled into the Windows operating system. In the past, Microsoft positioned COM as a competitor to CORBA. However, at the time of this writing, Microsoft is deemphasizing COM and focusing on SOAP.

CORBA and SOAP are completely language neutral. Client and server programs can be written in C, C++, Java, or any other language. You supply an interface description to specify the signatures of the methods and the types of the data your objects can handle. These descriptions are formatted in a special language, called Interface Definition Language (IDL) for CORBA and Web Services Description Language (WSDL) for SOAP.

Quite a few people believe that CORBA is the object model of the future. Frankly, though, CORBA has had a reputationsometimes deservedfor complex implementations and interoperability problems. After running into quite a few CORBA problems while writing this chapter, our sentiments about CORBA are similar to those expressed by French president Charles De Gaulle about Brazil: It has a great future . . . and always will.

SOAP may have once been simple, but it too has become complex, as it acquires more of the features that CORBA had all along. The XML protocol has the advantage of being (barely) human-readable, which helps with debugging. On the other hand, XML processing is a significant performance bottleneck. Overall, CORBA is more efficient, although SOAP is a better fit for a web architecture.

If both communicating objects are implemented in Java code, then the full generality and complexity of CORBA and SOAP is not required. Sun developed a simpler mechanism, called Remote Method Invocation (RMI), specifically for communication between Java applications.

NOTE

CORBA supporters initially did not like RMI because it completely ignored the CORBA standard. However, starting with JDK 1.3, CORBA and RMI have become more interoperable. In particular, you can use RMI with the IIOP protocol instead of the proprietary Java Remote Method Protocol. For more information on RMI over IIOP, see the introductory article at http://www.javaworld.com/javaworld/jw-12-1999/jw-12-iiop.html and the tutorial at http://java.sun.com/j2se/1.4/docs/guide/rmi-iiop/rmiiiopexample.html. A very thorough example is at http://www.ociweb.com/jnb/jnbApr2004.html.

Because RMI is easier to understand than CORBA or SOAP, we start this chapter with a thorough discussion of RMI. In the last sections of this chapter, we briefly introduce CORBA and SOAP. We show you how to use CORBA for communicating between Java and C++ programs and how to access a web service with SOAP.