Java RMI Tutorial: Distributed Object Technology

Java Remote Method Invocation
Mohammad Masudur Rahman
Department of Computer Science
University of Saskatchewan
Saskatoon, Canada
mor543@mail.usask.ca

Abstract—Java Remote Method Invocation (RMI) is a distributed object technology which allows an application to invoke
methods from remote java objects hiding socket level details. It
can be considered as an object version of Java RPC. It is mainly a
java-centric technology and it has three major parts - client part
which invokes the remote method, server part which allows client
to invoke methods and RMI registry which maintains the remote
object references for both client and server. This is an easy to
use, cross-platform distributed object technology which leverages
the whole power of Java technology. In this tutorial, we have
provided an overview of Java RMI technology and developed
a simple RMI application. We have also discussed about the
strengths and weaknesses of the technology which is followed
by a comparative study between RMI and another distributed
object technology called CORBA.
Index Terms—Java RMI; Distributed Object; RPC; IIOP;
CORBA

I. I NTRODUCTION
Remote method invocation (RMI) is a technology that
allows applications to call object methods located remotely,
sharing resources and processing load across systems in a
distributed environment. It facilitates object function calls
between Java Virtual Machines (JVMs). JVMs can be located
on separate computers - yet one JVM can invoke methods
belong to an object stored in another JVM[3]. Java has builtin support for RMI through Java RM I AP I. The original
implementation depends on Java Virtual Machine (JVM) class
representation mechanisms and it thus only supports making
calls from one JVM to another. The protocol underlying this
Java-only implementation is known as Java Remote Method
Protocol (JRMP). In order to support code running in a nonJVM context, there is also a version compliant with CORBA
technology [17].
Unlike other systems for remote execution which require
that only simple data types or defined structures be passed to
and from methods, RMI allows any Java object type to be used
- even if the client or server has never encountered it before[3].
It can be also considered as an object version of Remote
Procedure Call (RPC). RMI allows both client and server
to dynamically load new object types as required. Basically,
RMI uses object serialization1 to marshal2 and unmarshal
parameters and does not truncate types, supporting true objectoriented polymorphism.
1 A process to convert the object into a stream of bytes suitable for storage
or transmission over network
2 A similar process like serialization except it records object’s state, code
base and treat remote objects specially[11]

Java RMI is a distributed object technology and it has
two parts- client and server. However, client and server don’t
communicate directly, rather client proxy object communicates
with server stub object and emulates the remote method
invocation as a local object function call.
In this tutorial, we have provided an overview about Java
RMI technology and implemented a simple RMI application
for mathematical operations. We tried to discover the strengths
and weaknesses of RMI and also performed its comparative
study against another distributed object technology called
CORBA. However, rest of the tutorial is structured as follows.
• Section II focuses on the historical perspective of Java
RMI technology in brief.
• Section III defines few technical terminologies required
to understand the architecture or functionalities of our
target technology.
• Section IV discusses how different components of RMI
architecture operate with each other.
• Section V demonstrates the implementation and deployment of a simple Java RMI application for mathematical
operations.
• Section VI highlights some advanced topics related to
Java RMI
• Section VII illustrates the strength and weakness of the
technology
• Section VIII provides a comparative study between Java
RMI and CORBA technology.
• Section IX concludes the tutorial
II. H ISTORICAL BACKGROUND [7]
Distributed systems require that computations running in
different address spaces, potentially on different hosts, be
able to communicate. For a basic communication mechanism,
the Java programming language supports sockets, which are
flexible and sufficient for general communication. However,
sockets require the client and server to engage in applicationslevel protocols to encode and decode messages for exchange,
and the design of such protocols is cumbersome and can be
error-prone.
An alternative to sockets is Remote Procedure Call (RPC)
developed in late 1970’s, which abstracts the communication
interface to the level of a procedure call. Instead of working
directly with sockets, the programmer has the illusion of
calling a local procedure, when in fact the arguments of the
call are packaged up and shipped off to the remote target of the

