W. H. CARLISLE AUBURN UNIVERSITY COMPUTER SCIENCE AND ENGINEERING

1. Remote Method Invocation (RMI) W. H. CARLISLE AUBURN UNIVERSITY COMPUTER SCIENCE AND ENGINEERING

2. Remote Method Invocation (RMI) RMI is a powerful technology for developing distributed applications without worrying about the networking details A server defines the objects that clients can use Client invoke methods of a remote object exactly as if they were a part of the client program.

3. Remote Method Invocation (RMI) RMI is built on top of Sockets The actual communication on sockets makes use of I/O streams to read and write the data.

4. Client/Server model • Client/Server Architecture is a two tier model • presentation (client) • processing/storage (server) • insufficient to support RMI

5. Three Tier Model • Three software tiers support RMI • presentation (client) • processing/storage (server) • object resource broker (middle tier)

6. Remote Procedure call Remote Procedure call is the most successful alternative to the client/server architecture. RPC organizes messages an application can send/receive in the form of functions. The content of each message is an argument to a function call and the reply is the function value A stub compiler is used to glue client and code with software that does argument marshalling (streaming) and unmarshalling (restoring from stream)

7. Sun success built on RPC • Sun’s NFS is built on RPC. • Three software tiers support RPC • presentation (client) - makes procedure calls • processing/storage (server) - implements the call • broker (middle tier) - understands which procedures • are served by which servers.

8. Migrate RPC intoObject World • RMI is analogous to RPC for objects and methods • Proxy objects support a remote interface and provide the physical connection and communication • RMI architecture has: • stubs/skeletons • (clients side stubs and server side skeletons) • Remote reference layer • ( invocation to a single or replicated object) • Transport layer • (connection setup/management ;remote object tracking)

9. Migrate RPC intoObject World Remote objects already existed for C++ with the CORBA consortium (Common Object Resource Broker Architecture) Natural to include an RMI capability in Java. PROBLEM: politics - Sun was member of CORBA consortium and RMI was not CORBA compliant usefulness - with a CORBA design, C++ clients could use Java Objects

10. Migrate RPC intoObject World PROBLEMS Continued: performance - Early studies showed CORBA outperformed RMI.

11. Is RMI Dead? With Java 1.2 Sun Microsystems introduced a CORBA compliant Object Resource Broker (ORB) into the toolkit. However Sun lags behind Visigenic (Borland) and other third party companies in the CORBA Java/C++ distributed platform. (I mention Visigenic only because Netscape makes their ORB a part of their package).

12. Is CORBA Dead? Once upon a time there was a giant who sat at a table and after eating would regurgitate some food for others around the table. “This is not good food”, most said, but others pointed out that “the regurgitated food was not poisoned because it did not kill the giant”. Occasionally there would be food at the far end of the table that the giant was not eating. Some would try it, find it good, and this would begin a rush to eat this food. Unfortunately the giant would notice, reach over and begin consuming this food. This would again leave nothing very good for those crowding the table.

13. BUT Giants, Languages or Tool-sets aside: Total agreement that distributed object computing is the next wave to ride.

14. Distributed Object Computing • uses objects on different machines • allows callbacks from servers to applets • makes writing of reliable distributed applications simple • above are transparent to the client.

15. Important With RMI the client/server terminology applies only to a single message to an object. The computer running the Java code that sends a message to a remote object may be the server to a Java program on another machine.

16. Developing an RMI application A local surrogate (stub) object manages invocation of a remote object. Whereas CORBA presumes a heterogeneous multi-language environment and has a language neutral object model, RMI can assume the homogeneous environment of the JVM on client and server. Thus a single Java interface class can serve as a definition of the object to be exported and can be used to generate the stub for the remote object.

17. Step 1: Create the Interface • Create an interface class that extends java.rmi.Remote • import java.rmi.*; • public interface Intf extends Remote { • public String hello() throws RemoteException; • } • Compile the interface

