Java Remote Method Invocation

Gopalan Suresh Raj


Java-RMI Under the hood Java RMI - Under the Hood
Security Issues A Java/RMI Server
ActiveX Automation A Java/RMI Client
ActiveX Automation Download the Entire source as a zip file
Security Issues Getting Java/RMI to work on MS-IE & Netscape
A Detailed Comparison of CORBA, DCOM and Java/RMI
Developing a Java/RMI Server Component using IIOP
Developing a Java/RMI Client to our RMI/IIOP Server Component
Developing a CORBA Client to our RMI/IIOP Server Component


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.

More to come soon...


Go to the Component Engineering Cornucopia page

This site was developed and is maintained by Gopalan Suresh Raj

This page has been visited times since July 06,1998.

Last Updated : July 06, '98

If you have any questions, comments, or problems regarding this site, please write to me I would love to hear from you.

Copyright (c) 1997-99, Gopalan Suresh Raj - All rights reserved. Terms of use.

All products and companies mentioned at this site,are trademarks of their respective owners.