-
What is RMI ?
RMI is a mechanism for communicating (only) between two machines running
Java Virtual Machines.When Java code on machine A needs a
service or a method, respectively, of (remote Java object) objB
on machine B it starts a remote method invocation. It does this
the same way as invoking a local (Java) object's method.The whole communication
behind the remote invocation is done by the RMI mechanism.
-
How RMI works ?
When referencing a remote object residing on machine B from code being
on machine A there are always two intermediate objects actually handling
the communication: a stub object and a skeleton object. When
a remote method invocation comes up the following tasks are handled by
these two objects (see also figure):
The stub object (on machine A) has to
-
build an information block thats consists of
-
an identifier of the remote object to be used,
-
an operation number describing the method to be called and
-
the marshalled parameters (method parameters have to be encoded into a
format suitable for transporting them across the net)
-
send this information to the server
The tasks of the skeleton object (on machine B) are
-
to unmarshal the parameters,
-
to call the desired method on the real object lying on the server,
-
to capture the return value or exception of the call on the server,
-
to marshal this value,
-
to send a package consisting of the value in the marshalled form back to
the stub on the client, machine A.
The stub object unmarshals the return value or exception from the
server. This value becomes the return value of the remote method invocation.
Or, if the remote method threw an exception, the stub (object) rethrows
it in the process space of the caller.
-
Example
To get a better feeling how to deal with RMI, let's give a little example:
Let's assume there is a remote object belonging to the class Product
offering the method getDescription(), whose return value is
a String object. Let's further assume this method is invoked by
a remote machine (not very surprising). The following figure shows what
is going on in order to handle this situation, on client side as well as
on server side.
-
Processes and their relationships
Three processes are involved in the RMI scenario described above.
The registry process has to be started at first. It observes a specific
port for bindings between logical names and real objects (the same port
also serves lookups). Afterwards the server process is started on the same
machine. It gives the binding information to the registry process by sending
them to the corresponding port. Then everything has be done on server side.
Now any client process can be started. It will send lookups to the port
of the registry process. Now a connection via a stub object and a
skeleton object becomes established. Concerning a detailled description
of this process I recommend following the bibliographical links.
-
Notes
-
For any remote object (getting a reference on client side) there is one
stub object (on each client side) and one skeleton object (on server side).
These objects are created automatically; however the corresponding classes
(in our example ProductImpl_Stub.class and ProductImpl_Skel.class)
must have been created (by the rmic command) and must be available,
respectively.
-
Parameters of remote method invocations:
-
Remote objects are passed back as stubs.
-
Non-remote objects are copied and get serialized (so they have to implement
the interface Serializable)
-
Useful bibliographical links
In order to get a deeper insight in the RMI stuff I recommend to have
a look at