This Presentation shows the working of Java RMI technology, it's advantage over RPC, it's class hierarchy API and finally implementation of Factorial program using Java RMI.

1. Java RMI

2. What is RMI?
● RMI stands for Remote Method Invocation.
● It is a mechanism that allows an object residing in one
system (JVM) to access/invoke an object running on another
JVM.
● RMI is used to build distributed applications; it provides
remote communication between Java programs.
● It is provided in the package java.rmi.

3. Difference between RPC and RMI
RMI
● RMI is limited to Java.
● RMI is Object Oriented.
● RMI allows Objects to be passed as
arguments and return values.
● RMI is easy to program than RPC
● RMI is slower than RPC since RMI
involves execution of java bytecode.
● RMI allows usage of design patterns
due to the object oriented nature.
RPC
● RPC is Language Neutral.
● RPC is Procedure Oriented like C
● RPC supports only Primitive Data types.
Programmer may split any compound
objects to primitive data types.
● RPC is a bit difficult to program when
compared to RMI.
● RPC is faster than RMI.
● RPC does not have the capability to use
design patterns.

4. Why do we prefer RMI over RPC?
● RPC is a language neutral mechanism that allows calling of a
procedure on a remote computer. However, the language neutral
feature limits the data types that are passed as arguments and return
values to primitive types.
● RMI is the implementation of RPC in Java and it supports object
passing as well, making the life of the programmer easier.
● The advantage of RMI is the object oriented design support, but
limitation to Java is a disadvantage.

5. Architecture of an RMI Application
In an RMI application, we write two programs, a server program
(resides on the server) and a client program (resides on the client).
● Inside the server program, a remote object is created and
reference of that object is made available for the client (using the
registry).
● The client program requests the remote objects on the server and
tries to invoke its methods.

6. The following diagram shows the architecture of an RMI application.

7. Let us now discuss the components of this architecture.
● Transport Layer − This layer connects the client and the server. It manages the
existing connection and also sets up new connections.
● Stub − A stub is a representation (proxy) of the remote object at client. It
resides in the client system; it acts as a gateway for the client program.
● Skeleton − This is the object which resides on the server side. Stub
communicates with this skeleton to pass request to the remote object.
● RRL(Remote Reference Layer) − It is the layer which manages the references
made by the client to the remote object.

8. Working of an RMI Application
● When the client makes a call to the remote object, it is received by the stub
which eventually passes this request to the RRL.
● When the client-side RRL receives the request, it invokes a method called
invoke() of the object remoteRef. It passes the request to the RRL on the
server side.
● The RRL on the server side passes the request to the Skeleton (proxy on
the server) which finally invokes the required object on the server.
● The result is passed all the way back to the client.

9. Marshalling and Unmarshalling
Whenever a client invokes a method that accepts parameters on a remote
object, the parameters are bundled into a message before being sent over
the network. These parameters may be of primitive type or objects. In case
of primitive type, the parameters are put together and a header is attached
to it. In case the parameters are objects, then they are serialized. This
process is known as marshalling.
At the server side, the packed parameters are unbundled and then the
required method is invoked. This process is known as unmarshalling.

10. RMI Registry
RMI registry is a namespace on which all server objects are placed.
Each time the server creates an object, it registers this object with the
RMIregistry (using bind() or reBind() methods). These are registered
using a unique name known as bind name.
To invoke a remote object, the client needs a reference of that object.
At that time, the client fetches the object from the registry using its
bind name (using lookup() method).

11. The following illustration explains the entire process −

12. Goals of RMI
Following are the goals of RMI −
● To minimize the complexity of the application.
● To preserve type safety.
● Distributed garbage collection.
● Minimize the difference between working with local and
remote objects.

13. RMI Components
The RMI application contains the THREE components
(1) RMI Server
(2) RMI Client
(3) RMI Registry

