NETWORKS AND DISTRIBUTED SYSTEMS

Networks and Distributed Systems

Networks and Distributed Systems

Remote Procedure Call (RPC) systems abstract the communication interface to the level of a procedure call. Thus, instead of application programmers having to deal directly with sockets, the programmer has the illusion of calling a local procedure when, in fact, the arguments of the call are packaged up and shipped off to the remote target of the call. Such RPC systems encode arguments and return values using some type of an external data representation (e.g., XDR).

RPC, however, does not translate well into distributed object systems where communication between program level objects residing in different address spaces is needed. In order to match the semantics of object invocation, distributed object systems require remote method invocation or RMI. In such systems, the programmer has the illusion of invoking a method on an object, when in fact the invocation may act on a remote object (one not resident in the caller's address space).

Remote Procedure Call Systems have been around since Andrew Birrell and Greg Nelson first proposed them in 1984.1 During the intervening 15 years, numerous evolutionary improvements have occurred in the basic RPC system, leading to improved systemssuch as NCS2that offer programmers more functionality or greater simplicity. The Common Object Request Broker Architecture from the Object Management Group! and Microsoft's Distributed Common Object Model4 are this evolutionary process's latest outgrowths.(Birrell 2008:39-59)

With the introduction of java Developer's Kit release 1.1, a third alternative for creating distributed applications has emerged. The Java Remote Method Invocation system has many of the same features of other RPC systems, letting an object running in one Java virtual machine make a method call on an object running in another, perhaps on a different physical machine.

On the surface, the system is just another RPC mechanism, much like Corba and DCOM. But on closer look, RMI represents a very different evolutionary progression, one that results in a system that differs not just in detail but in the very set of assumptions made about the distributed systems in which it operates. These differences lead to differences in the programming model, capabilities, and way the mechanisms interact with the code that implements and built the distributed systems.

Corba and DCOM (and earlier systems in the RPC evolutionary line) were built on assumptions of heterogeneity. These mechanisms assume that the distributed system contains machines that might be different, running different operating systems. The machines' instruction sets might differ. Indeed, data representations might differ from one machine to another.

This heterogeneity is the central problem that systems such as Corba were designed to solve. As their solution, these systems introduced proxies on each machine that could process information passing from one member of the distributed system to another. The processing converted the information from the format known by one member into a format known by the other.

The proxy on the client (calling) side became known as a stub, while the proxy on the server (receiving) side became known as the ...