RPCs

As we noted in an earlier chapter, RPCs are nothing more than a method of communicating with a remote computer, a method in which the developer invokes a procedure on the server by making a simple function call on the client (see Figure 7.7). By functioning in this way, RPCs hide the intricacies of the network and operating system. (Remember, the client process that calls the remote function must suspend itself until the procedure completes.)

Figure 7.7. Using RPCs.

RPCs are easy to understand and just as easy to use. Even so, they can be problematic when incorporated into an application integration problem domain. The need to stop an application from processing during a remote call could limit the performance of the application. In addition, because RPCs demand a high level of network communication between the client and the server, RPC architecture requires a high-speed network. Most application integration solutions run across the Internet, which is anything but high speed.

RPCs formed the base middleware layers in early client/server systems. Then, as now, they functioned as database-oriented middleware layers. In addition, they are capable of running network operating systems, such as Sun's Network File System (NFS) and Open Software Foundation's DCE. Distributed object technology, such as COM and CORBA, effectively leverage RPCs to provide object-to-object communication.