RMI (Remote Method Invocation) PDF

RMI (Remote Method Invocation) 1. Introduction The Java allows us to develop distributed applications using RMI. Distributed computing refers to the application design paradigm in which programs, the data they process, and the actual computations are spread over a network either to leverage the proc...

RMI (Remote Method Invocation) 1. Introduction The Java allows us to develop distributed applications using RMI. Distributed computing refers to the application design paradigm in which programs, the data they process, and the actual computations are spread over a network either to leverage the processing power of multiple computers or due to the inherent nature of an application computing different modules. RMI (Remote method Invocation) allows object-to-object communication between different Java Virtual Machines (JVMs). JVMs can be distinct entities located on the same or separate computers –yet one JVM can invoke methods belonging to an object stored on another JVM. This enables applications to call object methods located remotely, sharing resources, and processing load across systems. Methods can even pass objects that a foreign virtual machine has never encountered before, allowing the dynamic loading of new classes as required. This is really a quite powerful feature. Other Alternatives to RMI: ❑ Sockets ❑ EJB ❑ CORBA ❑ DCOM Basic network programming with sockets is flexible and sufficient for communication between programs. However, it requires all the involved parties to communicate via application-level protocols, the design of which is complex and can be error prone. For example, consider a collaborative application like a simple chat application for instance: for multiple clients to participate we would first need to design some sort of protocol, and then use sockets to communicate in that protocol with the server. RMI, on the other hand, is a distributed system that internally uses sockets over TCP/IP. 2. RMI Architecture RMI’s purpose is to make objects in separate JVM’s look alike and act like local objects. The JVM that calls the remote object is usually referred to as a client and the JVM that contains the remote object is the server. One of the most important aspects of the RMI design is its intended transparency. Applications do not know whether an object is remote or local. A method invocation on the remote object has the same syntax as a method invocation on a local object, though under the hood there is a lot more going on. ❑ In RMI the term “Server” does not refers to a physical server or application but to a single remote object having methods that can be remotely invoked. ❑ Similarly the Term “Client” does not refer to a client m/c but actually refers to the object invoking a remote method on a remote object. The same object can be both a client and a server. LogicPace Technologies Private Limited 67/148, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) Although obtaining a reference to a remote object is somewhat different from doing so for local objects. Once we have the reference, we use the remote object as if it were local. The RMI infrastructure will automatically intercept the method call, find the remote object and process the request remotely. This location transparency even includes garbage collection. A remote object is always accessed via its remote interface. In other words the client invokes methods on the object only after casting the reference to the remote interface. The RMI implementation is essentially built from three abstraction layers: ❑ The Stub/Skeleton Layer ❑ The Remote Reference Layer ❑ The Transport Layer The following diagram shows the RMI Architecture: Client Object Server Object Client invoking method on the Remote object Application Layer remote object Stub Skeleton Presentation Layer Remote Remote Reference layer Reference layer Session Layer TCP TCP Transport layer IP IP Network Layer Hardware Hardware Data link Layer Interface Physical Layer Interface RMI Architecture 2.1 The Stub/Skeleton Layer This layer intercepts method calls made by the client to the interface reference and redirects these calls to a remote object. Stubs are specific to the client side, whereas skeletons are found on the server side. LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) To achieve location transparency, RMI introduces two special kinds of objects known as stubs and skeletons that serve as an interface between an application and rest of the RMI system. This Layer’s purpose is to transfer data to the Remote Reference Layer via marshalling and unmarshalling. Marshalling refers to the process of converting the data or object being transferred into a byte stream and unmarshalling is the reverse - converting the stream into an object or data. This conversion is achieved via object serialization. The Stub/ Skeleton layer of the RMI lies just below the actual application and is based on the proxy design pattern. In the RMI use of the proxy pattern, the stub class plays the role of the proxy for the remote service implementation. The skeleton is a helper class that is generated by RMI to help the object communicate with the stub; it reads the parameters for the method call from the link, makes the call to the remote service implementation object, accepts the return value and then writes the return value back to the stub. In short, the proxy pattern forces method calls to occur through a proxy that acts as a surrogate, delegating all calls to the actual object in a manner transparent to the original caller. 2.1.1 Stub The stub is a client-side object that represents (or acts as a proxy for) the remote object. The stub has the same interface, or list of methods, as the remote object. However when the client calls a stub method, the stub forwards the request via the RMI infrastructure to the remote object (via the skeleton), which actually executes it. Sequence of events performed by the stub: ❑ Initiates a connection with the remote VM containing the remote object ❑ Marshals (writes and transmits) the parameters to the remote VM. ❑ Waits for the result of the method invocation. ❑ Unmarshals (reads) the return value or exception returned. ❑ Return the value to the caller In the remote VM, each remote object may have a corresponding skeleton. 2.1.2 Skeleton On the server side, the skeleton object takes care of all the details of “remoteness” so that the actual remote object does not need to worry about them. In other words we can pretty much code a remote object the same way as if it were local; the skeleton insulates the remote object from the RMI infrastructure. Sequence of events performed by the skeleton: ❑ Unmarshals (reads) the parameters for the remote method (remember that these were marshaled by the stub on the client side) ❑ Invokes the method on the actual remote object implementation. ❑ Marshals (writes and transmits) the result (return value or exception) to the caller (which is then unmarshalled by the stub) 2.2 The Remote Reference Layer LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) The remote reference layer defines and supports the invocation semantics of the RMI connection. This layer maintains the session during the method call. 2.3 The Transport Layer The Transport layer makes the stream-based network connections over TCP/IP between the JVMs, and is responsible for setting and managing those connections. Even if two JVMs are running on the same physical computer, they connect through their host computers TCP/IP network protocol stack. RMI uses a protocol called JRMP (Java Remote Method Protocol) on top of TCP/IP (an analogy is HTTP over TCP/IP). From the JDK 1.2 the JRMP protocol was modified to eliminate the need for skeletons and instead use reflection to make connections to the remote services objects. Thus we only need to generate stub classes in system implementation compatible with jdk 1.2 and above. To generate stubs we use the Version 1.2 option with rmic. The RMI transport layer is designed to make a connection between clients and server, even in the face of networking obstacles. The transport layer in the current RMI implementation is TCP-based, but again a UDP-based transport layer could be substituted in a different implementation. 3. Locating Remote Objects Clients find remote services by using a naming or directory service. A naming or directory service is run on a host and port number that the client is already aware of (for example a well-known port on a public host). The RMI naming service, a registry, is a remote object that serves as a directory service for clients by keeping a hash table like mapping of names to other remote objects. It is not necessary to have a single registry on a particular physical host. An object is free to start its own registry. The behavior of the registry is defined by the interface java.rmi.registry.Registry. RMI itself includes a simple implementation of this interface called the RMI Registry. RMI Registry runs on each machine that hosts remote objects and accepts queries for services, by default on port 1099. In Simple terms, a remote object is associated with a name in the registry. Any time the client wants to invoke methods on this remote object it obtains a reference to it by looking up the name. The lookup returns a remote reference, a stub to the object. RMI also provides the java.rmi.Naming class that serves as the client’s interaction point with the object serving as the registry on the host for this lookup. This can be thought of as a client of the RMI Registry. The naming class’s methods take, as one of their arguments, a name that is a URL-formatted java.lang.String. The following diagram shows how the client uses the java.rmi.Naming class to lookup the stub/proxy of the remote object or LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) rmi protocol Registry Registry.lookup Naming Naming.lookup Client java.rmi.Naming The program which creates the instance of the remote object also makes use of the java.rmi.Naming class to bind the remote object to the RMI Registry. 3.1 The java.rmi.Naming class This class behaves as a client to the RMI Registry. It is used on the server side as well as on the client side to interact with the RMI Registry. On the server side it is used to bind the remote object to the RMI Registry. On the client side it is used to lookup the remote object. Methods All the methods of this class are static. ❑ public static void bind (String name, Remote obj) It binds the remote object to a string name. The name itself is in the RMI URL format. ❑ public static Remote lookup (String name) It returns a reference, a stub, for the remote object associated with the specified name. ❑ public static void rebind (String name, Remote obj) It rebinds (unbinds the name if it is already bound and binds it again) the specified name if it already in use to a new remote object. This could be dangerous if different applications use the same name in the registry but is helpful in development. ❑ public static void unbind (String name) It removes the binding with specified name. Once the client has a stub to the requested object, it can access the remote method transparently, just like local methods. The URL takes the form: rmi://[:]/ LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) Where: ❑ host_name is a name recognized on the local area network (LAN) or a DNS name on the Internet. ❑ name_service_port needs to be specified only if the naming service is running on a port other than the default 1099 ❑ service_name is the string name that the remote object is associated with in the registry. 4. Developing Applications with RMI Steps for developing RMI applications are as follows: 1. Defining the remote interface. 2. Implementing the remote interface. 3. Writing the code for registering the object. 4. Writing the client that uses the remote objects. 5. Generating stubs (client proxies) and skeletons (server entities). 6. Running the RMI Registry, server and client. 4.1 Defining the Remote Interface An interface manifests the exposed operations and the client programmer need not be aware of the implementation (the interface in this case also serves as a marker to the JVM). A remote Interface by definition is the set of methods that can be invoked remotely by a client: ❑ The remote interface must be declared public or the client will get an error when it tries to load a remote object that implements the remote interface. ❑ The remote interface must extend the java.rmi.Remote interface. ❑ Each method must throw a java.rmi.RemoteException (or a superclass of RemoteException) ❑ If the remote methods have any remote objects as parameters or return types, they must be interface types not the implementation classes. Note: java.rmi.Remote interface has no methods. It is just a marker interface. Example: The example discussed in the following sections illustrates how to define and invoke methods on a remote object. We will define our Remote Interface (HelloInterface.java) as follows: HelloInterface.java 1 import java.rmi.*; 2 public interface HelloInterface extends Remote 3 { 4 public String sayHello() throws java.rmi.RemoteException; 5 public void add(int a,int b)throws java.rmi.RemoteException; 6 public int square(int a) throws java.rmi.RemoteException; 7 } LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) 4.2 Implementing the Remote Interface Object java.rmi.server.RemoteObject (abstract class) java.rmi.server.RemoteServer (abstract class) java.rmi.server.UnicastRemoteObject java.rmi.activation.Activatable The implementing class is the actual class that provides the implementation for methods defined in the remote interface. The java.rmi.server.RemoteObject extends the functionality provided by the java.lang.Object class into the remote domain by overriding the equals(), hashcode() and toString() methods. The generic java.rmi.server.RemoteObject is an abstract class and describes the behavior of remote objects. The abstract subclass java.rmi.server.RemoteServer describes the behavior associated with the server implementation and provides the basic semantics to support remote references. java.rmi.RemoteServer has two concrete sub-classes ❑ java.rmi.server.UnicastRemoteObject It designs a non-replicated remote object whose reference is valid only when the server is alive. ❑ java.rmi.activation.Activatable It is the concrete class that defines behavior for on demand instantiation of remote objects. In addition to one of the above classes, the class corresponding to the remote interface must implement one or more interfaces that define the remote methods. A remote class can define any methods but only methods in the remote interface can be invoked remotely. HelloServer.java: Remote class, which implements the remote interface. 1 import java.rmi.*; 2 import java.rmi.server.*; 3 public class HelloServer extends UnicastRemoteObject 4 implements HelloInterface 5 { public HelloServer() throws RemoteException 6 { super(); 7 } 8 public String sayHello() throws RemoteException 9 { return "hello world"; 10 } 11 public void add(int a,int b)throws java.rmi.RemoteException 12 { System.out.println("addition = "+(a+b)); 13 } 14 public int square(int a) throws java.rmi.RemoteException 15 { return a*a; 16 } 17 } LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) 4.3 Registering the Remote Object Now that we have the interface and the implementation, we need to make this object available to clients by binding it to a registry. This will allow the clients to look the object up on the host by a String name. The stubs and skeletons (if any) are needed for registration. After all it is the object stub that is going to be passed around from the registry to the clients. MyRMI.java: Code for registering remote object. 1 import java.rmi.*; 2 public class MyRMI 3 { public static void main(String args[]) 4 { try 5 { HelloServer hs=new HelloServer(); 6 HelloServer hs1=new HelloServer(); 7 Naming.bind("remote1",hs); 8 Naming.bind("remote2",hs1); 9 }catch(Exception e) 10 { 11 System.out.println("in exxx "+e); 12 } 13 } 14 } MyRMI1.java: Code for registering remote object (another version). 1 import java.rmi.*; 2 public class MyRMI1 3 { public static void main(String args[]) 4 { try 5 { HelloServer hs=new HelloServer(); 6 HelloServer hs1=new HelloServer(); 7 Naming.bind("rmi://172.16.1.1:1099/remote1",hs); 8 Naming.bind("rmi://172.16.1.1:1099/remote2",hs1); 9 }catch(Exception e) 10 { 11 System.out.println("in exxx "+e); 12 } 13 } 14 } MyRMI2.java: Code for registering remote object (another version). 1 import java.rmi.*; 2 public class MyRMI2 3 { public static void main(String args[]) 4 { try 5 { HelloServer hs=new HelloServer(); 6 HelloServer hs1=new HelloServer(); 7 Naming.rebind("rmi://192.168.1.49:2000/remote1",hs); 8 Naming.rebind("rmi://192.168.1.49:2000/remote2",hs1); 9 }catch(Exception e) 10 { 11 System.out.println("in exxx "+e); 12 } 13 } 14 } 4.4 Writing the Client that uses the Remote Object LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) The client performs a lookup on the registry on the host and obtains a reference to the remote object. Note that casting to the remote object is critical. In RMI, clients always interact with the interface, never with the object implementation. HelloClient.java: Code for client that uses the remote object. 1 import java.rmi.*; 2 public class HelloClient 3 { public static void main(String args[]) 4 { String msg=""; 5 try 6 { HelloInterface hs=(HelloInterface)Naming.lookup("/remote1"); 7 msg=hs.sayHello(); 8 hs.add(10,20); 9 int x=hs.square(20); 10 System.out.println("message + square ="+msg+ " "+x); 11 hs=(HelloInterface)Naming.lookup("/remote2"); 12 msg=hs.sayHello(); 13 System.out.println("message ="+msg); 14 }catch(Exception e) 15 { System.out.println(e); 16 } 17 } 18 } HelloClient1.java: Code for client that uses the remote object (another version). 1 import java.rmi.*; 2 public class HelloClient1 3 { public static void main(String args[]) 4 { String msg=""; 5 try 6 { HelloInterface hs=(HelloInterface) Naming.lookup("rmi://172.16.1.1:1099/remote1"); 7 msg=hs.sayHello(); 8 hs.add(10,20); 9 int x=hs.square(20); 10 System.out.println("message + square ="+msg+ " "+x); 11 hs=(HelloInterface)Naming.lookup("/remote2"); 12 msg=hs.sayHello(); 13 System.out.println("message ="+msg); 14 }catch(Exception e) 15 { System.out.println(e); 16 } 17 } 18 } HelloClient2.java: Code for client that uses the remote object (another version). 1 import java.rmi.*; 2 public class HelloClient1 3 { public static void main(String args[]) 4 { String msg=""; 5 try 6 { HelloInterface hs=(HelloInterface) Naming.lookup("rmi://192.168.1.49:2000/remote1"); 7 msg=hs.sayHello(); 8 hs.add(10,20); 9 int x=hs.square(20); 10 System.out.println("message + square ="+msg+ " "+x); 11 hs=(HelloInterface) LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com  RMI (Remote Method Invocation) Naming.lookup("rmi://192.168.1.49:2000/remote2"); 12 msg=hs.sayHello(); 13 System.out.println("message ="+msg); 14 }catch(Exception e) 15 { System.out.println(e); 16 } 17 } 18 } 4.5 Generating Stubs and Skeletons Now that we have the remote interface and implementation, we can generate the skeletons and stubs (or only stubs in java 1.2 or higher version) with the rmic tool after we have compiled the classes. Remember to set the directory that you are working from in your classpath; you can then use the following line in a command window: rmic -v1.2 HelloServer This will generate stub class “HelloServer_Stub.class”. Note: It is worth keeping in mind that while starting the registry all classes and stubs must be available in the classpath or the classpath should not be set at all, to support dynamic loading. 4.6 Running the RMI Registry, Client and the Server The steps for running the RMI application are: 1. Start RMI Registry: Ensure that the following classes are present in the current folder or the classpath: HelloInterface.class HelloServer_Stub.class Start the RMI Registry by giving the command: rmiregistry 2. Start Server: Ensure that the following classes are in the current folder or the classpath: HelloInterface.class HelloServer.class HelloServer_Stub.class MyRMI.class Run the MyRMI program. 3. Run Client: Ensure that the following classes are in the current folder or the classpath: HelloInterface.class HelloServer_Stub.class HelloClient.class Run the HelloClient program. LogicPace Technologies Private Limited 68/27, Pratap Nagar, Sanganer, Jaipur. Phone :+91 1412791433, 9414248794 Email: [email protected] WebSite: www.logicpace.com