RMI remote method invocation

Traditional network programming The client program sends data to the server in some intermediary format and the server has to parse the data, and prepare response data in the required format, and sends response data. The client then parses the response data and displays the data. This is good but it requires involved parties to communicate via some application-level protocol designing which can involve lot of coding and could be error-prone. Request data Response data

Inter-object communication Solution to this is Inter-object communication using RMI. (Inter-object communication can also b done using CORBA –discussed at the end of this topic.) RMI allows communication between two java residing on different JVMs. This allows client applications to call an object method located on the server. The object on the server is called remote object and the method is called remote method. In others words, 1.A set of collaborating objects which can reside anywhere. These objects will provide a some services. 2.Any object residing in any machine can create an object of the above type and call a method on that object as if they were residing on the same machine.

RMI customer warehouse warehouse.findProduct() product client server RemoteObject In RMI terminology, server is the one that hosts the remote object (also called server object) and the client is the one which is invoking the remote method. RMI technology internally uses network programming to achieve this.

For RMI to be possible 3 things are required: 1.Client java object must have access to the server java object. a.Server needs to advertise its objects that can be accessed remotely. b.Clients need a unique way to locate the remote objects. 2. The method parameter must be some how shipped to the other machine. 3. The return data also must be shipped back in some way.

Point 1: Registering remote object How will the server announce the availability of this object to other clients ? The Sun RMI library has something called a bootstrap registry service. This service is a naming and directory service where servers can register its remote object and client can locate remote objects. The registry service can be in the same machine as the server machine or in the different machine. 1.First the server program registers server (remote) objects with the bootstrap registry service. Server programs provides a name for the object using which the client do the can lookup. As a result of this a Remote Object Reference is created. The reference to the object and a name is registered in the registry.

Remote Object Reference is associated with every remote object. It represents unique identifier of remote object in the distributed system. Internet address of the server+port no+time of creation +local object no.+ name of the remote object’s interface. There is a table maintained by RMI architecture to map actual objects and its remote object reference. 2.Now the client access the remote object by specifying the name of the object along with the url. The protocol used is ‘rmi i.e. rmi://servername:port/objectname.Default port is 1099.

Remote object Reference Name Dict English_Dict ….. Client lookup() bootstrap registry service. Server bind()

Point 2: Stub When the client access the remote object by specifying the name of the object along with the url what is returned is something called a stub. A stub for a remote object acts as a client's local representative or proxy for the remote object. Therefore, client object attempts to makes a call on server object (remote object), it actually calls a method on the stub that resides on the client machine( stubs are dynamically downloaded from the server m/c to the client m/c). The stub has the same methods which remote object has. The stub forwards the request via RMI framework to the remote object.

Stub takes care of sending the data to the server object. The process of converting data or object into a byte stream by the stub is called parameter marshalling. Stub does the following tasks 1.Initiates a connection with remote JVM. 2.Marshals the parameters and send to the remote JVM. 3.Waits for the reply from the remote objects. 4.Unmarshals the return value and returns to the client program.

Point 3: Skeleton/Server side process On the server side, the receiver object performs the following actions for every method call: 1.It unmarshals the parameters. Parameters should be serializable. 2.It locates the object to be called. 3.It calls the desired method 4.It gets the return data and marshals it. 5.It sends the marshaled data to the client. In Java 1.x each remote object may have a corresponding skeleton (from java 2 onwards, skeletons are not required).

ClientStub Skeleton Server Call stub method locally Send the marshaled parameters Call server method locally Send the marshaled return value return value client server RMI uses a protocol called Java Remote Method Protocol(JRMP).

Client Stub Remote reference layer TCP IP Hardware interface Server Skeleton TCP IP Hardware interface Remote reference layer Session layer Presentation layer Application layer Transport layer Network layer Physical layer RMI Architecture

The remote reference layer Defines and supports the invocation semantics of RMI connection.This layer provides Java Remote Method Protocol(JRMP). On the client side it maintains a table of remote object reference and its stub objects. On the server side it maintains a table of remote object reference and its local reference.

Lookup steps When client invokes a lookup for a particular url in registry 1.A socket is opened to the specified port. 2.Since registry implementation on the server itself is remote object, a stub to that remote object is returned from the host. The stub acts as proxy for the registry. 3.The call to lookup is performed on this stub object and another stub for the actual remote object is returned 4.Once this stub is obtained the further interaction takes place with this stub.