call. RPC systems encode arguments and return values using
an external data representation, such as XDR.
RPC, however, does not translate well into distributed object
systems, where communication between program-level objects
residing in different address spaces is needed. There are
three widely available distributed object technologies so far
- RMI by Sun Microsystem, CORBA by Object Management
Group(OMG) and SOAP by Microsoft. In order to match the
semantics of java object invocation, distributed object systems
require remote method invocation or RMI. In such systems,
a local surrogate (stub) object manages the invocation on a
remote object.
III. T ERMINOLOGIES
In this section, we illustrate some required terminologies .
These would help us to comprehend the Java RMI technology
more easily.
A. RPC[19]
Remote Procedure Call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or
procedure to execute in another address space (commonly on
another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.
B. XDR[20]
External Data Representation(XDR) is the backbone of the
Sun Microsystems Remote Procedure Call package. It is a
standard data serialization format, for uses such as computer
network protocols. It allows data to be transferred between
different kinds of computer systems. Converting from the
local representation to XDR is called encoding. Converting
from XDR to the local representation is called decoding.
XDR is implemented as a software library of functions which
is portable between different operating systems and is also
independent of the transport layer.
C. CORBA[18]
The Common Object Request Broker Architecture
(CORBA) is a standard defined by the Object Management
Group (OMG) that enables software components written
in multiple computer languages and running on multiple
computers to work together (i.e., it supports multiple
platforms). CORBA enables separate pieces of software
written in different languages and running on different
computers to work with each other like a single application or
set of services. More specifically, CORBA is a mechanism in
software for normalizing the method-call semantics between
application objects residing either in the same address space
(application) or remote address space (same host, or remote
host on a network).
D. IIOP[10]
Internet Inter-ORB Protocol (IIOP) is CORBA’s communication protocol. It defines the way bits are sent over a wire
between CORBA clients and servers. Interfaces to client and
server are described in a platform-neutral interface definition

language (IDL). Mappings from IDL to specific programming
languages are implemented binding the language to CORBA/IIOP.
E. Java IDL[9]
Java IDL adds CORBA capability to the Java platform,
providing standards-based interoperability and connectivity.
Java IDL enables distributed Web-enabled Java applications
to transparently invoke operations on remote network services
using the industry standard OMG IDL (Object Management
Group Interface Definition Language) and IIOP (Internet InterORB Protocol)
F. RMI-IIOP[10]
Previously, Java programmers had to choose between RMI
and CORBA/IIOP (Java IDL) for distributed programming
solutions. Now, by adhering to a few restrictions, RMI server
objects can use the IIOP protocol, and communicate with
CORBA client objects written in any language. This solution
is known as RMI-IIOP. RMI-IIOP combines RMI ease of use
with CORBA cross-language interoperability.
G. SOAP[15]
Simple Object Access Protocol, is a protocol specification
for exchanging structured information in the implementation
of Web Services in computer networks. It relies on Extensible
Markup Language (XML) for its message format, and usually
relies on other Application Layer protocols, most notably
Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer
Protocol (SMTP), for message negotiation and transmission
IV. S YSTEM A RCHITECTURE
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.
In this section, we are going to explain the architecture details
of RMI technology.
A. RMI Layered Structures[2]
The RMI system consists of four layers:
• Application layer-client and server application
• The stub/skeleton layer - client-side stubs (proxies) and
server-side skeletons
• The remote reference layer - remote reference behavior
(i.e., invocation to a single object or to a replicated object)
• The transport layer - connection set up and management
and remote object tracking
The application layer sits on top of the RMI system. The
relationship between the layers is shown in the Fig 1.
A remote method invocation from a client to a remote server
object travels down through the layers of the RMI system

Fig. 1. RMI Layered Architecture[2]
Fig. 2. How RMI Works[8]

to the client-side transport, then up through the server-side
transport to the server.
A client invoking a method on a remote server object
actually makes use of a stub or proxy for the remote object
as a conduit to the remote object. A client-held reference to
a remote object is a reference to a local stub. This stub is an
implementation of the remote interfaces of the remote object
and forwards invocation requests to that server object via the
remote reference layer. Stubs are generated using the rmic
compiler.
The remote reference layer is responsible for carrying out
the semantics of the invocation. For example the remote
reference layer is responsible for determining whether the
server is a single object or is a replicated object requiring
communications with multiple locations. Each remote object
implementation chooses its own remote reference semanticswhether the server is a single object or is a replicated object
requiring communications with its replicas.
The remote reference layer abstracts the different ways of
referring to objects that are implemented in (a) servers that
are always running on some machine, and (b) servers that
are run only when some method invocation is made on them
(activation). At the layers above the remote reference layer,
these differences are not seen.
The transport is responsible for connection set-up, connection management, and keeping track of and dispatching to
remote objects (the targets of remote calls) residing in the
transport’s address space.
In order to dispatch to a remote object, the transport
forwards the remote call up to the remote reference layer.
The remote reference layer handles any server-side behavior
that needs to be done before handing off the request to the
server-side skeleton. The skeleton for a remote object makes
an up-call to the remote object implementation which carries
out the actual method call.
The return value of a call is sent back through the skeleton,
remote reference layer and transport on the server side, and
then up through the transport, remote reference layer and stub
on the client side.

registers itself with remote object registry. Server object may
be always running or needs to be activated on method call
from client object. Basically server object is associated with a
skeleton object called < server class name > skel which
is responsible to translate the method invocation from client
as local object method invocation.
Client object generally resides on a different JVM from
the server does. To invoke a method from server object,
client object looks up the remote object registry for the
required reference to the service. The object registry returns
the reference of the < server class name > stub which
will communicate with the server object. Client object can
invoke the available methods to get the service. Again, the
client’s call is abstracted by the stub object so that the socket
level details are hidden from the client developer.
V. A S IMPLE RMI I MPLEMENTATION [3]
In this section, we demonstrated the implementation of a
simple RMI application. At first, we performed necessary
coding to develop service interface, server class and client
class. Then we deployed them in localhost for simplicity.
However, we have provided necessary guidelines to deploy
the service in another host having JVM installed and running.
A. Writing RMI Service
To write a RMI service we’ll start off with an example
which isn’t too ambitious. We’ll create a service that can
calculate factorial or square of a number and can check
whether a given number is a prime or not. Our factorial
method returns an integer, square method returns a big integer
(java.math.BigInteger) and checkPrime method returns a
boolean value.
1) Writing an Interface: The first thing we need to do is to
agree upon an interface, An interface is a description of the
methods we will allow remote clients to invoke. Let’s consider
exactly what we’ll need.
• A method that accepts as a parameter an integer, finds
its factorial, and returns an integer

