RMI remote method invocation

1. RMIremote method invocation

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

3. 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, • A set of collaborating objects which can reside anywhere. These objects will provide a some services. • 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. Inter-object communication

4. RMI 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. server client warehouse warehouse.findProduct() customer product RemoteObject

5. For RMI to be possible 3 things are required: • Client java object must have access to the server java object. • Server needs to advertise its objects that can be accessed remotely. • 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.

6. 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. • 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. Point 1: Registering remote object

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

8. Client Server lookup() bind() Remote object Reference Name 193.139.100.1+1099+555444+2222+Dict English_Dict … .. bootstrap registry service.

9. When the client access the remote object by specifying the name of the object along with the urlwhat 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. Point 2: Stub

10. 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 • Initiates a connection with remote JVM. • Marshals the parameters and send to the remote JVM. • Waits for the reply from the remote objects. • Unmarshals the return value and returns to the client program.

11. Point 3: Skeleton/Server side process • On the server side, the receiver object performs the following actions for every method call: • It unmarshals the parameters. Parameters should be serializable. • It locates the object to be called. • It calls the desired method • It gets the return data and marshals it. • 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).

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

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

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

15. When client invokes a lookup for a particular url in registry • A socket is opened to the specified port. • 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. • The call to lookup is performed on this stub object and another stub for the actual remote object is returned • Once this stub is obtained the further interaction takes place with this stub. Lookup steps

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

17. Implementation • 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. • Implement class for the remote object ( which will implement the above remote object interface). • Generate stubs • Write client class which will invoke the remote object’s methods. • Start the registry and register the object and run the server. • Run the client

18. 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. 1. Remote object interface

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

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

21. 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); }

22. 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); }} }

23. 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.2DictImpl Creates DictImpl_Stub.class For JDK 1.1 rmicDictImpl

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

25. 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()); } }}

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

27. Running the application • 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

28. Server Class which creates server object(Dict_Impl) Client 1 Dict_Impl Dict_Client 12 16 7 8 2 3 Dict_Impl_Skeleton Dict_Impl_Stub 11 13 4 9 15 6 RRL maintains a table of Dict_Impl reference object and its local reference RRL maintains a table that maps Dict_Impl reference object and the stub objects. 10 14 5 Registry maintains a mapping of Dict_Impl reference object and its name bootstrap registry service

29. 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. CORBA ORB