Home	»	Java	»	Advance Java	»	Remote Method Invocation (RMI)

The Distributed applications are worked by using the Concept of Client and Server. In a Network A Client Request for a Service from a Server and a Server is that Which Responds the Request of a Client. When a Client Request to the Server then also all the Required Parameters are also Passed to the Server and then the Server Reads the Parameters those are send by the Client. When a Client Makes a Request then Some times there is a Situation the Requested Method May Made in a Different Language and a Client is using a Different Language for Accessing that Method. Suppose a Server Contains Many Methods those are Made in JAVA and a Client is Requesting a Method to Call through the C++ Program Then in this Situation this will Create Many Problems , But For Avoiding these Problems JAVA Provides us CORBA Which Stands For Common Object Request Broker Architecture Which is used When the Request and Response are Performed in different Language but this will increase the Complexity and also decrease the Performance of Execution. So this Will gives better Performance if both the Programs are Made in the JAVA or in any One Language.

JAVA Provides us a great Feature to Call the Methods those are Made in JAVA and those are Stored on the Remote or other Computer in the Network. And With the Help of JAVA Program We can Call them. So the Main Aim of RMI or Remote Method Invocation is to Call the Method which is Stored on any Remote Computer.

There are number of methods for developing the network application such as COM/CDCOM CORBA and RMI with their own advantages and disadvantages. These all application just works on the concept of distributed object system technology.

Distributed Object System

Distributed Object System - It combines both network and OOP. Distributed means connecting the two PC or mainframe and any other devices together either in them there is one local node and the other is the remote node. For example a Web is largest distributed computing system in the World which is used for exchanging the data. Distributed object system is used in the large organizations. It makes easy to access, use and remote object located anywhere on a network. It includes following functions: -

Locating and Loading Remote Classes

Locating and loading of remote classes are needed by ordinary java applets. They contain references of classes those are download by the browser from several hosts. Those classes can provide the functionality to system developers for improving their system performance by virtually using the resources of these classes. For Calling Methods in the Network we have to Pass Some Arguments. The Passed Arguments must be Transferred to Server Arguments and the Parameters those are Passed are Stored in the Proxy Object which is called as stub . Stubs are always Created in Client Machine . So the Process of Storing the Parameters in Stub Object is also Called as Parameter Marshalling. The Main Purpose Marshalling to Convert the Arguments in a Forma So that they can be Transferred to any Java Virtual Machine. And Stub always Contains Parameters those are Marshaled. When a Client Pass those Agreements by Creating Stubs then the Parameters are Stored on the Skelton Object . Skelton Objects are always Created in the Server Side. When a Server Receive Request from a Client then he Performs :-

Retrieve all the Parameters or Arguments those are Send by Client or Stub.
Locate that Object which is Called by Stub.
Call the Method.
Then Find out the Results after Executing that Method.
Sends the Results back to the Clients.

Locating Remote objects and Providing Reference to them

For locating and providing the reference of remote objects there are must be some sort of catalog or either the database objects and a serer that will provide the access to those catalogs. Whenever a program need a service then it first ask from the catalog server that whether the service is provide to it by using the server object or not . we can't sort a reference to a object simply on a network, for this garbage collection is used which tells us whether remote reference to an object exist or not. An object must not send references whenever a remote computer even the location is out using this uses it. So that before Locating any Remote Object that Remote Object must be Checked whether it is Available or not So that a information Must be Contained in both the Client and Server. Means a Client Must Knows that Method is Exists on the Server and Server also Maintains that all the Required information is Send by Client is Successfully Reached and a Server Contains that Requested Method. Whenever we wants to Make a Method as a Remote then The Server Class or a Method which we wants to being Available to all the other Client Must Extends the Class Remote. And also throws Exception known as Remote Exception Which is Occurred because Possibility of Network Failure. And also Contains an Object of UnicastRemoteObject Class which will act as the server interface or which Provides the Methods to the Clients. And also use the java.rmi Package which contains all the Required Classes.

Enabling Remote Method Call

This method requires a mechanism for obtaining a reference to a target method and then passing the argument and return values from or across the network.

Notifying Programs of Network Failure or other Problems

In the distributed if there is an occurrence of any problem then the application is need not shutdown. But it simply advice the user that your request is not available. But in the standalone application this facility is less commonly helpful in the application.

RMI Architecture

The RMI architecture of RMI consists of four layers: -

Application.
Proxy Layer or Stub-Skeleton.
Remote Reference.
Transport Layer.

