Java RMI Detailed Tutorial

A Java RMI detailed tutorial for starting users.

1. Java Remote Method Invocation
Mohammad Masudur Rahman
Department of Computer Science
University of Saskatchewan
Saskatoon, Canada
[email protected]
Abstract—Java Remote Method Invocation (RMI) is a dis-
tributed 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. INTRODUCTION
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 built-
in support for RMI throughJava RMI 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 non-
JVM 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 dened 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 serialization
1
to marshal
2
and unmarshal
parameters and does not truncate types, supporting true object-
oriented 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 denes 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 deploy-
ment 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. HISTORICALBACKGROUND[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
exible and sufcient for general communication. However,
sockets require the client and server to engage in applications-
level 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

2. 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. TERMINOLOGIES
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 communi-
cation 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 program-
mer 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 dened 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 specically, 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 communi-
cation protocol. It denes 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 denition
language (IDL). Mappings from IDL to specic programming
languages are implemented binding the language to CORBA/I-
IOP.
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 Denition Language) and IIOP (Internet Inter-
ORB 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 specication
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. SYSTEMARCHITECTURE
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

3. Fig. 1. RMI Layered Architecture[2]
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 thermic
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 semantics-
whether 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, connec-
tion 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.
B. Working Principles[16, 8]
Fig 2 illustrates how different part of RMI works. Server
object implements the publicly available service interface and
Fig. 2. How RMI Works[8]
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< serverclassname >skelwhich
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< serverclassname >stubwhich
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 SIMPLERMI IMPLEMENTATION [3]
In this section, we demonstrated the implementation of a
simple RMI application. At rst, we performed necessary
coding to develop service interface, server class and client
class. Then we deployed them inlocalhostfor 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 rst 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, nds
its factorial, and returns an integer
public factorial(intnumber)throws
RemoteException;

4. A method that accepts as a parameter an integer, nds
whether it is a prime number or not, and returns a boolean
public checkPrime(intnumber)throws
RemoteException;
A method that accepts as a parameter an integer, nds
its square, and returns aBigIntegerobject
publicBigInteger square(intnumber)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 ourMathService
interface in Listing 1
//interface
importjava.math.BigInteger;
importjava.rmi.*;
public MathServiceextendsRemote {
//
//
public factorial(intnumber)throws
RemoteException;
//
public checkPrime(intnumber)throws
RemoteException;
//calculate
BigInteger
publicBigInteger square(intnumber)throws
RemoteException;
}
Listing 1. MathService Interface
Our interface extendsjava: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 denitions for the factorial,
checkPrime and square functions.
2) Implementing Interface:To implementMathService
interface, we have to declare a default constructor
MathServiceP rovider(), even when we don't have any
initialization code for our service. This is because our default
constructor can throw ajava:rmi:RemoteException, from
its parent constructor inUnicastRemoteObject. However,
the constructor is quite simple.
publicMathServiceProvider() throws
RemoteException
{
super();
}
Listing 2. MathServiceProvider constructor
Our implementation of the service also needs to have a main
method. The main method will be responsible for creating an
instance of ourMathServiceP 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 main(String args[]) {
try{
//
if(System.getSecurityManager() == null) {
System.setSecurityManager( new
RMISecurityManager());
}
//
MathServiceProvider provider = new
MathServiceProvider();
//
LocateRegistry.getRegistry().bind("
MathService", provider);
System.out.println("Service is bound to RMI
registry");
}catch(Exception exc) {
//
System.out.println("Cant bind the service:
" + exc.getMessage());
exc.printStackTrace();
}
}
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 theMathServiceP rovider. in Listing 4.
B. Writing RMI Client
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 rst assign a security manager, and then
obtain a reference to the service. Note that the client receives
an instance of the interface we dened earlier, and not the
actual implementation. Some behind-the-scenes work is going
on, but this is completely transparent to the client.
//
if(System.getSecurityManager() == null) {
System.setSecurityManager( new
RMISecurityManager());
}
//
String hostName = "localhost";this
be
MathService service = (MathService) Naming.
lookup("//" + hostName
+ "/MathService");
Listing 5. MathServiceClient RMIRegistry access

5. //MathService
importjava.awt.font.NumericShaper;
importjava.math.BigInteger;
importjava.rmi.*;
importjava.rmi.registry.LocateRegistry;
importjava.rmi.server.UnicastRemoteObject;
public MathServiceProvider extendsUnicastRemoteObject implements
MathService {
//
//
publicMathServiceProvider() throwsRemoteException {
super();
}
//
public factorial(intnumber) {
//
if(number == 1)
return1;
returnnumber*factorial(number - 1);
}
//
public checkPrime(intnumber) {
//
booleanisprime=true;
for(inti=2;i*i<number;i++)
{
if(number%i==0)
{
isprime=false;
break;
}
}
//returning
returnisprime;
}
//implementing
publicBigInteger square(intnumber)
{
//creating
BigInteger number1=newBigInteger(String.valueOf(number));
//returning
returnnumber1.multiply(number1);
}
public main(String args[]) {
try{
//
if(System.getSecurityManager() == null) {
System.setSecurityManager( newRMISecurityManager());
}
//
MathServiceProvider provider = newMathServiceProvider();
//.setProperty("java.security.policy","file:./server.policy");
//
LocateRegistry.getRegistry().bind("MathService", provider);
//.bind("MathService",);
System.out.println("Service is bound to RMI registry");
}catch(Exception exc) {
//
System.out.println("Cant bind the service: " + exc.getMessage());
exc.printStackTrace();
}
}
}
Listing 4. MathServiceProvider class

6. 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 aMathService
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 remoteMathServiceP roviderourselves.
//
System.out.println("The factorial of " + number +
"=" + service.factorial(number));
//
booleanisprime=service.checkPrime(number);
//Call
BigInteger squareObj=service.square(number);
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, how-
ever, might contain interfaces that change, or whose implemen-
tation changes. To run this tutorial example, both the client and
server will have a copy of the class les, 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 propertyjava:rmi:server:codebaseto 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.
$ rmic MathServiceProvider
4)Establishing security policy[14]: One of the most com-
mon 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 dened in a collection of
policy les. These les are managed by thepolicytool
program. By default, the security manager (i.e., in JDK
7) does not support RMI method call. So, we need to
set special permission for both server and client class.
If one wishes to grant additional permissions, then one
can specify them in a policy le and then request them
to be loaded using options such as the following:
$ java -Djava.security.manager -Djava.security.
policy=policy-file MyClass
Both of the ”-D” options specify system properties. The
rst system property has the same effect as executing
the following statement as the rst statement in your
program:
System.setSecurityManager ( newSecurityManager
());
The second system property above causes the specied
policy-le (which is specied with a URL) to be added
to the other policy les when dening the entire security
policy. The policytool can be used to construct the policy
le, but one can also use any text editor. However, in
our case we have created a policy le calledno:policy
and kept it in theCLASSP AT H. So, the content of
no:policyle is as follows.
grant {
permission java.security.AllPermission;
};
In the le, we have actually removed all security restric-
tions 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. Fur-
thermore, 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 le 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.
$ java -Djava.security.policy=no.policy
MathServiceProvider
6)Start the client: The client also needs a policy le like
the server. We have used the sameno:policyle for the
client also. Thus our command to start the client is as
follows.
$ java -Djava.security.policy=no.policy
MathServiceClient localhost

7. //MathService
importjava.math.BigInteger;
importjava.rmi.Naming;
importjava.rmi.RMISecurityManager;
importjava.util.Scanner;
//This
public MathServiceClient {
public main(String[] args) {
try{
//
if(System.getSecurityManager() == null) {
System.setSecurityManager( newRMISecurityManager());
}
//
String hostName = "localhost";
MathService service = (MathService) Naming.lookup("//" + hostName
+ "/MathService");
//
Scanner scanner = newScanner(System.in);
System.out.println("Enter your number to get factorial");
//?
if(scanner.hasNext()) {
//
intnumber = scanner.nextInt();
System.out.println("The factorial of " + number + "="
+ service.factorial(number));
}
System.out.println("Enter your number to check prime");
if(scanner.hasNext()) {
//
intnumber = scanner.nextInt();
booleanisprime=service.checkPrime(number);
if(isprime)System.out.println(number+" is a prime number");
elseSystem.out.println(number+" is not a prime number");
}
System.out.println("Enter your number to get square");
if(scanner.hasNext()) {
//
intnumber = scanner.nextInt();
BigInteger squareObj=service.square(number);
System.out.println("The square of "+number+" is ="+squareObj.intValue());
}
}catch(Exception exc) {
//
System.err.println(exc.getMessage());
exc.printStackTrace();
}
}
}
Listing 7. MathService Client

8. Here, the rst part of the command species the policy
le, second part is the client class itself and the last part
refers to the host it is trying to connect.
VI. ADVANCEDTOPICS ONRMI
Here, we discuss few advanced topics related to RMI briey
as the detailed discussion is beyond the scope of this tutorial.
A. Java Object Serialization
When client and server application try to communicate us-
ing serializable user-dened objects during RMI, they need to
exchange those objects over the network. Java serialization is
a technique to convert those object denitions 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 serial-
izable can be marshalled. It is almost like serialization, but
additionally, it records the code base of the denition 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 usingActivableremote 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. STRENGTH& WEAKNESS OFJAVARMI
In this section, we discuss about the strengths and weak-
nesses 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 tradi-
tional 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 systems-
they 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 argu-
ments and return values, not just predened 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 im-
plementations) from client to server and server to client. For
example, you can dene an interface for examining employee
expense reports to see whether they conform to current com-
pany 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 exibility, 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 benets 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
dened 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
benets 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.

