RMI Unit 5

Unit 5
Remote Method Invocation (RMI)

1. RMI Introduction
Remote Method Invocation (RMI) system allows an object running in one Java virtual
machine to invoke methods on an object running in another Java virtual machine. RMI
provides for remote communication between programs written in Java programming
language.
RMI applications often comprise two separate programs, a server and a client. A typical
server program creates some remote objects, makes references to these objects accessible,
and waits for clients to invoke methods on these objects. A typical client program obtains
a remote reference to one or more remote objects on a server and then invokes methods
on them. RMI provides the mechanism by which the server and the client communicate
and pass information back and forth. Such an application is sometimes referred to as a
distributed object application.
Remote Method Invocation (RMI) technology elevates network programming to a higher
plane. Although RMI is relatively easy to use, it is a remarkably powerful technology and
exposes the average Java developer to an entirely new paradigm – the world of
distributed object computing.
A primary goal for the RMI designers is to allow programmers to develop distributed
Java programs with the same syntax and semantics used for non-distributed programs. To
do this, they had to carefully map how Java classes and objects work in a single Java
Virtual Machine (JVM) to a new model of how classes and objects would work in a
distributed (multiple JVM) computing environment.

1.1. Role of Client and Server

In distributed programming, client computer makes a request and sends request data to
the server across the network. The server then processes the request and sends back
response to the client.
A distributed programming model installs a proxy object on the client. The proxy is an
object located in the client virtual machine that appears to the client program. The client
calls the proxy, making a regular method call. The client proxy contacts the server, using
a network protocol.

1.2. Remote Method Call

Remote method call is the key to distributed computing. In distributed computing, a
program on one machine (client) invokes a method on a remote object running on another
machine (server). Here, method parameters must be shipped to the server and the server
must locate the remote object and execute the method and the return value must be
shipped back. Here, the client/server terminology applies only to a single method call.
The computer that calls the remote method is the client for that call, and the computer
hosting the object that processes the call is the server for that call. It is also possible that

Nawaraj Paudel Page 1

RMI Unit 5

the roles of client and server are reversed for another call. The client of the previous call
can become server and the server of a previous call can become the client.

2. Java RMI Architecture Layers

The design goal for the RMI architecture was to create a Java distributed object model
that integrates naturally into the Java programming language and the local object model.
RMI architects have succeeded; creating a system that extends the safety and robustness
of the Java architecture to the distributed computing world.
The RMI implementation is essentially built from three abstraction layers. The first is the
Stub and Skeleton layer, which lies just beneath the view of the developer. This layer is
responsible for marshaling and unmarshaling the data and transmitting and receiving
them to and from the Remote Reference Layer.
The next layer is the Remote Reference Layer. This layer is responsible for carrying out
the invocations. This layer understands how to interpret and manage references made
from clients to the remote service objects.
The transport layer is based on TCP/IP connections between machines in a network. It
provides basic connectivity, as well as some firewall penetration strategies. This layer is
responsible for setting up connections, managing requests, monitoring them and listening
for incoming calls.

Fig: RMI Architecture Layers

By using a layered architecture each of the layers could be enhanced or replaced without
affecting the rest of the system.

2.1. Stub and Skeleton Layer

This layer is responsible for managing the remote object interface between the server and
client. In this layer, the stub class is the client-side Proxy for the remote object. Stub is
responsible for initiating a call to the remote object it represents and is the application
interface to that object. It is also responsible for marshalling the method arguments to a
marshal stream. This stream is a stream object, which simply transports the parameters,
exceptions and errors needed for the method dispatch and returns the results. Both the
stub and skeleton classes use this stream to communicate with each other. Once the
results are returned to the client stub, the results are un-marshalled.
The skeleton class is similar to the stub class in many ways. The only difference is that it
exists on the server side. The responsibility of the skeleton class is to send parameters to
the method implementation and sending the return values. They are generated using the
RMI stub compiler (RMIC). When the remote object from the naming server is

Nawaraj Paudel Page 2

RMI Unit 5

requested, the stub class is downloaded to the client machine. The stub and skeleton
classes implement the same interfaces as the remote object.

2.2. Remote Reference Layer

The Remote Reference Layers defines and supports the invocation semantics of the RMI
connection. This layer provides a RemoteRef object that represents the link to the
remote service implementation object.
The stub objects use the invoke() method in RemoteRef to forward the method call.
The RemoteRef object understands the invocation semantics for remote services.

2.3. Transport Layer