B. Working Principles[16, 8]
Fig 2 illustrates how different part of RMI works. Server
object implements the publicly available service interface and

public long factorial(int number) throws
RemoteException;

A method that accepts as a parameter an integer, finds
whether it is a prime number or not, and returns a boolean

•

public boolean checkPrime(int number) throws
RemoteException;

A method that accepts as a parameter an integer, finds
its square, and returns a BigInteger object

•

public BigInteger square(int number) throws
RemoteException;

Once we’ve decided on the methods that will compose our
service, we have to create a Java interface. An interface is
a class which contains abstract methods; these methods must
be implemented by another class. Here is our M athService
interface in Listing 1

Our implementation of the service also needs to have a main
method. The main method will be responsible for creating an
instance of our M athServiceP rovider, and registering (or
binding) the service with the RMI Registry. Our main method
will also assign a security manager to the JVM, to prevent
any nasty surprises from remotely loaded classes. In this case,
a security manager isn’t really needed, but in more complex
systems where untrusted clients will be using the service, it is
critical.
public static void main(String args[]) {
try {
// setting RMI security manager
if (System.getSecurityManager() == null) {
System.setSecurityManager(new
RMISecurityManager());
}
// creating server instance
MathServiceProvider provider = new
MathServiceProvider();
// binding the service with the registry
LocateRegistry.getRegistry().bind("
MathService", provider);
System.out.println("Service is bound to RMI
registry");
} catch (Exception exc) {
// showing exception
System.out.println("Cant bind the service:
" + exc.getMessage());
exc.printStackTrace();

//interface between RMI client and server
import java.math.BigInteger;
import java.rmi.*;
public interface MathService extends Remote {
// every method associated with RemoteException
// calculates factorial of a number
public long factorial(int number) throws
RemoteException;

}
// check if a number is prime or not
public boolean checkPrime(int number) throws
RemoteException;
//calculate the square of a number and returns
BigInteger
public BigInteger square(int number) throws
RemoteException;

}
Listing 3. MathServiceProvider main() method

Once the factorial, checkPrime and square methods are
added, our server application is complete. Here’s the full
source code for the M athServiceP rovider. in Listing 4.
B. Writing RMI Client

}
Listing 1. MathService Interface

Our interface extends java.rmi.Remote, which indicates
that this is a remote service. We provide method signatures
for our three methods (factorial, checkPrime and square), and
the interface is complete. The next step is to implement the
interface, and provide method definitions for the factorial,
checkPrime and square functions.
2) Implementing Interface: To implement M athService
interface, we have to declare a default constructor
M athServiceP rovider(), even when we don’t have any
initialization code for our service. This is because our default
constructor can throw a java.rmi.RemoteException, from
its parent constructor in U nicastRemoteObject. However,
the constructor is quite simple.
public MathServiceProvider() throws
RemoteException
{
super();
}
Listing 2. MathServiceProvider constructor

What good is a service, if you don’t write a client that uses
it? Writing clients is the easy part - all a client has to do is
call the registry to obtain a reference to the remote object, and
call its methods. All the underlying network communication
is hidden from view which makes RMI clients simple.
Our client must first assign a security manager, and then
obtain a reference to the service. Note that the client receives
an instance of the interface we defined earlier, and not the
actual implementation. Some behind-the-scenes work is going
on, but this is completely transparent to the client.
// Assign security manager
System.setSecurityManager(new
RMISecurityManager());
}
// Accessing RMI registry for MathService
String hostName = "localhost"; //this can
be any host
MathService service = (MathService) Naming.
lookup("//" + hostName
+ "/MathService");
Listing 5. MathServiceClient RMIRegistry access

//MathService Server or Provider
import
import
import
import
import

java.awt.font.NumericShaper;
java.math.BigInteger;
java.rmi.*;
java.rmi.registry.LocateRegistry;
java.rmi.server.UnicastRemoteObject;

public class MathServiceProvider extends UnicastRemoteObject implements
MathService {
// MathServiceProvider implements all the methods of MathService interface
// service constructor
public MathServiceProvider() throws RemoteException {
super();
}
// implementation of factorial
public long factorial(int number) {
// returning factorial
if (number == 1)
return 1;
return number * factorial(number - 1);
}
// implementation of checkPrime
public boolean checkPrime(int number) {
// returning whether prime or not
boolean isprime=true;
for(int i=2;i*i<number;i++)
{
if(number%i==0)
{
isprime=false;
break;
}
}
//returning response
return isprime;
}
//implementing of Square
public BigInteger square(int number)
{
//creating BigInteger object
BigInteger number1=new BigInteger(String.valueOf(number));
//returning the BigInteger object
return number1.multiply(number1);
}

public static void main(String args[]) {
try {
// setting RMI security manager
System.setSecurityManager(new RMISecurityManager());
}
// creating server instance
MathServiceProvider provider = new MathServiceProvider();
// System.setProperty("java.security.policy","file:./server.policy");
// binding the service with the registry
LocateRegistry.getRegistry().bind("MathService", provider);
// Naming.bind("MathService", provider);
System.out.println("Service is bound to RMI registry");
// showing exception
System.out.println("Cant bind the service: " + exc.getMessage());
}
}
}
Listing 4. MathServiceProvider class