The following diagram shows the RMI layers:

Application Layer

Any application that wants to make some of its methods available in the remote client then those are first declared in an instance that extends java.rmi.remote and all these methods are declared as public in which these are implemented. But remember at the time of creating interface it doesn't define the methods in the interface. The entire remote object must extend the UnicastRemoteObject class, which provides functionality that is, need to make objects available from remote machine. These classes belong to the package java.rmi.Server. Then the server normally registers itself with a name server or registry. The client first users this registry or name servers to make first contact with the server and obtain a reference to its remote objects.

Proxy Layer

RMIC stubs , RMI compiler for client-side and server-side representation of remote object generates the stub and skeleton classes. A program that is running on the client machine uses stub classes for marshalling the information from client to remote object means it is used for transport the parameter exceptions and errors and it is also responsible for returning the result from the remote object. It first marshals object information to byte stream and then it send it over the network and then it is de-marshalled on the server-side proxy of remote object. The stub always receives a reference from its class for a remote object from the remote reference layer. It uses the RRL for communicating with a skeleton on the server-side of the skeleton class.

Stub Class

The stub is a client-side proxy. Stubs define all of the interfaces that the remote object implementation supports. A program running on the client machine references the stub the same way that it references any other local object.

The stub is responsible for making a call to a remote object as well as for marshaling information to and from a remote object. A stub receives a reference to a remote object from the Remote Reference Layer. A stub uses a marshal stream for communication with a skeleton on the server side. A marshal stream is also acquired through the Remote Reference Layer.

Skeleton Class

The skeleton is the server-side proxy that interfaces with the server RRL. It received the request of calling the remote method from the client and then it de-marshalled the arguments that are sending to a remote method. This class stays on the server-side connection and directly deals with the implemented classes of Remote methods. It is responsible for sending the parameters to the method and then sending the results or any error back to the client. The skeleton first de-marshal information send by stub and then it marshal information, which is being sent back to the s/w.

Remote Reference Layer

In this layer it receives the information from the stub class and then send to the skeleton class. It is used for setting the connection from the transport layer. The actual transport layer may take place by using a non-connection based but they will represent their communication as a connection-based.

Transport Layer

This layer is responsible for the machine-to-machine communication. By default it uses a TCP/IP connection. This layer can be responsible for handling encrypted streams, or any other security or performance related works. This is independent from all the other three layers. When a client request for the remote objects it first establish the connection with the server and add a reference of the remote object into his internal table. It checks the livens of the connection. It checks that if within the 10 minutes if no actions are performed using the connection. Then it shuts down the connection.

RMI Registry Service

In the distributed application if a client-side wants to able or locate a method or if he is calling a remote object then it is must that the remote object must be registered. If a server registers any of its remote object then it is registered by using registry service or name service of RMI. If a client wants to locate a remote object then this remote object exported using the name server or called a registry. With lookup method a reference to the remote object is returned if the lookup is successful.

Registry services can be used in one of two ways -

For using the Registry Service first is to look-up the name of server on the well-defined port-number.
The second is running its own registry services but by specifying the port number we can registers the remote objects in the registry table. Then we can call hem by using the rmi registry. Registry interface or from rmi naming class.

RMI uses the first method to maintain a registry. The registry keeps track of the addresses of all the remote objects that are being exported by their applications. All objects are assigned unique names that are used to identify them. Applications can add, remove, and access remote objects in the registry's table of objects by calling certain methods from the rmi.registry.Registry interface, or from the rmi.Naming class.

To create an application that uses RMI, one needs to use the classes and interfaces defined by the java.rmi package.

To create an RMI application, the following steps need to be followed:

Creating RMI Applications

To create an application that uses RMI, one needs to use the classes and interfaces defined by the java.rmi package.

To create an RMI application, the following steps need to be followed:

Define an Interface for the Remote Classes

Implement the Interface in a Server-side Application

Bind Objects to a Registry Service

Create Stubs and Skeletons classes

Create and Compile the Client Program to Access the Remote Objects

Install files on the Client and Server Machines

Start the RMI Registry

Define an Interface for the Remote Classes

To implement the RMI bases client/server application, an interface is created that contains all the methods that the remote object must support. All interfaces for remote objects must extend the Remote interface defined in java.rmi package. All the methods in those interfaces must include a throws RemoteException statement. The reason is that remote method calls are inherently less reliable that local calls. It is always possible that the remote calls fails. The server or the network connection may be temporarily unavailable. The client code must be prepared to deal with this. For these reasons, Java forces the programmer to catch the RemoteException with every remote method call and to specify the appropriate action to be taken when the call doen not succeed.