18. Interfaces • Heart of RMI it the remote interface • A remote interface is an interface that extends • java.rmi.Remote • All methods of a remote interface must include • java.rmi.RemoteException in their throws list.

19. Interfaces • Method arguments and return values are • primitive: a value is passed • reference to local object: an object copy is passed using serialization • reference to a remote object: a serialized remote reference is passed. • A local reference to a remote object is actually a reference to a stub object.

20. Step 2: Implement the Interface • Programmer writes a class that extends java.rmi.server.UnicastRemoteObject and implements the interface. • import java.rmi.*; • import java.rmi.server.UnicastRemoteObject; • public class Server extends UnicastRemoteObject implements Intf { • public Server() throws RemoteException { super() }; //constructor • synchronized public String hello() throws RemoteException { return “Hello”; } //implements interface

21. Step 2: continued • The main creates an instance and records it with the middleware naming service. • public static void main(String args[]) { try { Server v = new Server(); //create the object; Naming.rebind( ”//church.eng.auburn.edu/HelloServer",v); } catch(Exception e) { System.out.println("Server: "+ e.getMessage()); e.printStackTrace(); } } }

22. RMI Registry • Currently RMI uses a simple remote object registry (name server) rmiregistry <port> //default 1099 • Access to the naming services of this registry is provided in the class java.rmi.Naming • Currently rmiregistry is remotely accessible by a URL string rmi://host:port/name but applications can bind or unbind only in the registry running on the same host. • To register a server use void Naming.bind(String,Remote) void Naming.rebind(String,remote) • To obtain a server reference use Remote Naming.lookup(String)

23. Step 3: Generate client stub • The utility rmic is used to generate a stub for the client and the skeleton code used by the remote object. • When the client sends a message to an object, it is a method of the stub that is called. The stub does the necessary networking to pass the call to the skeleton on the client side. • The skeleton translates the request to a method invocation on the servers object, gets the result and passes it back to the stub on the skeleton side. • The stub returns this information to the client.

24. Step 3: Continued • rmic Servercreates and compiles two new classes with suffixes _Stub and _Skel • Currently, the server machine must run a program that listens to a port and knows about the services offered. • Start this registry server with the rmiregistry command. • Now you can run the Server program and your machine is offering the object for clients to use.

25. Step 4: Writing a Client. • The client program defines a variable of the interface and then uses the naming service to get an instance of the object from the server. (Really an instance of the stub) • public class Client { static public void main(String arg[]) { try { Intf object = (Intf)Naming.lookup( “//church.eng.auburn.edu/HelloServer”); • System.out.println(object.hello()); • } catch (Exception e) { System.out.println(e.message()); e.printStackTrace();} }}

26. Intf.java import java.rmi.*; public interface Intf extends Remote { public String hello() throws RemoteException; }

27. Server.java import java.rmi.*; import java.rmi.server.UnicastRemoteObject; public class Server extends UnicastRemoteObject implements Intf { public Server() throws RemoteException { super();} synchronized public String hello() throws RemoteException {return "Hello"; } public static void main(String args[]) { try { Server v = new Server(); //create the object; Naming.rebind( "//church.eng.auburn.edu/HelloServer",v); } catch(Exception e) { System.out.println("Server: "+ e.getMessage()); e.printStackTrace(); }}}

28. Client.java import java.rmi.*; public class Client { static public void main(String arg[]) { try { Intf s = (Intf)Naming.lookup( "//church.eng.auburn.edu/HelloServer"); System.out.println( s.hello()); } catch(Exception e){ System.out.println(e.getMessage()); e.printStackTrace();} }}

29. Remote garbage • When a remotely accessible object (via a skeleton) is • exported from a from a server, a stub is serialized to • the client, and the stub’s host is added to the skeletons • reference set. • When the stub is garbage collected in a VM an • unreferenced message is sent back to the skeleton’s host. • The remote object will only be garbage collected when • there are no local or remote references for the object.