15. Components Explained
(1) RMI Server:
RMI Server contains objects whose methods are to be called remotely. It creates
remote objects and applies the reference to these objects in the Registry, after that
the Registry registers these objects who are going to be called by client remotely.
(2) RMI Client:
The RMI Client gets the reference of one or more remote objects from Registry with
the help of object name. Now, it can be invokes the methods on the remote object
to access the services of the objects as per the requirement of logic in RMI
application.
Once the client gets the reference of remote object, the methods in the remote
object are invoked just like as the methods of a local object.

16. (3) RMI Registry:
In the Server side the reference of the object (which is
invoked remotely) is applied and after that this reference is
set in the RMI registry.
When the Client call the method on this object, it’s not
directly call but it call by the reference which is already set in
the Registry so first get the object from this reference which is
available at RMI Registry then after calls the methods as per
the requirement of logic in RMI application.

17. Java RMI Class Hierarchy
●java.rmi Package
●java.rmi.server Package
●java.rmi.registry Package
●java.rmi.dgc Package
●java.rmi.activation Package

23. Java RMI Enhancements
RMI was included in Java 1.1
Java 2 SDK, Standard Edition, v1.2 removed the need for a skeleton. Codename Playground.
RMI was modified to support optional compatibility with CORBA in J2SE 1.3. Codename is Kestrel.
Server-side Stack Traces Now Retained in Remote Exceptions in J2SE 1.4
Service Provider Interface for RMIClassLoader (since Java SE 1.4)
Dynamic Server Host Name (since Java SE 1.4)
HTTP Fallback Is More Configurable (since Java SE 1.4.1)
java.rmi.Naming.list Method No Longer Prepends a Scheme to Names Returned (since Java SE 1.4.1)

24. Java 1.5
●rmic no longer compiles arbitrary source files in the class path (since Java SE 5.0)
In previous releases, rmic would sometimes, while processing its input class files, attempt to compile arbitrary .java source files that it
encountered in the class path. In Java SE 5.0, rmic does not attempt to compile any source files other than those for the stub, skeleton, or tie classes that it
generates.
●rmic default stub protocol version option now -v1.2 (since Java SE 5.0)
This change means that by default, rmic does not generate any skeleton classes and generates stub classes that only implement the 1.2 stub
protocol version.
●Launching rmid or a Java RMI Server from inetd/xinetd (since Java SE 5.0)
●Standard SSL/TLS Socket Factory Classes (since Java SE 5.0)
●Dynamic Generation of Stub Classes (since Java SE 5.0)
This release adds support for the dynamic generation of stub classes at runtime, obviating the need to use the Java Remote Method Invocation
(Java RMI) stub compiler, rmic, to pregenerate stub classes for remote objects.

25. Java 1.6
●java.rmi.MarshalledObject now generic
The class MarshalledObject now has a type parameter representing the type of the contained serialized object.
●Bug fix: Explicit TCP ports freed after remote objects unexported (4457683)
In previous releases, after a remote object had been exported on an explicit (non-anonymous) TCP port, the RMI implementation would keep a server socket bound to that port open for the lifetime of the
virtual machine, regardless of the life cycle of remote objects exported on that port. This bug has been fixed so that after all remote objects that had been exported on a given non-anonymous port have become unexported (either
explicitly or through distributed garbage collection) then the associated server socket will be closed. (There is an equivalent bug for anonymous TCP ports: 6279965.)
●Bug fix: Garbage collection of client socket factories (4486732)
In previous releases, after a remote invocation was made on a remote stub containing a non-null RMIClientSocketFactory in a given virtual machine, then either that factory object or an equivalent factory
object would remain forever reachable in the virtual machine, preventing it (and its defining class loader) from ever being garbage collected; this bug has been fixed. (There is an equivalent bug for socket factories used to export a
remote object: 6332603.)
●Default GC interval lengthed to one hour (6200091)
In previous releases, the maximum interval between garbage collections of the local heap enforced by the RMI implementation (while there are live remote references or exported remote objects), which is
controlled by the system properties sun.rmi.dgc.client.gcInterval and sun.rmi.dgc.server.gcInterval, was one minute by default. The default interval is now one hour, to better accommodate applications with large heap sizes without
special configuration.

