Gopalan Suresh Raj's Web Cornucopia
An Oasis for the parched Enterprise Services Engineer/Developer

    Distributed Computing-Java Remote Method Invocation

    Distributed-Computing

    Remote Method Invocation (RMI) is the object equivalent of Remote Procedure Calls (RPC). While RPC allows you to call procedures over a network, RMI invokes an object’s methods over a network.

    In the RMI model, the server defines objects that the client can use remotely. The clients can now invoke methods of this remote object as if it were a local object running in the same virtual machine as the client. RMI hides the underlying mechanism of transporting method arguments and return values across the network. In Java-RMI, an argument or return value can be of any primitive Java type or any other Serializable Java object.

    What is Java-RMI and how does it compare with other Middleware Specifications?

    1. Java-RMI is a Java-specific middleware spec that allows client Java programs to invoke server Java objects as if they were local.
    2. Java-RMI is tightly coupled with the Java language. Hence there are no separate IDL mappings that are required to invoke remote object methods. This is different from DCOM or CORBA where IDL mappings have to be created to invoke remote methods.
    3. Since Java-RMI is tightly coupled with The Java Language, Java-RMI can work with true sub-classes. Neither DCOM nor CORBA can work with true subclasses since they are static object models.
    4. Because of this, parameters passed during method calls between machines can be true Java Objects. This is impossible in DCOM or CORBA at present.
    5. If a process in an RMI system receives an object of a class that it has never seen before, it can request that its class information be sent over the network.
    6. Over and above all this, Java-RMI supports Distributed Garbage Collection that ties into the local Garbage Collectors in each JVM.

    What makes Java-RMI tick

    Since both the client and the server may reside on different machines/processes, there needs to be a mechanism that can establish a relationship between the two. Java-RMI uses a network-based registry program called RMIRegistry to keep track of the distributed objects. (Note: The RMI Registry is an RMI server itself!!!)

    The RMI Registry

    The server object makes methods available for remote invocation by binding it to a name in the RMI Registry. The client object, can thus check for the availability of a certain server object by looking up its name in the registry. The RMI Registry thus acts as a central management point for Java-RMI. The RMI Registry is thus a simple name repository. It does not address the problem of actually invoking remote methods.

    Stubs and Skeletons

    Since the two objects may physically reside on different machines, a mechanism is needed to transmit the client’s request to invoke a method on the server object to the server object and provide a response. Java-RMI uses an approach similar to RPC in this regard. The code for the server object must be processed by an RMI compiler called rmic, which is part of the JDK.

    The rmic compiler generates two files: a stub and a skeleton. The stub resides on the client machine and the skeleton resides on the server machine. When a client invokes a server method, the JVM looks at the stub to do type checking. The request is then routed to the skeleton on the server, which in turn calls the appropriate method on the server object. In other words, the stub acts as a proxy to the skeleton and the skeleton is a proxy to the actual remote method.

    Author Bibliography

    Gopalan Suresh Raj is a Senior Analyst, Software Architect, and Developer with expertise in multi-tiered systems development, enterprise service architectures, and distributed computing. He is also an active author, including contributions to Professional JMS Programming, Wrox Press, 2001, Enterprise Java Computing-Applications and Architecture, Cambridge University Press, 1999, and The Awesome Power of JavaBeans, Manning Publications Co., 1998. He has submitted papers at international fora, and his work has been published in numerous technical journals. Visit him at his Web Cornucopia© site (webcornucopia.com) or mail him at gopalan@webcornucopia.com.

    Back