1 Java RMI G53ACC Chris Greenhalgh

2 Contents l Java RMI overview l A Java RMI example –Overview –Walk-through l Implementation notes –Argument passing –File requirements l RPC issues and RMI l Other problems with RMI See also RMI tutorial, Farley p.71-83

3 Java RMI l Distributed Object System –Allows objects in one process to invoke methods on objects in another process. l Supports bind/find/execute service-oriented interaction –RMI registry is naming service l Java-specific l Optional CORBA interoperability

4 Java RMI system elements l RMI infrastructure = base classes and interfaces: –provides communication and naming. l RMI compiler: –generates client stubs, to translate client requests to standard form. –generates (optional) server stub (“skeleton”) to translate standard form to server implementation form.

5 Building an example distributed application l A “ticket” issuing service –E.g. next customer to be served, or first-come- first served –Managed resource = next ticket number l Centralised to control allocation, e.g. ensure no duplicates l Client: –Locates server –Requests the next ticket –Prints it on the screen

6 Example application processes/machines TicketServer object Process/Application B Client object Process/Application A RMI objects and classes Remote Method Invocations (over TCP/IP connections) RMI registry Server machine Client stub Find Bind Use Client machine

7 1. Specify the common interface l Define the interface as a Java interface –Like a normal local interface l Set of methods with name, arguments, return type and exceptions l But… –must extend java.rmi.Remote interface l Hint to marshalling code –all methods throw java.rmi.RemoteException l NOTE: unavoidable complications - network-related errors (e.g. server unavailable or unreachable, timed out) –All types must be primitive ( int etc.), implement java.io.Serializable or implement java.rmi.Remote

8 Example interface import java.rmi.*; public interface TicketServer extends Remote { public int getNextTicket (String name) throws RemoteException; }

9 Notes on defining the interface l What distinct requests can a client make? –Each request = 1 method l How can each request by concisely described? –= method name l What information does the client have that the server needs to perform the request? –= arguments – types and names l What might be anticipated to go wrong? –= exceptions l If it works, what information does the client need back? –= return type

10 2. Implement the service l Implement the service as a Java class –extend java.rmi.server.UnicastRemoteObject l Inherits server support, networking, etc. –Implement the define interface and its method l The “business logic” –(Typically) Implement a main method to: l Create a new instance of the server l Register (bind) this with the naming service (rmiregistry) so that clients can find it