To identify a service, we specify an RMI URL. The URL
contains the host name on which the service is located, and
the logical name of the service. This returns a M athService
instance, which can then be used just like a local object
reference. We can call the methods just as if we had created
an instance of the remote M athServiceP rovider ourselves.
// Call to factorial method
System.out.println("The factorial of " + number +
"=" + service.factorial(number));

set special permission for both server and client class.
If one wishes to grant additional permissions, then one
can specify them in a policy file and then request them
to be loaded using options such as the following:
$ java -Djava.security.manager -Djava.security.
policy=policy-file MyClass

// Call to checkPrime method
boolean isprime=service.checkPrime(number);

Both of the ”-D” options specify system properties. The
first system property has the same effect as executing
the following statement as the first statement in your
program:

//Call to square method
BigInteger squareObj=service.square(number);

System.setSecurityManager (new SecurityManager
());

Listing 6. MathServiceClient accessing remote methods

Writing RMI clients is the easiest part of building distributed
services. In fact, there’s more code for the user interface menu
in the client than there is for the RMI components! To keep
things simple, there’s no data validation, so be careful when
entering numbers. Here’s the full source code for the RMI
client in Listing 7.
C. Running the Client and Server
Our example was very simple. More complex systems, however, might contain interfaces that change, or whose implementation changes. To run this tutorial example, both the client and
server will have a copy of the class files, but more advanced
systems might share the code of the server on a webserver, for
downloading as required. If your systems do this, don’t forget
to set the system property java.rmi.server.codebase to the
webserver directory in which your classes are stored.
1) Start the rmiregistry: To start the registry, Windows
users should do the following (assuming that your java/
bin directory is in the current path):
$ start rmiregistry

