Part II Java Remote Method Invocation ( RMI )

estrapadesherbetΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 6 μήνες)

88 εμφανίσεις

Part II


Java Remote Method Invocation ( RMI )

Purpose: to learn Java basics and learn how to use
Java Remote Method Invocation (
RMI )
.


Building RMI (Remote Method Invocation) Client/Server


































Client
Side







Server Side













Define remote interface

Implement the interface

Server class

javac

rmic

Server stub

Implement client

Server Skeleton

Start RMI registry

Start Client

javac

Start server

The RMI Development Process:


1.

Define a remote interface


2.

Implement the remote interface


3.

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.


4.

Define the server class which contains main( ) method or add the main() method
to the step 2 class.



5.

Compile the server class: javac xxxServer.java


6.

Run the stub compiler against the class that implements the remote interface:

rmic

xxxImpl


7.

Start the RMI registry on your server host: rmiregistry


8.

Start the server process (JDK1.2)

Java

Djava.security.policy=policy.file xxxServer


9.

Copy the stubs to the client side


10.

Write the client code


11.

Compile the client code: javac xxxClient


12.

S
tart the client (same as step 8)



The Steps to compile the RMI applications


On Server side:


1.

javac *.java


2.

rmic xxxImpl


3.

rmiregistry


4.

java xxxServer (or java xxxImpl)



On Client side:


1.

manually copy remote interface class file (eg, RmiP0.class) from Se
rver
side



2.

manually copy the stub class file (eg. RmiP0Impl_Stub.class) from Server
side


3.

javac xxxClient.java


4.

java xxxClient



Comments


1.

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
include the

D options to specify where are the codebase of Server and the
Security file on the Client side command line.


2.

For PRNG applications on separated boxes (Server 0, Server 1, and Server 2), you
may use

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.


3.

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
(//xxx.xxx.
xxx.xxx:5001/remote
-
service
-
name).


4.

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.


5.

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:


Instance:


a.

countX uses to indicate the current state of ServerX.


b.

valueX uses to store the current Random Number that is available for the serv
ice.


c.

randomListX is a Vector to store all the generated Random Numbers for
ServerX.


d.

registryX use to compose URL for the other two Servers.




Methods:


rmiP0()

returns a Random Number to the Client’s request. First, it retrieves the current state
Ran
dom Number (X
0
(t)) from the Vector, randomList0, to a local variable, named
tmpValue0. Second, it generates another Random Number (X
1
(t+1)) for the next state by
inquiring (calling remote method inquireP1(t) and inquireP2(t)) the current Random
Number (X
1
(
t), X
2
(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
on
the same state. Last, it returns the Random Number (stores on tmpValue0) to the Client
request.



inquireP0(t)

retrieves the Random Number on the state t from its Vector, randomList0, and return this
value to the caller (other Servers).



nextP0(t)


in
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.