The Transport Layer makes the connection between JVMs. All connections are stream-
based network connections that use TCP/IP.
Even if two JVMs are running on the same physical computer, they connect through their
host computer's TCP/IP network protocol stack. The following diagram shows the use of
TCP/IP connections between JVMs.

As you know, TCP/IP provides a persistent, stream-based connection between two

machines based on an IP address and port number at each end. Usually a DNS name is
used instead of an IP address. In the current release of RMI, TCP/IP connections are used
as the foundation for all machine-to-machine connections.
On top of TCP/IP, RMI uses a wire level protocol called Java Remote Method Protocol
(JRMP). The RMI transport layer is designed to make a connection between clients and
server, even in the face of networking obstacles. While the transport layer prefers to use
multiple TCP/IP connections, some network configurations only allow a single TCP/IP
connection between a client and server (some browsers restrict applets to a single
network connection back to their hosting server). In this case, the transport layer
multiplexes multiple virtual connections within a single TCP/IP connection.

3. Stubs and Parameter Marshalling

When client code wants to invoke a remote method on a remote object, it actually calls an
ordinary method of the Java programming language that is encapsulated in a surrogate
object called a stub. The stub packages the parameters used in the remote method into a
block of bytes. This packaging uses a device-independent encoding for each parameter.
The process of encoding the parameters is called parameter marshalling. The purpose

Nawaraj Paudel Page 3

RMI Unit 5

of parameter marshalling is to convert the parameters into a format suitable for transport
from one virtual machine to another.
To sum up: the stub method on the client builds an information block that consists of:
• An identifier of the remote object to be used;
• A description of the method to be called;
• The marshaled parameters.
The stub then sends this information to the server. On the server side, a receiver object
performs the following actions for every remote method call:
• It unmarshals the parameters.
• It locates the object to be called.
• It calls the desired method.
• It captures and marshals the return value or exception of the call.
• It sends a package consisting of the marshalled return data back to the stub on the
client.
The client stub unmarshals the return value or exception from the server. This value
becomes the return value of the stub call. Or, if the remote method threw an exception,
the stub rethrows it in the process space of the caller.

4. Creating a Simple RMI Application

It is now time to build a working RMI system and get hands-on experience. A working
RMI system is composed of several parts. The steps for building a simple client/server
application by using RMI are given below:
• Create and compile interface for the remote services
• Create and compile server program
• Create and compile client program
• Install files on server and client machines
• Run the server program
• Run the client program

4.1. Create and Compile Interface for the remote services

The first step in building RMI system is to create interface for remote services. For
example,
import java.rmi.*;
public interface Adder extends Remote
{
public int add(int a, int b) throws RemoteException;
}
Notice this interface extends Remote, and the method signature declares that it may
throw a RemoteException object. Compile this interface using javac compiler as
shown below:
javac Adder.java

Nawaraj Paudel Page 4

RMI Unit 5

4.2. Create and Compile Server Program

Next, you create and compile the server program. The server program class uses
UnicastRemoteObject to link into the RMI system. When a class extends
UnicastRemoteObject, it must provide a constructor that declares that it may throw
a RemoteException object. When this constructor calls super(), it activates code
in UnicastRemoteObject that performs the RMI linking and remote object
initialization. This program also implements the interface created for the remote service.
For example,
import java.rmi.*;
import java.rmi.registry.*;
import java.rmi.server.*;
public class Server extends UnicastRemoteObject implements Adder
{
public Server()throws RemoteException
{
super();
}
public int add(int a, int b) throws RemoteException
{
return a + b;
}
public static void main(String[]args) throws RemoteException
{
try
{
Registry reg = LocateRegistry.createRegistry(19999);
reg.rebind("hi server", new Server());
System.out.println("Server is ready");
}
catch(RemoteException e)
{
System.out.println("exception " + e);
}
}
}
Compile this class using javac compiler as shown below:
javac Server.java

Note: We can also create a separate implementation class to implement the remote
interface and a separate server program rather than implementing the remote interface in
the server program as given in the program above.

Nawaraj Paudel Page 5

RMI Unit 5

4.3. Create and Compile Client Program

Now, we create and compile the client program to invoke remote object as given in the
program below.
import java.rmi.*;
import java.rmi.registry.*;
public class Client
{
public static void main(String[]args)throws RemoteException
{
Client c = new Client();
c.connectRemote();
}
private void connectRemote() throws RemoteException
{
try
{
Registry reg = LocateRegistry.getRegistry("localhost",19999);
Adder ad = (Adder)reg.lookup("hi server");
System.out.println("Addition is " + ad.add(16,9));
}
catch(NotBoundException|RemoteException e)
{
System.out.println("exception" + e);
}
}
}
Compile this interface using javac compiler as shown below:
javac Adder.java