To start the registry, Unix users should do the following:$ rmiregistry &

2) Compile the sever
$ javac MathService.java MathServiceProvider.
java

3) Create the server stub: This step is no longer needed
to do manually. From JDK 1.5+, it is automatically done
for the developers.

The second system property above causes the specified
policy-file (which is specified with a URL) to be added
to the other policy files when defining the entire security
policy. The policytool can be used to construct the policy
file, but one can also use any text editor. However, in
our case we have created a policy file called no.policy
and kept it in the CLASSP AT H. So, the content of
no.policy file is as follows.
grant {
permission java.security.AllPermission;
};

In the file, we have actually removed all security restrictions for the server class. However, this can be more
restrictive, but we did it here for simplicity.
As if this wasn’t already complicated enough, there is
yet another way to deal with the problem of downloading
Serializable classes. The command-line option
$ -Djava.rmi.server.codebase=code-base
specifies a location

from which Serializable classes may be downloaded.
Of course, your security manager must recognize this
system property, and not all of them will do so. Furthermore, as mentioned earlier, this is only necessary
if you actually need to download Serializable classes.
However, we didn’t focus about serializable classes in
this tutorial.
5) Start the server: To start the server, we have to specify
the policy file we have created for server class. As, our
server class sets up a security manager in the source,
there is no need set another security manager from
command line.

$ rmic MathServiceProvider

4) Establishing security policy[14]: One of the most common problems one encounters with RMI is a failure due
to security constraints. Note that this section assumes
that one is using Java 1.2 or later. The default security
manager uses a policy that is defined in a collection of
policy files. These files are managed by the policytool
program. By default, the security manager (i.e., in JDK
7) does not support RMI method call. So, we need to

$ java -Djava.security.policy=no.policy
MathServiceProvider

6) Start the client: The client also needs a policy file like
the server. We have used the same no.policy file for the
client also. Thus our command to start the client is as
follows.
$ java -Djava.security.policy=no.policy
MathServiceClient localhost

//MathService Client
import
import
import
import

java.math.BigInteger;
java.rmi.Naming;
java.rmi.RMISecurityManager;
java.util.Scanner;

//This client accesses MathService Remote Object
public class MathServiceClient {
public static void main(String[] args) {
try {
// Assign security manager
System.setSecurityManager(new RMISecurityManager());
}
// Accessing RMI registry for MathService
String hostName = "localhost";
MathService service = (MathService) Naming.lookup("//" + hostName
+ "/MathService");
// enter your input values
Scanner scanner = new Scanner(System.in);
System.out.println("Enter your number to get factorial");
// is the input entered?
if (scanner.hasNext()) {
// reading the number for factorial from keyboard
int number = scanner.nextInt();
System.out.println("The factorial of " + number + "="
+ service.factorial(number));
}
System.out.println("Enter your number to check prime");
// reading the number for checkPrime
boolean isprime=service.checkPrime(number);
if(isprime)System.out.println(number+" is a prime number");
else System.out.println(number+" is not a prime number");
}
System.out.println("Enter your number to get square");
// reading the number for square
BigInteger squareObj=service.square(number);
System.out.println("The square of "+number+" is ="+squareObj.intValue());
}

