In order to carry out a remote procedure call, they stop the execution of the program. This quality is what defines RPCs as "blocking middleware." They also require more bandwidth than other types of middleware products, because carrying out a remote procedure call requires so much "overhead."
Over the years, RPCs have become a commodity product. For example, most UNIX systems ship RPC development libraries and tools as part of the base operating system. The best-known type of RPC is the Distributed Computing Environment (DCE) from the Open Software Foundation (OSF), now the Open Group.
DCE provides a very sophisticated distributed RPC mechanism with many layers of services (such as security, a directory, and the ability to maintain integrity between applications). Performance has been a problem with DCE. The DCE RPC performs as fast as any other RPC. Until quite recently, it worked faster than most implementations of IIOP. The problems are that the DCE directory (Cell Directory Service, or CDS) is not scalable, and the administration of a DCE environment is ugly. And for DCE to be effective, it must be deployed everywhere. Very few firms have been willing to make a total commitment to DCE.
Despite their simplicity, most RPCs are not well-performing middleware products. To function well, RPCs demand a tremendous level of processing power. In addition, many exchanges must take place across a network to carry out a request. As a result, they "suck the life" from a network or a computer system. A typical RPC call may require 24 distinct steps in completing requests-in addition to several calls across the network. This level of performance limits the benefits of making RPC calls across slower networks, such as the Internet. RPCs require 10,000 to 15,000 instructions in order to process a remote request. That's several hundred times the cost of a local procedure call (a simple function call). As is the case with DCE, the RPC software also has to make requests to security services in order to control access to remote applications. Calls to naming services and translation services may be required as well. All of this inevitably adds to the already bloated overhead of RPCs.
As we've noted, the advantage of RPCs is simplicity-of the mechanism and the programming. However, when this simplicity is weighed against the huge performance cost of RPCs and their inability to scale well (unless combined with other middleware mechanisms, such as a TP monitor or message-queuing middleware), it doesn't seem to be such a tremendous benefit.
RPCs are bundled into so many products and technologies, it is difficult to know when they are in use. For example, CORBA-compliant distributed objects are nothing more than an additional layer on top of an RPC. As a result, they rely on synchronous connections to communicate object to object (although they are now deploying messaging and transaction services as part of the standard). This additional layer translates directly to additional overhead when processing a request between two or more distributed objects.
This structure is the reason that distributed objects, although architecturally elegant, generally don't scale or provide good performance. The Object management Group (OMG), the consortium of vendors that created CORBA, is working with CORBA vendors to solve the performance problem.
This was first published in June 2001