4.4. Install files on server and client machines

Now, we create and compile the client program to invoke remote object as given in the
Copy Add.class and Client.class to a directory on the client machine. Copy Add.class and
Server.class to a directory on the server machine.

4.5. Run the server program

The server code is started from the command line, as shown here:
java Server

4.6. Run the client program

The client code is started from the command line, as shown here:
java Client

Nawaraj Paudel Page 6

RMI Unit 5

The output from this program is given below:

Addition is 25

5. RMI Registry
Essentially the RMI registry is a place for the server to register services it offers and a
place for clients to query for those services.
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).

Fig: Entire RMI process

6. Parameters in RMI
You have seen that RMI supports method calls to remote objects. When these calls
involve passing parameters or accepting a return value, how does RMI transfer these
between JVMs? What semantics are used? Does RMI support pass-by-value or pass-by-
reference? The answer depends on whether the parameters are primitive data types,
objects, or remote objects.

Nawaraj Paudel Page 7

RMI Unit 5

6.1. Parameters in a Single JVM

First, review how parameters are passed in a single JVM. When a primitive data type
(boolean, byte, short, int, long, char, float, or double) is passed as a
parameter to a method, the mechanics used is pass-by-value. The mechanics of passing
an object as a parameter is pass by reference. Now you will see how RMI passes
parameters and return values between remote JVMs.

6.2. Parameters in RMI

When a primitive data type is passed as a parameter to a remote method, the RMI system
passes it by value. RMI will make a copy of a primitive data type and send it to the
remote method. If a method returns a primitive data type, it is also returned to the calling
JVM by value. Values are passed between JVMs in a standard, machine-independent
format. This allows JVMs running on different platforms to communicate with each other
reliably.
When an object is passed to a remote method, the semantics change from the case of
the single JVM. RMI sends the object itself, not its reference, between JVMs. It is the
object that is passed by value, not the reference to the object. Similarly, when a remote
method returns an object, a copy of the whole object is returned to the calling program.
RMI introduces a third type of parameter to consider: remote objects. As you have
seen, a client program can obtain a reference to a remote object through the RMI
Registry program. There is another way in which a client can obtain a remote reference, it
can be returned to the client from a method call.

7. Remote Object Activation

In the preceding programs, we used a server program to instantiate and register objects so
that clients could make remote calls on them. However, in some cases, it might be
wasteful to instantiate lots of remote objects and have them wait for connections, whether
or not client objects use them. The activation mechanism lets you delay the object
construction so that a remote object is only constructed when at least one client invokes a
remote method on it. To take advantage of activation, the client code is completely
unchanged. The client simply requests a remote reference and makes calls through it.
However, the server program is replaced by an activation program that constructs
activation descriptors of the objects that are to be constructed at a later time, and binds
receivers for remote method calls with the naming service. When a call is made for the
first time, the information in the activation descriptor is used to construct the object. A
remote object that is used in this way should extend the Activatable class instead of the
UnicastRemoteObject class. For example,
public class Server extends Activable implements Adder
{
}

Nawaraj Paudel Page 8

RMI Unit 5

8. An Introduction to CORBA
Common Object Request Broker Architecture (CORBA) is used for communication
between distributed and heterogeneous objects that are written in multiple computer
languages. CORBA is developed by Object Management Group (OMG). OMG adopted
the CORBA standard in 1990. This was followed by many revisions of CORBA
architecture.

8.1. Comparison of RMI and CORBA

RMI and CORBA are both defined for the communication of remote objects in the
middle tier of distributed applications. RMI enables a java object to remotely
communicate with other java objects, CORBA, on the other hand, provides solution that
is portable across multiple platforms. CORBA provides an environment for the
communication of objects regardless of the programming languages they are written or
the operating system that they are running on. We can use CORBA to enable interaction
between legacy systems and new technology applications.
RMI applications are slower than CORBA applications. This is because RMI is based
on Java, which is interpreted language. The execution of interpreted language has
interpretation overheads that are not present in compiled languages. These interpretation
overheads include the excess time taken to interpret each line of code as compared to
compilation, in which entire code is compiled in one instance. Therefore, CORBA
applications are suitable for real-time systems since their execution time is less than that
of RMI applications.
RMI uses Java interfaces whereas CORBA uses Interface Definition Language (IDL).
RMI passes parameters by value whereas CORBA passes parameters by reference.

8.2. Steps to Implement CORBA Objects