// showing exceptions
System.err.println(exc.getMessage());
}
}
}
Listing 7. MathService Client

Here, the first part of the command specifies the policy
file, second part is the client class itself and the last part
refers to the host it is trying to connect.
VI. A DVANCED T OPICS ON RMI
Here, we discuss few advanced topics related to RMI briefly
as the detailed discussion is beyond the scope of this tutorial.
A. Java Object Serialization
When client and server application try to communicate using serializable user-defined objects during RMI, they need to
exchange those objects over the network. Java serialization is
a technique to convert those object definitions into sequence of
bytes which are suitable for network transmission. Generally,
stub and skeleton are responsible for Java object serialization
during RMI.
B. Parameter Marshalling and Demarshalling
It is a special kind of Java Object serialization technique
for method parameters. Any object of type remote or serializable can be marshalled. It is almost like serialization, but
additionally, it records the code base of the definition so that
the original object can be obtained after demarshalling.
C. Object Activation
Java RMI facilitates remote object access on demand; that
means, the remote reference layer activates the remote object
only when the client requests for the service. This feature
can be implemented using Activable remote object and this is
reasonable solution to resource optimization. Generally, each
RMI call creates a client-server communication line and there
is no need to keep all connections alive if the clients are not
using it. So, client can store a persistence reference of the
remote object and can make a connection when required.
VII. S TRENGTH & W EAKNESS OF JAVA RMI
In this section, we discuss about the strengths and weaknesses of Java RMI as a distributed object technology.
A. Strength of Java RMI[1]
At the most basic level, RMI is Java’s remote procedure
call (RPC) mechanism. RMI has several advantages over traditional RPC systems because it is part of Java’s object oriented
approach. Traditional RPC systems are language-neutral, and
therefore are essentially least-common-denominator systemsthey cannot provide functionality that is not available on all
possible target platforms.
RMI is focused on Java, with connectivity to existing
systems using native methods. This means RMI can take a
natural, direct, and fully-powered approach to provide you
with a distributed computing technology that lets you add Java
functionality throughout your system in an incremental, yet
seamless way.

1) Object Oriented: RMI can pass full objects as arguments and return values, not just predefined data types. This
means that you can pass complex types, such as a standard
Java hashtable object, as a single argument. In existing RPC
systems you would have to have the client decompose such an
object into primitive data types, ship those data types, and then
recreate a hashtable on the server. RMI lets you ship objects
directly across the wire with no extra client code.
2) Mobile Behavior: RMI can move behavior (class implementations) from client to server and server to client. For
example, you can define an interface for examining employee
expense reports to see whether they conform to current company policy. When an expense report is created, an object that
implements that interface can be fetched by the client from the
server. When the policies change, the server will start returning
a different implementation of that interface that uses the new
policies. The constraints will therefore be checked on the client
side-providing faster feedback to the user and less load on the
server-without installing any new software on user’s system.
This gives you maximal flexibility, since changing policies
requires you to write only one new Java class and install it
once on the server host.
3) Design Patterns: Passing objects lets you use the full
power of object oriented technology in distributed computing,
such as two- and three-tier systems. When you can pass
behavior, you can use object oriented design patterns in
your solutions. All object oriented design patterns rely upon
different behaviors for their power; without passing complete
objects-both implementations and type-the benefits provided
by the design patterns movement are lost.
4) Safe and Secure:: RMI uses built-in Java security
mechanisms that allow your system to be safe when users
downloading implementations. RMI uses the security manager
defined to protect systems from hostile applets to protect
your systems and network from potentially hostile downloaded
code. In severe cases, a server can refuse to download any
implementations at all.
5) Easy to Write/Easy to Use: RMI makes it simple to
write remote Java servers and Java clients that access those
servers. A remote interface is an actual Java interface. A server
has roughly three lines of code to declare itself a server,
and otherwise is like any other Java object. This simplicity
makes it easy to write servers for full-scale distributed object
systems quickly, and to rapidly bring up prototypes and early
versions of software for testing and evaluation. And because
RMI programs are easy to write they are also easy to maintain.
6) Connects to Existing/Legacy Systems: RMI interacts
with existing systems through Java’s native method interface
JNI. Using RMI and JNI you can write your client in Java
and use your existing server implementation. When you use
RMI/JNI to connect to existing servers you can rewrite any
parts of you server in Java when you choose to, and get the full
benefits of Java in the new code. Similarly, RMI interacts with
existing relational databases using JDBC without modifying
existing non-Java source that uses the databases.

