RMI : Java Glossary


RMI (Remote Method Invocation) — a specification for RPC (Remote Procedure Call). The client can invoke methods on objects remotely residing in the server, possibly passing it primitives or objects as parameters and receiving a primitive or object as a result. RMI has gone through several major revisions in the way it works. Unless you are going to work with older JVM (Java Virtual Machine) s, it is best to read only the most current documentation.
Advantages Stubs and Skeletons
Disadvantages Books
How It Works Learning More
The RMI Registry Links


The advantages of this technique are:


The disadvantages are:

How It Works

I saw a demo on coding and using RMI at the Java Colorado Software Summit in 1997. It was about 30 times simpler than I imagined it would be. Objects on the server make a call to register themselves as open for business. Objects on the clients make a connection request. Then from then on, the objects on the clients just invoke the methods of the objects on the server as if they were local. All the parameters and results get passed back and forth automagically in serialised form.

For a remote procedure call, there are two objects, one local proxy stub object and one remote real object. RMI can communicate in both directions between client and server. Let’s assume the client wants to execute a method on a remote server object, the usual case. The stub proxy object lives in the client’s address space. The real object runs in the server’s address space. The client invokes the method on the stub proxy, just as if it were working on the server’s object directly. RMI magic happens and the equivalent method call gets done on the server’s object and the results get passed back to the proxy stub object. To the client, it is just like a local method call. The only difference is it takes longer.

You don’t explicitly serialise. Your calls send primitives and references over the link as parameters. The objects and the code to manipulate the objects do not travel over the link.

The code on the server does all the application work. The stub code on the client just collects parameters and bundles them into objects to send to the server.

The method invoked on the server could do anything an ordinary method could do e.g. call other methods, read or write the disk, talk to a database engine, call methods remotely back to objects on the client…

You can’t call static methods remotely. If you needed to do so, you would have to call some remote instance method that did the static call for you. The only methods you can call remotely are methods in an interface that extends Remote.

The RMI Registry

A special program called the Registry runs on the server. This has absolutely nothing to do with the accursed Windows registry. The RMI Registry usually runs in the same JVM al the server. Even when it runs in its own JVM, it always runs on the same host. When you have separate JVM s, the objects themselves live in the server’s address space, not the registry’s. The registry allows server objects to register themselves as available to the clients. Clients can find a registered object by asking for it by name. Since each client gets given a reference to the single copy of the registered object running on the server, that object would be very busy. Typically it is a factory object that spins off other objects and threads that do the actual work. The registry is just to get started. Once you have a reference, you no longer need the registry. You can pass your reference onto others so they can use it without ever talking to the registry.

Stubs and Skeletons

There are two kinds of object in RMI, ordinary ones that don’t implement the Remote interface, and ones that do. Ones that do, have RMIC (Remote Method Invocation Compiler) stubs on both client (called a stub) and server (called a skeleton, but no longer needed in Java version 1.2 or later ). When you pass an object as a parameter to a remote procedure, it may go either by reference or by value. Only the server has the actual code for the class. RMI is a peer to peer protocol, so any station may act both as client and server. In Java version 1.4- you use rmic.exe to generate the stub classes. In Java version 1.5 or later, the RMI runtime does it automatically by constructing a java.lang.reflect.Proxy (not to be confused with java.net.Proxy) on the fly.

Ordinary objects go by value. The object may travel in either direction, client to server or server to client and may be passed as a parameter or returned as a result. The object’s datafields are pickled by serialization into an ObjectStream and reconstituted on the other end. You end up with two independent objects, one local and one remote. Changes made to one won’t be reflected in the other.

When you pass an object that implements Remote as a parameter, it goes by reference. but if and only if it is exported at the time. Otherwise, it is serialised and exported on arrival (so it acts like a mobile remote agent). This is the intention but there have been several bugs in this area. Exported just means the object is made visible to the outside world. Normal objects, even if they implement Remote, are private to that JVM. Exporting a remote object makes it available to accept incoming remote method requests. When you extend java.rmi.server. UnicastRemoteObject or java.rmi.activation.Activatable, your class will be exported automatically upon creation.

Microsoft Internet Explorer and Microsoft Java do not support RMI directly. You have to explicitly place the library files in an ARCHIVE statement and download the mother every time you run your Applet! ouch! You are better off using the Java Plug-in, or pre-installing the RMI class library, or running as an application rather than an Applet.


Learning More

Oracle’s Technote Guide on RMI Getting Started Tutorial : available:
Oracle’s Technote Guide on RMI FAQ : available:
Oracle’s Technote Guide on Codebase : available:
Oracle’s JDK Tool Guide to rmic : available:
Oracle’s JDK Tool Guide to rmiregistry : available:
Oracle’s JDK Tool Guide to RMI Activation System Daemon : available:
Oracle’s JDK Tool Guide to serialver command : available:
Oracle’s Javadoc on LocateRegistry.createRegistry : available:
Oracle’s Javadoc on Proxy class : available:

This page is posted
on the web at:


Optional Replicator mirror
of mindprod.com
on local hard disk J:

Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number