RMI

Table of Content

• Overview of RMI

• Developing Applications with RMI

– Declaring remote interfaces

– Implementing remote interfaces

– Stubs and skeletons

– Registering remote objects

– Writing RMI clients

 Remote Method Invocation

• RMI is not only the simplest way of creating distributed

applications, but also gives us a chance to introduce you to naming
services similar to the Java Naming and Directory Interface (JNDI).
• RMI technology is useful for many business applications written in
Java. Some of the typical applications are listed here:
• Getting stock-market price quotes
• Obtaining flight information
• Requesting and downloading music files
• Performing inventory maintenance
 Overview of RMI

• RMI is the action of invoking a method of a remote interface on a

remote object.

• It enables Java clients to invoke methods on Java objects living on

the remote computer’s Java Virtual Machine (JVM).

• Both JVMs can be running on the same or different computers, but

the most important thing is that the application has to be distributed,
which in the case of RMI means that it should use at least two
JVMs.
 Overview of RMI

• Any RMI application consists of the following components:

– Client

– Server

– Registry

• The RMI components usually run on separate networked computers.

 Overview of RMI

• The registry is the naming service.

• The server creates some Java objects, registers them with the
naming service, and waits for remote clients to invoke methods on
these objects.

• A client application gets a reference to a remote-server object from

the registry and then invokes methods on this remote object.

• The main concept of RMI is that even though the methods are being
called in the client’s JVM, they are executed on the server’s JVM.
Overview of RMI
 Overview of RMI

• The best part of RMI applications is that a developer does not have
to program the network communications—the programming is
done automatically by a special tool called an RMI compiler (rmic).

• This tool generates two additional classes, stub and skeleton, that
will take care of data exchange over the network by using data
marshalling—presentation of Java objects as a set of bytes—and
serialization.
 Overview of RMI

• Usually an RMI server works in the wait mode: It “listens” to

requests on a particular port.

• A Java RMI client does not work directly with the server’s
database(s) or other resources—it just sends a request for the
information or updates in a form of a Java class, XML, or the like.

• That’s why the underlying infrastructure of a system is hidden from

the client and no database drivers or other third-party software must
be installed on the client’s machines.
 Developing Applications with RMI
• Writing distributed RMI applications usually consists of the following
steps:

1. Declaring a remote interface for the client

2. Implementing a remote interface on the server

3. Writing a client program that uses this remote interface to connect to a

server and call its methods

4. Generating stubs (client proxies) and skeletons (server entities)

5. Starting the registry on the server and registering remote objects with it

6. Starting the server application on the remote machine

7. Starting the Java application that is either located on the client machine
or downloaded as a Java applet
 Developing Applications with RMI

• Declaring remote interfaces

– A remote interface defines method(s) that can be invoked

remotely by a client.

– Like any Java interfaces, the remote interfaces describe the

behaviour of remote objects and do not contain the
implementation of this behaviour.

– The client program will “have a feeling” that it calls local

methods, but actually these calls will be redirected to a remote
server.
 Developing Applications with RMI
• The following are the rules for creation of remote interfaces:

1. An application’s remote interface must declare business methods

having public access that will enable clients to communicate with
the server.

2. An application’s remote interface must extend the

java.rmi.Remote interface. The Remote interface does not have
any methods—just declare the required methods there.

3. Each method must declare a java.rmi.RemoteException or one of

its ancestors.

4. Method arguments and return data types must be serializable.

 Developing Applications with RMI

• Implementing remote interfaces

– In RMI, the interface and implementations are completely

separated.

– While the remote interface just declares the methods used by the
client, the actual class that provides the implementation for these
methods will run on the server side in a separate JVM.

– These methods must have exactly the same signatures as their

proxies on the client, otherwise the RMI clients won’t find them.
 Developing Applications with RMI

• Stubs and skeletons

– After the remote interface and its implementation are created,

you need to generate the objects responsible for the network
communications between them.

– The stub is a client-side object that represents the remote object.

 Developing Applications with RMI

• When a client calls a remote method, the stub method is invoked and
it does the following:

– Initiates a connection with the remote JVM

– Marshals (prepares and transmits) the parameters to the server

– Waits for the result of the method invocation

– Unmarshals (reads) the return value or exception returned

– Returns the value to the client

 Developing Applications with RMI

• An RMI server may have a similar object called a skeleton to

process the client’s network calls.

• It performs the following operations for each received call:

– Unmarshals (reads) the parameters for the remote method