26. Java 1.7
From JDK 7 Update 21, the RMI property java.rmi.server.useCodebaseOnly is set to true by default. In
earlier releases, the default value was false.
When set to false, this property allows one side of an RMI connection to specify a network location (URL) from
which the other side of the RMI connection should load Java classes. The typical use of this mechanism is for RMI
clients and servers to be able to provide remote interfaces and data classes to each other, without the need for
configuration.
The behavior of loading classes from locations specified by the remote end of the RMI connection, is disabled when
the java.rmi.server.useCodebaseOnly is set to true. In this case, classes are loaded only from preconfigured locations,
such as the locally-specified java.rmi.server.codebase property or the local CLASSPATH, and not from codebase
information passed through the RMI request stream.
Running a system with the java.rmi.server.useCodebaseOnly property set to false is not recommended, as it may
allow the loading and execution of untrusted code.

27. Java 1.8
Deprecated
Feature:
HTTP
proxying
from RMI
(8023862)
The HTTP proxying feature of RMI/JRMP is now
deprecated, and HTTP proxying is disabled by
default
Deprecated
Feature :
Support for
statically
generated
stubs
(8023863)
Support for statically-generated stubs from RMI
(JRMP) is now deprecated.

28. Java RMI Application
To write an RMI Java application, you would have to follow the steps
given below −
● Define the remote interface
● Develop the implementation class (remote object)
● Develop the server program
● Develop the client program
● Compile the application
● Execute the application

29. 1.Defining the Remote Interface
A remote interface provides the description of all the methods of a particular remote object.
The client communicates with this remote interface.
To create a remote interface −
● Create an interface that extends the predefined interface Remote which belongs to
the package.
● Declare all the business methods that can be invoked by the client in this interface.
● Since there is a chance of network issues during remote calls, an exception named
RemoteException may occur; throw it.

30. Following is an example of a remote interface. Here we have defined an
interface with the name Hello and it has a method called printMsg().
import java.rmi.Remote;
import java.rmi.RemoteException;
// Creating Remote interface for our application
public interface Hello extends Remote {
void printMsg() throws RemoteException;
}

31. Developing the Implementation class (Remote
Object)
We need to implement the remote interface created in the earlier step. (We can write an
implementation class separately or we can directly make the server program implement this
interface.)
To develop an implementation class −
● Implement the interface created in the previous step.
● Provide implementation to all the abstract methods of the remote interface.

32. Following is an implementation class. Here, we have created a class named ImplExample
and implemented the interface Hello created in the previous step and provided body for
this method which prints a message.
// Implementing the remote interface
public class ImplExample implements Hello {
// Implementing the interface method
public void printMsg() {
System.out.println("This is an example RMI program");
}
}

33. Developing the Server Program
An RMI server program should implement the remote interface or extend the implementation class. Here, we should create a
remote object and bind it to the RMIregistry.
To develop a server program −
● Create a client class from where you want invoke the remote object.
● Create a remote object by instantiating the implementation class as shown below.
● Export the remote object using the method exportObject() of the class named UnicastRemoteObject which
belongs to the package java.rmi.server.
● Get the RMI registry using the getRegistry() method of the LocateRegistry class which belongs to the package
java.rmi.registry.
● Bind the remote object created to the registry using the bind()method of the class named Registry. To this method,
pass a string representing the bind name and the object exported, as parameters.

34. Following is an example of an RMI server program.
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
public class Server extends ImplExample {
public Server() {}
public static void main(String args[]) {
try {
// Instantiating the implementation class
ImplExample obj = new ImplExample();
// Exporting the object of implementation class
// (here we are exporting the remote object to the stub)
Hello stub = (Hello) UnicastRemoteObject.exportObject(obj, 0);
// Binding the remote object (stub) in the registry
Registry registry = LocateRegistry.getRegistry();
registry.bind("Hello", stub);
System.err.println("Server ready");
} catch (Exception e) {
System.err.println("Server exception: " + e.toString());
e.printStackTrace();
}
}
}