9. 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 dis-
tributed 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 dene 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
le. However, due to added security concern, using RMI is
complex and less exible. It also requires additional compi-
lation withrmicfor creating stub classes which might be an
overhead to the performance.
VIII. A CASESTUDY: RMIVSCORBA
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 native-
code 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 difcult-to-
maintain code. CORBA, on the other hand, is designed to
be language-independent. Object interfaces are specied 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 subsys-
tem 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
uid dynamics and nite-element modeling are best written
in languages that can be compiled down to native hardware
instructions, like C and C++. The Java virtual machine archi-
tecture is a disadvantage here, since an additional interpreta-
tion 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 specications, 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 Fed-
eral 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.

10. IX. CONCLUSION
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 dis-
covered 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.
REFERENCES
[1]
technetwork/java/javase/tech/index-jsp-138781.html.
[2]
michael/java/jdk1.1-beta2-docs/guide/rmi/rmi-arch.
doc.html.
[3]
javacoffeebreak.com/articles/javarmi/javarmi.html.
[4]
http://www1.cs.columbia.edu/dcc/nestor/presentations/
java-rmi/java-rmi-handouts.pdf.
[5]
[6]
com/t/180297/java-developer-SCJD/certication/
RMI-Advantages-Disadvantages.
[7]
javase/1.5.0/docs/guide/rmi/spec/rmi-intro2.html.
[8]
netmanage/simulator/rmi/RMIExplanation.htm.
[9]
JavaIDL.html.
[10]
[11]
Marshalling%28computerscience%29.
[12]
http://www.cs.mun.ca/
paul8/jdk1.2beta3/docs/guide/
rmi/examples.html.
[13]
on/O/
oreilly/java-ent/dist/ch0307.htm.
[14]
cs379/DistributedSystems/rmitut.html.
[15]
org/wiki/SOAP.
[16]
umbc.edu/
tarr/dp/lectures/RMI.pdf.
[17]
wikipedia.org/wiki/Javaremotemethodinvocation.
[18]
//en.wikipedia.org/wiki/CORBA.
[19]
wiki/Remoteprocedurecall.
[20]
com/cd/E19963-01/html/821-1671/xdrnts-1.html.