7.1.2: Remote Method Invocation (RMI)

How RMI Works:

To build an RMI application, developers follow steps similar to RPC but in Java terms:

1. Define a remote interface (declaring the methods that can be called remotely, each throwing RemoteException).
2. Implement the remote interface in a server class (which typically extends UnicastRemoteObject to allow remote invocation).
3. Start an RMI registry and deploy the server object, binding it to a name in the registry.
4. Lookup the remote object on the client via the registry to get a stub.
5. Invoke methods on the stub as if it were a local object – the RMI infrastructure will transmit the call to the server and return results.

Under the hood, RMI generates stubs and skeletons (in Java <=1.4, skeletons were used; later versions generate stubs dynamically). The stub on the client side forwards method calls to the remote JVM, and the skeleton on the server side dispatches calls to the actual implementation. The parameters are passed either by value (serialized copies of objects) or by remote reference (if the parameter is itself a remote object). RMI includes features like distributed garbage collection (to auto-release remote objects when not referenced) and dynamic class loading (if the client needs the definition of a custom object returned from server, it can download the bytecode from a provided codebase).

Advantages and Limitations:

RMI’s advantages include seamless integration with Java (the developer can use Java objects and interfaces naturally) and built-in garbage collection of remote objects. It abstracts networking to a large extent. However, RMI is limited to Java – both client and server must be written in Java and running a JVM. This tight coupling to Java means RMI is not suitable for heterogeneous environments where different languages need to communicate. Furthermore, RMI’s portability is limited by the need for a common Java version and the security constraints (it may require policy files and security managers for certain operations). Because of these limitations, RMI is primarily used in Java-centric systems. In modern cloud environments that embrace polyglot services, RMI has largely been superseded by more language-neutral approaches (like REST or gRPC), but it laid important groundwork in distributed object design.