7) Write Once, Run Anywhere: RMI is part of Java’s ”Write
Once, Run Anywhere” approach. Any RMI based system
is 100% portable to any Java Virtual Machine, as is an
RMI/JDBC system. If you use RMI/JNI to interact with an
existing system, the code written using JNI will compile and
run with any Java virtual machine.
8) Distributed Garbage Collection: RMI uses its distributed garbage collection feature to collect remote server
objects that are no longer referenced by any clients in the
network. Analogous to garbage collection inside a Java Virtual
Machine, distributed garbage collection lets you define server
objects as needed, knowing that they will be removed when
they no longer need to be accessible by clients.
9) Parallel Computing: RMI is multi-threaded, allowing
your servers to exploit Java threads for better concurrent
processing of client requests.
10) The Java Distributed Computing Solution: RMI is part
of the core Java platform starting with JDK 1.1, so it exists
on every 1.1+ Java Virtual Machine. All RMI systems talk
the same public protocol, so all Java systems can talk to each
other directly, without any protocol translation overhead.
B. Weakness of Java RMI[4, 6]
Despite of so many advantages, Java RMI suffers from some
problems. In this section, we have discussed the shortcomings
of Java RMI technology.
1) Tied to Java system: It is strongly tied to Java platform
and has no support for legacy systems written in C++, Ada,
Fortran, Cobol, and others (including future languages).
2) Performance issues: RMI calls should be used for only
large-grain computation. Because, every remote invocation
from the client results into a new thread and a new TCP
connection.
3) Added Security restrictions & complexity: It has security
threats when downloading the remote objects for execution
which is controlled by security manager and security policy
file. However, due to added security concern, using RMI is
complex and less flexible. It also requires additional compilation with rmic for creating stub classes which might be an
overhead to the performance.
VIII. A C ASE S TUDY: RMI VS CORBA
In this section, we provide a comparative study between
RMI and CORBA as distributed object technologies. Please
visit [13] for details.
A. Language Dependence
As we mentioned before, RMI is a Java-centric distributed
object system. The only way currently to integrate code written
in other languages into a RMI system is to use the Java nativecode interface to link a remote object implementation in Java
to C or C++ code. But, the native-code interface in Java is
complicated, and can quickly lead to fragile or difficult-tomaintain code. CORBA, on the other hand, is designed to
be language-independent. Object interfaces are specified in
a language that is independent of the actual implementation

language. This interface description can then be compiled
into whatever implementation language suits the job and the
environment.
B. Mobile Behavior
An RMI system is immediately cross-platform; any subsystem of the distributed system can be relocated to any host that
has a Java virtual machine handy. In CORBA, objects can
never really leave their implementation hosts; they can only
roam the network in the virtual sense, sending stub references
to themselves and to clients.
C. Performance Issue
Performance may be an issue in case of RMI for heavy
computation. Heavy computational tasks like computational
fluid dynamics and finite-element modeling are best written
in languages that can be compiled down to native hardware
instructions, like C and C++. The Java virtual machine architecture is a disadvantage here, since an additional interpretation layer is added to the processing of instructions. The Java
just-in-time compilers (JIT) are capable of generating native
instructions from Java bytecodes, but there is still an additional
piece of overhead in running each piece of Java code.
D. Ease of Use
RMI can be easier to master, especially for experienced
Java programmers, than CORBA. CORBA is a rich, extensive
family of standards and interfaces, and delving into the details
of these interfaces is sometimes overkill for the task at hand.
E. Maturity of Technology
CORBA is a more mature standard than RMI, and has had
time to gain richer implementations. The CORBA standard
is a fairly comprehensive one in terms of distributed objects,
and there are CORBA implementations out there that provide
many more services and distribution options than RMI or Java.
The CORBA Services specifications, for example, include
comprehensive high-level interfaces for naming, security, and
transaction services.
F. Renowned Customers
Java RMI technology is widely used by IBM, Swiss Federal Supreme Court, CEAS Consulting and most importantly
different chat service companies [12]. On the other hand,
CORBA is an old and established technology and it has
customers like USA AG, Cisco Systems, American Airlines,
BHP Information Technology and others [5].
To summarize, comparing RMI and CORBA doesn’t reveal
an optimum solution - one is not ”better” than the other.
The properties of these two technologies lend themselves
to different situations. A comparison of RMI and CORBA
helps to highlight individual strengths and weaknesses, but the
applicability of one technology over the other depends largely
on the purposes for which it is to be used, the experience of
the developers who will design, implement and maintain the
distributed system, and whether non-Java systems are intended
to access the system now or in the future.