35. Developing the Client Program
Write a client program in it, fetch the remote object and invoke the required method using this object.
To develop a client program −
● Create a client class from where your intended to invoke the remote object.
● Get the RMI registry using the getRegistry() method of the LocateRegistry class which belongs to
the package java.rmi.registry.
● Fetch the object from the registry using the method lookup() of the class Registry which belongs
to the package java.rmi.registry.
● To this method, you need to pass a string value representing the bind name as a parameter. This
will return you the remote object.
● The lookup() returns an object of type remote, down cast it to the type Hello.
● Finally invoke the required method using the obtained remote object.

36. Following is an example of an RMI client program.
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
public class Client {
private Client() {}
public static void main(String[] args) {
try {
// Getting the registry
Registry registry = LocateRegistry.getRegistry(null);
// Looking up the registry for the remote object
Hello stub = (Hello) registry.lookup("Hello");
// Calling the remote method using the obtained object
stub.printMsg();
// System.out.println("Remote method invoked");
} catch (Exception e) {
System.err.println("Client exception: " + e.toString());
e.printStackTrace();
}
}
}

37. FACTORIAL OF A NUMBER USING RMI IN JAVA
AIM: To write the Remote Invocation Method (RMI) program to find a factorial of a number .
PROCEDURE:
1. Start the process.
2. To perform the RMI operation create Interface file, Implementation file, Server file and
Client file .
3. Perform the JAVA compilation for all files.
4. Perform the RMI compilation for the implementation file to create stub and skeleton by
using rmic command.
5. Start the RMI registry.
6. Run the server and client file separately.
7. Display the result.
8. Terminate the process.

38. PROGRAM:
CLIENT PROGRAM:
import java.io.*;
import java.rmi.*;
public class client
{
public static void main(String args[])throws Exception
{
try
{
String s="rmi://"+args[0]+"/abc";
serverint f=(serverint)Naming.lookup(s);
DataInputStream m=new DataInputStream(System.in);
int n1=Integer.parseInt(m.readLine());
System.out.println("the factorial is"+f.fact(n1));
}
catch(Exception e)
{
System.out.println(e);
}
}
}

39. INTERFACE PROGRAM:
import java.rmi.*;
public interface serverint extends Remote
{
int fact(int n)throws Exception;
}
IMPLEMENTATION PROGRAM:
import java.rmi.*;
import java.rmi.server.*;
public class serverimpl extends UnicastRemoteObject implements serverint
{
public serverimpl()throws Exception
{
}
public int fact(int n)
{
int i,c=1;
for(i=1;i<=n;i++)
{
c=i*c;
}
return c;
}
}

40. SERVER PROGRAM:
import java.net.*;
import java.rmi.*;
public class server
{
public static void main(String args[])
{
try
{
serverimpl m=new serverimpl();
Naming.rebind("abc",m);
}
catch(Exception e)
{
System.out.println("Exception"+e);
}
}
}

41. OUTPUT:
SERVER WINDOW:
C:vino20>javac serverint.java
C:vino20>javac serverimpl.java
C:vino20>javac server.java
C:vino20>rmic serverimpl
C:vino20>start rmiregistry
C:vino20>java server
CLIENT WINDOW:
C:vino20>javac client.java
Note: client.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
C:vino20>java client localhost
3
the factorial is 6
C:vino20>

42. Useful Video Links for RMI:
Part 1:
https://www.youtube.com/watch?v=ILeAeFZOkMI
Part 2:
https://www.youtube.com/watch?v=OjXTkgW0wDQ
Part 3:
https://www.youtube.com/watch?v=vkw275ptI3E

43. Thank You