– Invokes the method on the actual remote-object implementation

– Marshals the result to the caller

 Developing Applications with RMI

• The skeleton is responsible for dispatching the client call to the

actual object implementation.

• The skeletons are deprecated starting from Java 1.2 onwards.

• They are not replaced by any other classes and can be just ignored.

• But if at least one of the JVMs participating in the RMI application

uses Java version 1.1 or older, the skeleton class must exist on the
server side.

• J2SE comes with the RMI compiler called rmic, which generates
stubs and skeletons from the existing implementation class.
 Developing Applications with RMI

• You can start the rmic program like this:

c:>rmic FlightServerImpl

• This command will create two more classes—one for the client side
and the other for the server.

• If you want to know what’s under the hood, run the rmic with the

– keepgenerated flag to see the source code of the stub and skeleton
in the files.
 Developing Applications with RMI
• The stub implements only remote interfaces.

• When the client calls a remote method the stub marshals and
serializes the data over the network to the skeleton.

• The skeleton, in turn unmarshals and deserializes the data on the

remote machine and passes the data to the actual implementation of
the method.

• After the method completes, the return value is delivered back to the
client in the reverse order.

• Obviously, the remote method parameters and returned values of the

remote methods must be serializable.
 Developing Applications with RMI

• Registering remote objects

– Before a client program can invoke a particular method on the

remote object, it has to find this object on the network.

– A server makes remote objects visible to the clients by

registering these objects with a naming service.

– The rmiregistry is a simple naming service that comes with

J2SE.
 Developing Applications with RMI

• The process of registering an object with the RMI registry is called

binding.

• The RMI registry is nothing but a naming service that knows where
to find the server’s objects, and it will enable clients to look up an
object in the network by name.

• While the class name can be long and include the package name, the
registry name is usually short and descriptive.
 Developing Applications with RMI

• Two methods in the java.rmi.Naming class can bind an object to

the registry.

• The bind() method binds an object to a name.

• It throws the AlreadyBoundException if the binding already exists

under the specified name.

• The rebind() method replaces any preexisting registry entry with the
new one.

• The unbind() method removes an object from the registry.

 Developing Applications with RMI
• The registry must be up and running by the time you bind the
objects. To start the registry, open a command window and type the
following:

c:\>start rmiregistry

• This command will start the registry on the default RMI port 1099.

• If you need to specify another port, provide the port’s number as a

command-line parameter.

• For example, to start the registry on port 6000 use the following
command:

c:\>start rmiregistry 6000

 Developing Applications with RMI

• Instead of starting the registry manually, you could have also started
it from within the StartFlightServer program itself.

• Just add the following line at the beginning of the main( ) method

LocateRegistry.createRegistry(6000);

• To bring the flight server up, open a command window and start the
StartFlightServer class from your working directory.

• Here’s an example:

C:\>java StartFlightServer
 Developing Applications with RMI

• Writing RMI clients

– The client has to perform a lookup in the registry on the server’s

machine and obtain a remote reference to the object listed under
the specified name.

– The lookup() method of the java.rmi.Naming class locates the

remote object on the specified host and port.

FlightServer myServer = (FlightServer)

Naming.lookup(“rmi://localhost:6000/FlightService”);
 Developing Applications with RMI

• The RMI registry runs by default on port 1099, unless another port
number is specified.

• When the client wants to invoke methods on the remote object it

obtains a reference to that object by looking up the name.

• The lookup returns to the client a stub of the remote object.

 Developing Applications with RMI

• The method takes the object’s URL as an argument in this format:

rmi://<hostname>[:<name_service_port>]/<service_name>

• These components are described as follows:

• hostname is the name of the computer on the local area network (LAN) or
a DNS name on the Internet.

• name_service_port has to be specified only if the naming service is running

on a port other than the default one (1099).

• service_name is the name of the remote object that should have been bound
to the registry.
 Developing Applications with RMI

• If the RMI client is an applet, RMISecurityManager is not

needed—just make sure that the RMI implementation classes exist
on the same server that the applet is coming from.

• If the Web server and RMI server are running on different hosts, the
applets have to be digitally signed.

• FlightClient can be started as follows:

c:>java -Djava.security.policy=security.policy FlightClient CO1208

• Policy files contain permissions granted to users of this application.

 Developing Applications with RMI

• A sample security file is shown in Listing 4-5. Detailed explanations

of how to write security-policy files can be found at
http://java.sun.com/j2se/1.4/docs/guide/security/PolicyFiles.html