Java RMI

RMI Stands for Remote Method Invocation. RMI is an API that provides you an interface to make
remote procedure calls. Remote procedure calls forms the basis for creating distributed, client
server applications. Let me explain what a remote procedure call means exactly. You developed a
java application in your local machine. That application contains many classes and each class
contains many methods. Now, consider a situation, where from one class, you need to call a method
that belongs to some other class. To satisfy this requirement, first you will create an object of the
class whose method you want to call. If the method you are trying to call is a static method, then
there is no need for the instance of the class. But if it is a non-static method, then you need an
object of that class. Progressively, using this classs object, you will call a method of that class. This
process is called local procedure calling.
When it comes to remote procedure calls, the process is the same. In remote procedure calls, the
method you are trying to invoke belongs to some other java process. This java process may be
running on the same machine or on some remote machine. In both the case, if you are calling a
method that belongs to some other java process than the one from where you are calling, then it
becomes remote procedure call. Usually, this type of calling happens between the java processes
running on different machines. The idea here is that the address space being used by two processes
should be different.
Using the remote procedure call, developers need not worry about the details of the interface with
the network. The transport independence provided by RPC isolates the application from the physical
and logical elements of the underlying communication mechanism which allows the application to
make use of many types of transport methods.
In computer programming jargon, RPC is an inter-process communication that allows computer
programs to allow a procedure or function execute in another address space without a programmer
explicitly programs the details for this remote invocation.
Process of communication that happens in RPC
A client initiates an RPC and sends a request message to the known remote server to execute a
specified procedure with supplied parameters. The remote server sends the response to the client
and the client application continues to execute. Until unless the client wishes not to do so, it has to
wait until it receives the response from the client. This is like synchronous communication. Following
is the sequence of steps followed in RPC.
1. The client calls the stub. Stub is a piece of code which is responsible for converting the
parameters that are to be passed on to remote method into serializable format so that they
can be transmitted over the wire onto the remote machine.
2. The call to this stub is something like a call to a local method. Here the parameters are
pushed onto the stack in the normal way.
3. The client stub, then converts the parameters into serializable format and packs them in a
message. Once packing is done, it makes a system call to send the message. This packing of
parameters is called Marshalling.
4. The clients local OS then sends the message to the remote machine
5. There will be a server stub running on the server machine. The server OS on receiving this
message from client machine passes the incoming message packets to its server stub.
6. This server stub, in turn, reads the message, unpacks the parameters from the message. This
process of unpacking is called Un-Marshalling.
7. After unpacking the parameters, server stub then calls the server procedure and passes it
the parameters that are unpacked. For sending the response, the same process will be
followed.
In order to make use of RMI effectively, we need to understand the components that are involved in
using RMI. Following are the components that are involved.
1. An interface that extends Remote interface. This is the interface that is used by client to
get the remote object and also this is the interface that tells the client what methods of the
remote object can be called by the client.
2. A Server class: Server class must be listening to the RMI calls and should implement the
above interface so that client will know what methods to call on remote object. In order to
make Server class to listen to RMI requests, it has to extend the UnicastRemoteObject
class. This class is responsible for listening to the RMI Requests.
3. A client class
Explanation of above steps
As part of writing the client server applications using RMI, above three steps are mandatory. An
interface can be any user defined interface that contains any method definitions as we need. The
only requirement to make it useful in RMI is to extend that interface with Remote interface. This
Remote interface will be available in java.rmi package.
Once the interface is created, then this interface will be used by both client and server applictions.
Server class have to implement this interface and need to provide concrete implementation of all
the methods defined in the interface. Apart from this, server class also need to extend the
UnicastRemoteObject. This class will be present in java.rmi.server package. Once Server class is
defined in the specified way, in the implementation of server class, we need to create a registry that
will be listening on a specific port. Once the registry is created, an object of this server class will be
created and this object will be registered with this registry. Here, registering the object is nothing
but binding the object with the registry. With this, server functionality is done.
Now, for the client to make a call to this remote object method, first client has to look up the
registry and find the required object. Once it is found, the object is retrieved and the required
method will be called on that object as if making a local call.
Broader Understanding of RMI
RMI provides facilities to clients to access a remote object. This can be done in two ways as below
1. Pass by reference
2. Pass by value
Lets understand each method.
Pass by Reference
When client needs to access a remote method using pass by reference, they have to make use of
Remote interface provide by java.rmi package. In this method, we need an interface that defines
all the methods that needs to be exposed to the client and this interface must extend Remote
interface. Then, server application should extend this custom interface.
In this method, client will be able to access only those methods that are defined in the interface. In
this process, to call the remote method, the stub class should be placed on client machine. This is
because, when client makes a remote procedure call, the call will be passed on to the stub class. This
stub class in turn sends the request to the server. The server then sends back the object in context
to client and this object will be replaced with the stub class and is returned to the client. In this
method, all the calls still are happening remotely and all the remote machine services and resources
will be made available to the client. Any changes made to the state of the object in this method will
be visible to all other users because everyone are working on the same object.
Even though client has the facility to access all the server resources and services, there are still
problems present that are related to network because all the calls made here are remote calls. In
this process, to make it work properly, all you need to do is to ensure that the server application is
exported properly onto the server and then make to listen to RMI calls properly.
Pass by value
In this method, when client try to make RPC, the remote call returns an object that implements
Serializable interface instead of Remote interface. Here, the object first will be serialized and then
transferred over the network to the client and on client machine, it will be deserialized. Once
deserialization is done, the object will be instantiated.
In this method, client will not have access to any of the server resources. But the advantage is that
there is no network problems involved. The calls on these objects are just like local calls. Any
changes made to the state of this object is not visible to other users who are working on the same
object