Example:

The following contains a simple interface that can be used with a remote object

import java.rmi.*;
interface MethodImpl extends Remote
{
	double getSqrt(double dbl) throws RemoteException;
}

The above example creates an interface which defines getSqrt() method which will be invoked by the client.

Compile the interface using the javac compiler.

Implement the Interface in a Server-side Application

The next step is to implement the remote interface in a server-side application. The server application extends the UnicastRemoteObject class and implements the remote interface inside the class. All remote objects must extend UnicastRemoteObject, which provides functionality that is needed to make objects available from remote machines.

Example:

class RMIServer extends UncastRemoteObject implements MethodImpl
{
	//code to implement
}

A security manager on a server prevents random clients from connection and making unauthorized calls. This is done by configuring the security manager to allow or disallow various operations. The java class library includes a class called RMISecurityManager, which can be used for this purpose.

Bind Objects to a Registry Service

Any Server application, which wishes to make remote objects available to client applications, must first register those objects with a registry service. For an application to bind or register an object with the registry, both the registry service as well as the application must be running on the same machine.

An application can bind any object to the registry, provided that object either extends the UnicastRemoteObject class, or extends a Remote interface.

For a server application to bind an object to a registry, the following is required:

»  A reference to an instance of the object.
»  The address of the registry server.
»  A unique name that the object will be registered as.

A client application invokes a remote object by using the name with which that object is registered with the registry service. As a result no two objects can be registered with the same name.

The java.rmi.Naming class has provided two methods for binding objects to a registry service. These two methods are - bind() and rebind()

The bind() Method()

Syntax: java.rmi.Naming.bind(URL,Ref)

This method takes two parameters -
»  URL specifies the location of the registry along with the name that objects will
    be registered as.
»  Ref is a reference to the object that is being registered.

The bind() method will throw an exception if it tries to bind a name that already exists in the registy service.

Example:

The following block of code attempts to bind an object of "RMIServer" class with a registry service running on a computer whose URL is "www.yourservername.com" under the name "RefsctEmp".

The code also traps the MalformedURLException, UnknowHostException and the AlreadyBoundExcpetion, which may be throun.

try
{
    RMIServer MYEmp=new RMIServer();
    java.rmi.Naming.bind("rmi://www.yourservername.com/RefsctEmp",RefsctEmp);
}
catch(MalformedURLException malformURLExcp)
{
	System.out.println("Invalid URL!!");
}
catch(UnknowHostException UnknowHtExcp)
{
	System.out.println("Cannot resolve Hostname!!");
}
catch(AlreadyBoundException AlrdyBondExcp)
{
	System.out.println("This name is already is use!!");
}

The rebind() Method()

Syntax: java.rmi.Naming.rebind(URL,Ref)

This method takes the same two parameters as the bind() method.
»  URL specifies the location of the registry along with the name that objects will
    be registered as.
»  Ref is a reference to the object that is being registered.

The rebind() method differs from the bind() method in that it will not throw an AlreadyBoundException exception. The rebind() method will simple replace any previously registered objects possessing the same name, with the current object.

Example:

The following example contains a server application that implements the MethodImpl interface and binds the remote methods with the registry.

The user defined interface i.e. MethodImpl is as shown:

import java.rmi.*;

interface MethodImpl extends Remote
{
	double getSqrt(double dbl) throws RemoteException;
}

Compile the above code on the Server.

C:\>javac MethodImpl.java

The server application returns the square root of number to the remote client.

import java.rmi.*;
import java.rmi.registry.*;
import java.rmi.server.*;

public class RMIServer extends UnicastRemoteObject implements MethodImpl
{
	public RMIServer() throws RemoteException{}
	{
		System.out.println("The Server is instantiated");
	}
	public double getSqrt(double dbl)
	{
		//Returns the square root of the number passed as argument
		return Math.sqrt(dbl);
	}		
        public static void main(String[] arguments)
	{
		try
		{
			//Instantiates the RMIServer object
			RMIServer server=new RMIServer();

			/*The rebind() method takes two arguments, URL name and the Remote 
			object which binds the remote object to the remote registy */
			Naming.rebind("sqrt",server);

			/*The name sqrt is a bind name given to the remote object, which gets
			registered with the RMI registry through which remote calls are made*/
		}
		catch(Exception exce)
		{
			System.out.println("Erro -- " +exce.toString());
		}
	}//End of main() method
}//End of RMIServer class

