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