11 Example server implementation –import java.rmi.*; import java.rmi.server.UnicastRemoteObject; public class TicketServerImpl extends UnicastRemoteObject implements TicketServer { // cons throws RemoteException TicketServerImpl() throws RemoteException { }; // cont…

12 – // service state/resource int nextTicket=0; // business logic - implementation public int getNextTicket(String name) throws RemoteException { return nextTicket++; } // cont…

13 – // app – start server public static void main(String [] args) { // install RMI security manager System.setSecurityManager (new RMISecurityManager()); try { String name = args[0]; //create new instance TicketServerImpl server = new TicketServerImpl(); // register with nameserver Naming.rebind(name, server); } catch(Exception e) { // errors... } } –}//end

14 3. Implement client l Client –installs appropriate security manager (and security policy) for client stubs –looks up server in name service like URL: “ rmi://machine:port/name ” like URL: “ rmi://machine:port/name ” defaults are “ rmi://localhost:1099/ ” defaults are “ rmi://localhost:1099/ ” “ localhost ” = “this machine” “ localhost ” = “this machine” –obtains handle (client stub) which implements interface –performs remote operations –Handles errors (exceptions)

15 l import java.rmi.*; public class TicketClient { public static void main(String [] args) { // install RMI security manager System.setSecurityManager (new RMISecurityManager()); try { // look up in nameserver String fullname = args[0]; TicketServer server = (TicketServer)Naming.lookup(fullname); // cont…

16 l // get ticket - remote method! int ticket = server. getNextTicket("TicketClient"); System.out.println("Got ticket "+ ticket); } catch (Exception e) { /* error… */ } } }

17 4. Compile & Generate stubs l Compile server implementation (javac) and process with RMI compiler (rmic) –generates client stub class l (TicketServerImpl_Stub.class) l Required by client (only) –generates server stub (skeleton) class l Optionally required by server (only) (if not using reflection-based despatcher - see RPC notes) –See RMI Tutorial for details, e.g. command line options

18 5. Run the server Run naming service (rmiregistry): rmiregistry [ ] Run naming service (rmiregistry): rmiregistry [ ] –Must be on the same machine as the server l Run server application, which –creates a server object instance and –registers with naming service l See Tutorial for command line options –E.g. security policy file

19 6. Run the client l Run client which –Looks up the server in the specified registry –Invokes operations on the server… l See Tutorial for command line options

20 Argument Passing in Java RMI (i) l All arguments must be one of: –basic types l Serialised, passed by value l E.g. int, long, short, byte, char, boolean, float, double –implement java.io.Serializable l serialised, passed by value l i.e. an identical copy of the object is made at the other end l Exact class must be found remotely l operations will be local to each copy

21 Serializable example E.g. java.lang.String, or your own custom classes E.g. java.lang.String, or your own custom classes –E.g. public class MyPersonClass implements java.io.Serializable { public String firstName; public String lastName; public int ageYears; public MyPersonClass children[]; // sample (local) method public int getAge() { return ageYears; } }

22 Argument Passing in Java RMI (ii) l or: –implement java.rmi.Remote l be passed as a network reference l i.e. a network handle (copy of a client proxy object) is serialised and sent, not the object data itself l client stub class must be located by receiving process l operations on the received proxy object will themselves be remote –i.e. forwarded to the original object –e.g. “callbacks”

23 Unmarshalling serialized objects l For Serializable objects and stubs of Remote objects the receiving process JVM needs to find the same class (class file) –Could already be present at receiving end, in class path –Can be downloaded from a remote web server via HTTP server is run with java.rmi.server.codebase property pointing to webserver URL where class files are put server is run with java.rmi.server.codebase property pointing to webserver URL where class files are put l Value is included in marshalled information l Used by receiving process IF ALLOWED –This is why RMI security manager is installed

24 Which files, where? l Client needs: –Client implementation l (must be local) –Interface l And any Serializable classes it uses l (must be local if directly used in the client implementation code) –Client stub l (can be downloaded since not directly referenced in client implementation class)

25 l Server needs: –Server implementation l (must be local) –Interface l And any Serializable classes it uses l (must be local since server implements the interface and methods) –Server skeleton l (if used, must be local) –Client stub (to send to registry)

26 l Rmiregistry needs: –Interface l And any Serializable classes it uses –Client stub l (can all be downloaded since the registry code does not explicitly refer to any of these classes)

27 RPC issues in RMI (ii) l Transparency –Pretty good – normal Java interface –But implements Remote and methods throw RemoteExceptions –Also no (easy) way to identify client or link client requests in “sessions”…

28 Client/session tracking in RMI interfaces l Client is not identified to server code –No automatic link between successive calls by the same client (cf. “sessions”) l Not like using TCP or UDP directly –Implications for security, e.g. when authentication must be done (each method) l Options: –Explicit client identification per message l From client, e.g. user id, or l Returned by initial server operation (cf. “login”/”start”)  session id –Client-specific server returned by initial server operation (second interface, server object & stub)

29 RPC issues in RMI (ii) l Heterogeneity –Java is cross platform :-) –Java is not cross language… –However additional tool and runtime support allows l RMI interfaces to be translated to CORBA IDL interfaces and l RMI to use CORBA IIOP protocol l Allowing interoperability with any CORBA client/server

30 RPC issues in RMI (iii) l Concurrency –Client requests are always blocking l Needed to link RemoteException to call context –Server threads are provided by server runtime l Pool of despatcher threads l Server can handle multiple remote requests concurrently l Binding –Distributed object model, supported by rmiregistry and Remote arguments –See naming notes

31 Problems with RMI l Problems with class versioning (e.g. in the rmiregistry) –May not unload old versions of classes if interfaces are changed l No asynchronous invocations l No reply-less invocations (c.f. CORBA ‘oneway’) l => Blocking invocations –Failure of server can take 30s to several minutes to detect! –May need extra worker threads to ‘push’ invocations