Here are the steps for implementing CORBA objects:
1. Write the interface that specifies how the object works using IDL, the interface
definition language, for defining CORBA interfaces. IDL is a special language to
specify interfaces in a language-neutral form.
2. Using the IDL compiler(s) for the target language(s), generate the needed stub
and helper classes.
3. Add the implementation code for the server objects, using the language of your
choice. (The skeleton created by the IDL compiler is only glue code. You still
need to provide the actual implementation code for the server methods.) Compile
the implementation code.
4. Write a server program that creates and registers the server objects. The most
convenient method for registration is to use the CORBA naming service, a service
that is similar to the rmiregistry.
5. Write a client program that locates the server objects and invokes services on
them.
6. Start the naming service and the server program on the server and the client
program on the client.
These steps are quite similar to the steps that you use to build distributed applications

Nawaraj Paudel Page 9

RMI Unit 5

with RMI. There are two important differences:

• You can use any language with a CORBA binding to implement clients and
servers.
• You use IDL to specify interfaces.

8.3. Architecture of CORBA

The CORBA architecture consists of following components:
➢ Object Request broker (ORB)
➢ Common Object Services
➢ Interface Definition Language (IDL)
➢ Internet Inter-ORB Protocol (IIOP)
➢ Basic Object Adapter (BOA)
Object Request Broker
The foundation of CORBA architecture is based on the Object Request Broker (ORB).
The ORB is prime mechanism that acts as a middleware between the client and the
server.
It provides a heterogeneous environment in which a client can remotely communicate
with the server irrespective of the hardware, the operating systems, and the software
development language used.
The ORB helps establish connection with remote server. When a client wants to use
the services of a server, it first needs reference to the object that is providing the service.
Here, the ORB plays its role; the ORB resolves the client request for the object reference
on behalf of the client and thereby enables the client and the server to establish the
connectivity.
Common Object Services
The Common object services help the ORB in enabling object to interact in a
heterogeneous environment. These services are responsible for tasks such as creating
objects, monitoring access control and relocated objects. One of the important object
services is the Naming service. This service enables a remote server object to register
itself with the ORB so that a client can use its services.
Interface Definition languages
CORBA uses the concept of an interface Definition language to implement the services.
IDL is a neutral programming language method of defining how a service is
implemented. The syntax of this language is independent of any programming language.
IDL is used to define an interface, which describes the methods that are available and the
parameters that are required when a call is made for a remote object.
Internet Inter-ORB protocol (IIOP)
The CORBA standard specifies General Inter-ORB protocol (GIOP) as a standard
protocol that defines how ORBs communicate with component. IIOP is a TCP/IP
implementation of GIOP. It is standard protocol for communication between ORBs on
TCP/IP based networks.
Vendors can define their own proprietary protocols for their implementation of
CORBA. However they must implement IIOP for their products to be CORBA
compliant. This ensures interoperability. When there is more than one protocol, The ORB

Nawaraj Paudel Page 10

RMI Unit 5

can negotiate as to which protocol to use.

Since the Internet uses TCP/IP and IIOP is defined for TCP/IP, a CORBA application
can communicate over the internet.
Basic Object Adapter (BOA)
The ORB also provides services other than those required for object communication.
These services are provided by object adapters and can range from user authentication to
object activation to object persistence. Object adapters are part of the ORB. The BOA
provides the basic functions required for accessing the services of an ORB.
One of the most important services provided by the BOA is the server activation
policy service. The server activation policy defines how a server component should be
started and executed. For example, a server might be initialized once and many clients
might access the same server object.

Exercises
1. Define RMI? Why is it important to user RMI?
2. Explain role of client and server in RMI.
3. what is remote method call? Explain.
4. Explain RMI architecture layers in detail.
5. what is the role of stub? what is parameter marshalling and unmarshalling?
6. Write an RMI application to find multiplication to two numbers.
7. What is the role of RMI registry? Explain.
8. How can parameters be passed in RMI? Explain.
9. What is remote object activation? Why is it important is RMI?
10. Define CORBA. Compare CORBA with RMI.
11. What are the steps we use to implement CORBA application? Explain.
12. Explain architecture of CORBA in detail.

References:
1. Core Java Volume I – Fundamentals, Cay S. Horstmann and Gary Cornell,
Pearson.
2. Core Java Volume II – Advanced Features, Horstmann and Gary Cornell,
Pearson.
3. Java Complete Reference, Herbert Schildt, Oracle Press.
4. http://www.tutorialspoint.com
5. http://www.javapoint.com

Nawaraj Paudel Page 11