Java Remote Method Invocation ( RMI )
Purpose: to learn Java basics and learn how to use
Java Remote Method Invocation (
Building RMI (Remote Method Invocation) Client/Server
Define remote interface
Implement the interface
Start RMI registry
The RMI Development Process:
Define a remote interface
Implement the remote interface
Set up the environment and CLASSPATH. The interface stub and skeleton files
must be accessible to the NamesServer, the Server JVM,
and the client JVM.
Define the server class which contains main( ) method or add the main() method
to the step 2 class.
Compile the server class: javac xxxServer.java
Run the stub compiler against the class that implements the remote interface:
Start the RMI registry on your server host: rmiregistry
Start the server process (JDK1.2)
Copy the stubs to the client side
Write the client code
Compile the client code: javac xxxClient
tart the client (same as step 8)
The Steps to compile the RMI applications
On Server side:
java xxxServer (or java xxxImpl)
On Client side:
manually copy remote interface class file (eg, RmiP0.class) from Se
manually copy the stub class file (eg. RmiP0Impl_Stub.class) from Server
To run RMI application, you can choose to download the Stub class file at the run
time from the Server instead of m
anually to copy it. By doing so, you need to
D options to specify where are the codebase of Server and the
Security file on the Client side command line.
For PRNG applications on separated boxes (Server 0, Server 1, and Server 2), you
the same Remote Interface Name for each Name Server (rmiregistry).
However, to run the PRNG at the same box for the purpose of demonstration, you
have to define each Remote Interface with identical name.
The Name Server runs on each machine that hosts
remote service objects and
accepts queries for services, by default on port 1099. However, you can specify a
different port than 1099 due to security purpose. For example, rmiregistry 5001.
The Client need to include this custom port on the URL
For Lab 3 Part III, originally the Name lookups are implemented at the main()
methods of each Server. However, the lookup information is lost when the Server
need to retrieve the information from one another. The solutio
n to this problem is
to implement the Name lookup on the methods (eg. RmiP0( ), and nextP0( )) of
each remote service.
To prevent the data corruption for the Lab 3 Part III, you can implement it with
Multithreading technology with carefully adding synchr
onized keyword to protect
the method or the object. Or you can use single thread to prevent from data
corruption because there is only one copy of application for each Server at any
moment. I use the latter one to implement Lab 3 Part III.
In order to
keep the three ServerX (X indicating 0, 1, or 2) on the same state, we use the
following instances and methods:
countX uses to indicate the current state of ServerX.
valueX uses to store the current Random Number that is available for the serv
randomListX is a Vector to store all the generated Random Numbers for
registryX use to compose URL for the other two Servers.
returns a Random Number to the Client’s request. First, it retrieves the current state
dom Number (X
(t)) from the Vector, randomList0, to a local variable, named
tmpValue0. Second, it generates another Random Number (X
(t+1)) for the next state by
inquiring (calling remote method inquireP1(t) and inquireP2(t)) the current Random
(t)) from the other two Servers. Once it is done, it will notice the other
two Servers to promote to the next state by calling nextP1(t), nextP2(t) methods along
with the current state t parameter. By doing so, we guarantee that all the Servers are
the same state. Last, it returns the Random Number (stores on tmpValue0) to the Client
retrieves the Random Number on the state t from its Vector, randomList0, and return this
value to the caller (other Servers).
vokes by other Servers to promote itself to the next state t+1. It generate the next State
Random Number by inquiring the State t Random Numbers form the other tow Servers.