IX. C ONCLUSION
In this tutorial, we provided a simple overview about Java
RMI technology including a simple application demonstration
and a case study between RMI and CORBA. We also discovered its strengths and weaknesses of RMI. However, the
choice of RMI depends on the purpose, scope and nature of
the application we are going to develop.
R EFERENCES
[1] Advantages of java rmi. URL http://www.oracle.com/
technetwork/java/javase/tech/index-jsp-138781.html.
[2] Java rmi architecture.
URL http://www.cs.mun.ca/
∼michael/java/jdk1.1-beta2-docs/guide/rmi/rmi-arch.
doc.html.
[3] Introduction to java rmi.
URL http://www.
javacoffeebreak.com/articles/javarmi/javarmi.html.
[4] Java rmi: Remote method invocation.
URL
http://www1.cs.columbia.edu/dcc/nestor/presentations/
java-rmi/java-rmi-handouts.pdf.
[5] Corba success stories. URL http://www.corba.org/.
[6] Disadvantages of rmi.
URL http://www.coderanch.
com/t/180297/java-developer-SCJD/certiﬁcation/
RMI-Advantages-Disadvantages.
[7] Background of java rmi. URL http://docs.oracle.com/
javase/1.5.0/docs/guide/rmi/spec/rmi-intro2.html.
[8] How rmi works.
URL http://www.sce.carleton.ca/
netmanage/simulator/rmi/RMIExplanation.htm.
[9] Java idl.
URL http://www.webopedia.com/TERM/J/
Java IDL.html.
[10] Rmi iiop. URL http://en.wikipedia.org/wiki/RMI-IIOP.
[11] Marshalling object. URL http://en.wikipedia.org/wiki/
Marshalling %28computer science%29.
[12] Real world applications using java rmi, .
URL
http://www.cs.mun.ca/∼paul8/jdk1.2beta3/docs/guide/
rmi/examples.html.
[13] Rmi vs corba, . URL http://www.cs.ait.ac.th/∼on/O/
oreilly/java-ent/dist/ch03 07.htm.
[14] Security issues of java rmi. URL www.eg.bucknell.edu/
∼cs379/DistributedSystems/rmi tut.html.
[15] Simple object access protocol. URL http://en.wikipedia.
org/wiki/SOAP.
[16] Java remote method invocation. URL http://userpages.
umbc.edu/∼tarr/dp/lectures/RMI.pdf.
[17] Java remote method invocation, .
URL http://en.
wikipedia.org/wiki/Java remote method invocation.
[18] Common object request broker architecture, . URL http:
//en.wikipedia.org/wiki/CORBA.
[19] Remote procedure call, . URL http://en.wikipedia.org/
wiki/Remote procedure call.
[20] External data representation. URL http://docs.oracle.
com/cd/E19963-01/html/821-1671/xdrnts-1.html.

Java RMI Tutorial: Distributed Object Technology

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Java RMI Tutorial: Distributed Object Technology

Similar a Java RMI Tutorial: Distributed Object Technology (20)

Más de Masud Rahman

Más de Masud Rahman (20)

Último

Último (20)

Java RMI Tutorial: Distributed Object Technology