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?
-
Java-RMI
is a Java-specific middleware spec that
allows client Java programs to invoke server
Java objects as if they were local.
-
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.
-
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.
-
Because
of this, parameters passed during method
calls between machines can be true Java
Objects. This is impossible in DCOM or CORBA
at present.
-
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.
-
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.