Good news Stub classes hence have lot of work to do. Good news is that stub classes can be created automatically. Since client requires stub classes, they are also automatically downloaded by the client. –Dynamic class loading. So classes in the server can be changed anytime without affecting client. When the client makes a call to the remote object, the updated stub gets automatically downloaded.

Implementation 1.Define a remote object interface which will contain methods of the remote object that client can invoke. It should extend ‘Remote’ which contains no methods. 2.Implement class for the remote object ( which will implement the above remote object interface). 3.Generate stubs 4.Write client class which will invoke the remote object’s methods. 5.Start the registry and register the object and run the server. 6.Run the client

1. Remote object interface A remote interface is the set of methods that the client can invoke on the remote object. Rules: Must be a public class. Must extend java.rmi.Remote interface. All methods in this class should throw RemoteException. If the remote methods have any remote objects as parameters they must be of interface types. java.rmi.Remote interface has no methods. It is just used to tag an object as remote object. Only object of Remote type can be registered in bootstrap registry.

import java.rmi.*; public interface Dict extends Remote{ public String getMeaning(String word) throws RemoteException; }

2. Remote object class Rules: Must be a public class. Must implement java.rmi.Remote interface. Must extends java.rmi.RemoteServer class which is an abstract class that has some method for basic communication between server and client objects. java.rmi.server.UnicastRemoteObject is a convenience class that implements extends Remote server class and provides implementation for all the methods. So invariably all the remote object extends this class. Create a remote object and bind a name to it so that the name and the remote object could be registered in the registry.

import java.rmi.*; import java.rmi.server.*; import java.util.Hashtable; public class DictImpl extends UnicastRemoteObject implements Dict{ Hashtable wordlist= new Hashtable(); public DictImpl() throws RemoteException{} public String getMeaning(String word) throws RemoteException{ return (String)wordlist.get(word);} private void setWord(String word, String meaning){ wordlist.put(word,meaning);}

public static void main(String str[]){ try{ DictImpl dic= new DictImpl(); dic.setWord("Fantasy","Dream"); dic.setWord("Earnest","sincere, honest"); java.rmi.Naming.rebind("EnglishDic",dic); }catch(Exception e){ System.out.println(e); }} }

3. Generate stubs After creating remote object class, we need to create stubs, so that client can download it. A tool called rmic generates stubs automatically. rmic –v1.2 DictImpl Creates DictImpl_Stub.class For JDK 1.1 rmic DictImpl

4. Write client class 1. Client program cannot download remote stubs from network if security manager has not been set.The RMISecurityManager is a security manager which should be set to enable RMI. System.setSecurityManager(new RMISecurityManager()) 2. Client program makes a lookup for remote object. 3. While running client client.policy file is specified so that the RMISecurityManager that is loaded gets the policy from this file.

public class DictClient { public static void main(String str[]){ try{ System.setSecurityManager(new java.rmi.RMISecurityManager()); String url="rmi://localhost/EnglishDic"; Dict dic =(Dict)java.rmi.Naming.lookup(url); System.out.println(dic.getMeaning("Earnest")); }catch(Exception e){ System.out.println(e.toString()); } }}

client.policy grant{ permission java.security.AllPermission; };

Running the application 1.Compile all source files. javac *.java 2. Run rmic on the implementation class rmic –v1.2 DictImpl 3. Start RMI registry start rmiregistry 4. Start the server Start java DictImpl 5. Run the client java –Djava.security.policy=client.policy DictClient

Dict_Client Dict_Impl Class which creates server object(Dict_Impl) RRL maintains a table of Dict_Impl reference object and its local reference Registry maintains a mapping of Dict_Impl reference object and its name RRL maintains a table that maps Dict_Impl reference object and the stub objects. Dict_Impl_Skeleton Dict_Impl_Stub Client Server bootstrap registry service

CORBA Common object request broker architecture. Standard by OMG (Object Management Group) group. Defines the common mechanism for interchanging data and discovering services. The object exchanging data may be objects written in any language. The idea is that task of finding out the information about the object that provide services and activating any requested services is delegated to a so-called Object request broker(ORB). = Specification followed by most ORB is called Inter-ORB protocol (IIOP). Sun and IBM have developed next version of RMI that uses IIOP called RMI-IIOP. ORB