Compile the RMIServer application using the javac compiler.

This will create RMIServer.class

Create Stubs and Skeletons classes

The Stubs and Skeleton layers can be created using the rmic compiler, which comes along with the JDK.

Example:
The following examples creates the Stub and Skeleton classes by specifying the server application class file and the interface created to the rmic compiler.

rmic RMIServer

This will create the stubs and skeltons:

RMIServer_stub.class and RMIServer_skel.class

Create and Compile the Client Program to Access the Remote Objects

The client is implemented to access the remote objects created to use the remote interface and calls the methods from that interface.

A stub as seen earlier is a Java object that resides on the client machine. It's function is to present the same interface as the remote server. Remote method calls are actually directed to the stub. The stub workds with the other parts of the RMI system to formulate a request that is sent to the remote machine.

A remote machine may accept the arguments that are simple types or objects. In the latter case, the object may have references to other objects also. All of this information must be send to the remote machine.

A skeleton as seen earlier in Java object that resides on the server machine. It works with other parts of the RMI system to receive requests and invoke the appropriate code on the server.

Obtaining a reference to a remote object is accomplished by making a call to the lookup() method of the java.rmi.Naming class.

The java.rmi.Naming.lookup() Method

Syntax: java.rmi.Naming.lookup(URL)

This method takes a URL as its parameter. The URL points to the registy and the object that the client application requires. If the lookup() method finds the object, it will return a reference to that object else it may throw a NotBoundException.

Example:

The following example creates a client application that makes a reference to the remote object using lookup() method.

The client application receives the square root of the number passed.

import java.rmi.*; import java.rmi.registry.*; public class RMIClient { public static void main(String[] arguments) { try { MethodImpl mthdImpl=(MethodImpl)Naming.lookup("rmi://127.0.0.1/sqrt"); /* '127.0.01' represents local host and sqrt is the name with which the server object is registered. */ double dbl=mthdImpl.getSqrt(100); System.out.println("SQRT:"+dbl); } catch(Exception exec) { System.out.println("Error--" +exec.toString()); } }//End of main() method }//End of RMIClient class

Compile the RMIClient using the javac compiler.

The lookup() methods returns an object of type java.rmi.Remote and hence must always be cast to the type of object the client application (in this case, MethodImpl).

Install files on the Client and Server Machines

Incase the Server Application and Client Application is run on separate machines then:

Copy RMIClient.class, MethodImp.class, RMIServer_stub.class to a directory on the client machine.
Copy RMIServer_stub.class, RMIServer_skel.class, MethodImpl.class to a directory on the server_machine.

Start the RMI Registry

Sun Microsystems has provided an RMI registry application (rmiregistry) as part of the JDK. The RMI registry application is normally started as a background application that will by default run on port 1099. On a Windows machine, by issuing the following command at the DOS prompt: the RMI registry application can be started.

rmiregistry <port number>

The <port number> argument is optional. By default the rmiregisty will run on port 1099. This command will load and execute rmiregistry as a TSR application in Windows. To run the RMI registry in a separate DOS shell, the registry can be started with the DOS "start" command. For example

C:>start rmiregistry

The above statement start the registry service at the default port i.e. 1099. and will show new window as shown below.

Creating A Model For An Air-line Reservation Using RMI

<< Previous Topic	Next Topic >>

	Section 1
	Home
	Introduction To Java
	Java Evolution
	Overview of Java
	Constants, Variables & Data Types
	Java Operators
	Branching Statements
	Looping Statements
	Section 2
	Classes, Objects & Methods
	Inheritance
	Array, String & Vectors
	Java Interfaces
	Java Packages
	Java Applet Programming
	Java Graphics Programming
Advance Java Programming
	Section 1
	Java AWT
	Java Event Handling
	Java File Handling
	Java MultiThreading
	Java Swing-I
	Java Swing-II
	Java Exception Handling
	Section 2
	Java Socket Programming
	Java Database Connectivity
	Java RMI
	Java Servlets
	Java Beans

Java - Remote Method Invocation (RMI)

Creating RMI Applications

2 comments:

Useful Links

Visitors

Java Tutorials

Follow by Email

Follow Advanced Java Programming on Facebook

Popular Programs

Follow Advanced Java Programming on Twitter