Java Remote Method Invocation (RMI) CIS007-3 Comparative Integrated Systems Java Remote Method Invocation (RMI) Dr Marc Conrad Sue Brandreth

Outline Introduction to RMI RMI architecture RMI naming service

Introduction to RMI

The Network is the Computer Consider the following program organisation: If the network is the computer, we ought to be able to put the two classes on different computers RMI is ONE technology that makes this possible computer 1 computer 2 SomeClass AnotherClass method call returned object

RMI Introduction RMI stands for Java Remote Method Invocation, RMI allows you to write distributed objects using Java. At the most basic level, RMI is Java's remote procedure call (RPC) mechanism. Traditional RPC systems (Corba, DCOM) are language-neutral, and therefore are essentially least- common-denominator systems. They cannot provide functionality that is not available on all possible target platforms. Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction RMI is focused on Java, with connectivity to existing systems using native methods. This means RMI can take a natural, direct, and fully-powered approach to provide a distributed computing technology that lets you add Java functionality throughout your system in an incremental, yet seamless way. RMI provides a simple model for distributed computing with Java objects. These objects can be new Java objects, or can be simple Java ‘wrappers’ around an existing API. Because RMI is centred around Java, it brings the power of Java safety and portability to distributed computing. Dr M. E. AYDIN / Dr M. CONRAD

RMI and other technologies CORBA (Common Object Request Broker Architecture) has long been king CORBA supports object transmission between virtually any languages Objects have to be described in IDL (Interface Definition Language), which looks a lot like C++ data definitions CORBA is complex and flaky Microsoft supported CORBA, then COM, now .NET RMI is purely Java-specific Java to Java communications only As a result, RMI is much simpler than CORBA

RMI Basics RMI is the Java Distributed Object Model for facilitating communications among distributed objects. RMI is a higher-level API built on top of sockets. Socket-level programming allows you to pass data through sockets among computers. RMI enables you not only to pass data among objects on different systems, but also to invoke methods in a remote object.

The Differences between RMI and RPC RMI is similar to Remote Procedure Calls (RPC) in the sense that both RMI and RPC enable you to invoke methods, but there are some important differences. With RPC, you call a standalone procedure. With RMI, you invoke a method within a specific object. RMI can be viewed as object-oriented RPC.

The Differences between RMI and Traditional Client/Server Approach A RMI component can act as both a client and a server, depending on the scenario in question. A RMI system can pass functionality from a server to a client and vice versa. A client/server system typically only passes data back and fourth between server and client.

How does RMI work? A subinterface of java.rmi.Remote that defines the methods for the server object. An object that resides on the server host, communicates with the stub and the actual server object. An object that resides on the client host and serves as a surrogate for the remote server object. A program that invokes the methods in the remote server object. An instance of the server object interface. A utility that registers remote objects and provides naming services for locating objects. RMI works as follows: A server object is registered with the RMI registry; A client looks through the RMI registry for the remote object; Once the remote object is located, its stub is returned in the client; The remote object can be used in the same way as a local object. The communication between the client and the server is handled through the stub and skeleton.

Passing Parameters When a client invokes a remote method with parameters, passing parameters are handled under the cover by the stub and the skeleton.

RMI and other technologies Java makes RMI (Remote Method Invocation) fairly easy, but there are some extra steps To send a message to a remote “server object,” The “client object” has to find the object Do this by looking it up in a registry The client object then has to marshal the parameters (prepare them for transmission) Java requires Serializable parameters The server object has to unmarshal its parameters, do its computation, and marshal its response The client object has to unmarshal the response

Terminology A remote object is an object on another computer The client object is the object making the request (sending a message to the other object) The server object is the object receiving the request As usual, “client” and “server” can easily trade roles (each can make requests of the other) The rmiregistry is a special server that looks up objects by name Hopefully, the name is unique! rmic is a special compiler for creating stub (client) and skeleton (server) classes

Processes For RMI, you need to be running three processes The Client The Server The Object Registry, rmiregistry, which is like a DNS service for objects You also need TCP/IP active

Interfaces Interfaces define behavior Classes define implementation Therefore, In order to use a remote object, the client must know its behavior (interface), but does not need to know its implementation (class) In order to provide an object, the server must know both its interface (behavior) and its class (implementation) In short, The interface must be available to both client and server The class should only be on the server

Remote Interfaces and Classes A Remote class has two parts: The interface (used by both client and server): Must be public Must extend the interface java.rmi.Remote Every method in the interface must declare that it throws java.rmi.RemoteException (other exceptions may also be thrown) The class itself (used only by the server): Must implement a Remote interface Should extend java.rmi.server.UnicastRemoteObject May have locally accessible methods that are not in its Remote interface

Security It isn’t safe for the client to use somebody else’s code on some random server Your client program should use a more conservative security manager than the default System.setSecurityManager(new RMISecurityManager()); Most discussions of RMI assume you should do this on both the client and the server Unless your server also acts as a client, it isn’t really necessary on the server

The Server Class The class that defines the server object should extend UnicastRemoteObject This makes a connection with exactly one other computer If you must extend some other class, you can use exportObject() instead Sun does not provide a MulticastRemoteObject class The server class needs to register its server object: String url = "rmi://" + host + ":" + port + "/" + objectName; The default port is 1099 Naming.rebind(url, object); Every remotely available method must throw a RemoteException (because connections can fail) Every remotely available method should be synchronized

Hello World server: Interface import java.rmi.*; public interface HelloInterface extends Remote { public String say() throws RemoteException; }

Hello World server: Class import java.rmi.*; import java.rmi.server.*; public class Hello extends UnicastRemoteObject implements HelloInterface { private String message; // Strings are serializable public Hello (String msg) throws RemoteException { message = msg; } public String say() throws RemoteException { return message; } }

Registering the Hello World server class HelloServer { public static void main (String[] argv) { try { Naming.rebind("rmi://localhost/HelloServer", new Hello("Hello, world!")); System.out.println("Hello Server is ready."); } catch (Exception e) { System.out.println("Hello Server failed: " + e); } } }

The Hello World client program class HelloClient { public static void main (String[] args) { HelloInterface hello; String name = "rmi://localhost/HelloServer"; try { hello = (HelloInterface)Naming.lookup(name); System.out.println(hello.say()); } catch (Exception e) { System.out.println("HelloClient exception: " + e); } } }

rmic The class that implements the remote object should be compiled as usual Then, it should be compiled with rmic: rmic Hello This will generate the file Hello_Stub.class The “Stub” class must be copied to the client area

Trying RMI In three different terminal windows: rmiregistry Run the registry program: rmiregistry Run the server program: java HelloServer Run the client program: java HelloClient If all goes well, you should get the “Hello, World!” message

Using RMI A working RMI system is composed of several parts. Interface definitions for the remote services Implementations of the remote services Stub and Skeleton files A server to host the remote services An RMI Naming service that allows clients to find the remote services (A class file provider (an HTTP or FTP server) ) A client program that needs the remote services

Using RMI You take the following steps to build a system: Write and compile Java code for interfaces Write and compile Java code for implementation classes Generate Stub and Skeleton class files from the implementation classes Write Java code for a remote service host program Develop Java code for RMI client program Install and run RMI system

RMI Introduction RMI has several advantages over traditional RPC systems. Object Oriented: RMI can pass full objects as arguments and return values, not just predefined data types. This means that you can pass complex types as a single argument. You don’t have to have the client decompose an object into primitive data types (as in existing RPC systems), ship those data types, and then recreate on the server. RMI lets you ship objects directly across the wire with no extra client code.

RMI Introduction Mobile Behaviour: RMI can move behaviour (class implementations) from client to server and server to client. For example, you can define an interface for examining employee expense reports to see whether they conform to current company policy. When an expense report is created, an object that implements that interface can be fetched by the client from the server. When the policies change, the server will start returning a different implementation of that interface that uses the new policies. The constraints will therefore be checked on the client side - providing faster feedback to the user and less load on the server - without installing any new software on user's system. This gives you maximal flexibility. Changing policies requires you to write only one new Java class and install it once on the server host. Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction

RMI Introduction A client displays a GUI (graphical user interface) to a user, who fills in the fields of the expense report. Clients communicate with the server using RMI. The server stores the expense reports in a database using JDBC. So far this may look like any multi-tier system, but there is an important difference-RMI can download behaviour.

RMI Introduction Suppose that the company's policies about expense reports change. For example, today the company requires receipts only for expenses over £20. Tomorrow the company decides this is too lenient. It wants receipts for everything, except for meals that cost less than £20. Without the ability to download behaviour, what alternatives are there for designing your system for change?

RMI Introduction With RMI you can have the client upload behaviour from the server with a simple method invocation, providing a flexible way to offload computation from the server to the clients while providing users with faster feedback. When a user is ready to write up a new expense report, the client asks the server for an object that embodies the current policies for expense reports as expressed via a Policy interface written in Java. Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction If this is the first time that the client's RMI runtime has seen this particular implementation of the policy, RMI will ask the server for a copy of the implementation. This means that policy is always dynamic. You can change the policy by simply writing a new implementation of the general Policy interface, installing it on the server, and configuring the server to return objects of this new type. From that point on, any new expense reports will be checked against the new policy by every client. Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction This is a better approach than any static approach because: All clients don't need to be halted and updated with new software-software is updated on the fly as needed. The server is not burdened with entry checking that can be done locally. Allows dynamic constraints because object implementations, not just data, are passed between client and server. Lets users know immediately about errors. Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction Design Patterns: Passing objects lets you use the full power of object oriented technology in distributed computing - such as two- and three-tier systems. When you can pass behaviour, you can use object oriented design patterns in your solutions. All object oriented design patterns rely upon different behaviours for their power Without passing complete objects - both implementations and type - the benefits provided by the design patterns movement are lost. Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction Safe and Secure: RMI uses built-in Java security mechanisms that allow your system to be safe when users downloading implementations. RMI uses the security manager defined to protect systems from hostile applets to protect your systems and network from potentially malicious downloaded code. In severe cases, a server can refuse to download any implementations at all. Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction Easy to Write/Easy to Use: RMI makes it simple to write remote Java servers and Java clients that access those servers. A remote interface is an actual Java interface. A server has roughly three lines of code to declare itself a server, and otherwise is like any other Java object. This simplicity makes it easy to write servers for full-scale distributed object systems quickly, and to rapidly bring up prototypes and early versions of software for testing and evaluation. And because RMI programs are easy to write they are also easy to maintain. Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction Connects to Existing/Legacy Systems: RMI interacts with existing systems (other platforms/programming languages) through Java's native method interface JNI. Using RMI and JNI you can write your client in Java and use your existing server implementation. When you use RMI/JNI to connect to existing servers you can rewrite any parts of you server in Java when you choose to, and get the full benefits of Java in the new code. Similarly, RMI interacts with existing relational databases using JDBC without modifying existing non-Java source that uses the databases. JNI = Java Native Interface (JNI) is a standard programming interface for writing Java native methods and embedding the Java virtual machine into native applications. The primary goal is binary compatibility of native method libraries across all Java virtual machine implementations on a given platform. See http://docs.oracle.com/javase/7/docs/technotes/guides/jni/ Dr M. E. AYDIN / Dr M. CONRAD

RMI Introduction Write Once, Run Anywhere: RMI is part of Java's "Write Once, Run Anywhere" approach. Any RMI based system is 100% portable to any Java Virtual Machine*, as is an RMI/JDBC system. If you use RMI/JNI to interact with an existing system, the code written using JNI will compile and run with any Java virtual machine.

RMI Introduction Distributed Garbage Collection: RMI uses its distributed garbage collection feature to collect remote server objects that are no longer referenced by any clients in the network. Analogous to garbage collection inside a Java Virtual Machine, distributed garbage collection lets you define server objects as needed, knowing that they will be removed when they no longer need to be accessible by clients.

RMI Introduction Disadvantages? Concurrent Processing: RMI is multi-threaded, allowing your servers to exploit Java threads for better concurrent processing of client requests. Disadvantages?

Java RMI Architecture

The Design Goal for the RMI Architecture The primary goal for the RMI designers was to allow programmers to develop distributed Java programs with the same syntax and semantics used for non- distributed programs. Therefore, they had to make the Java distributed object model integrate naturally into the Java programming language and the local object model, to make the use of distributed Java objects similar to using local Java objects

The Design Goal for the RMI Architecture To do this, they had to carefully map how Java classes and objects work in a single Java Virtual Machine (JVM) to a new model of how classes and objects would work in a distributed (multiple JVM) computing environment. Dr M. E. AYDIN / Dr M. CONRAD

The Design Goal for the RMI Architecture RMI architects have succeeded; creating a system that extends the safety and robustness of the Java architecture to the distributed computing world. In the following slides, we will see how this is achieved. Dr M. E. AYDIN / Dr M. CONRAD

Interfaces: The Heart of RMI The RMI architecture is based on one important principle: The definition of behaviour and the implementation of that behaviour are separate concepts. RMI allows the code that defines the behaviour and the code that implements the behaviour to remain separate and to run on separate JVMs. This fits nicely with the needs of a distributed system where clients are concerned about the definition of a service and servers are focused on providing the service. Specifically, in RMI, the definition of a remote service is coded using a Java interface. The implementation of the remote service is coded in a class.

Interfaces: The Heart of RMI Therefore, the key to understand RMI is to remember that interfaces define behaviour and classes define implementation. The following diagram illustrates this separation, Dr M. E. AYDIN / Dr M. CONRAD

Interfaces: The Heart of RMI Remember that a Java interface does not contain executable code. RMI supports two classes that implement the same interface. The first class is the implementation of the behaviour, and it runs on the server. The second class acts as a proxy for the remote service and it runs on the client. Dr M. E. AYDIN / Dr M. CONRAD

Interfaces: The Heart of RMI Dr M. E. AYDIN / Dr M. CONRAD

Interfaces: The Heart of RMI How RMI works? A client program makes method calls on the proxy object. RMI sends the request to the remote JVM, and forwards it to the implementation. Any return values provided by the implementation are sent back to the proxy and then to the client's program. This is similar to an RPC system Dr M. E. AYDIN / Dr M. CONRAD

RMI Architecture Layers - Diagram In the Java 2 SDK SE an additional stub protocol was introduced that eliminates the need for skeletons. Generic code is used to carry out the duties performed by skeletons. Stubs are generated by the rmic compiler.

RMI Architecture Layers The RMI implementation is essentially built from three abstraction layers. The first is the Stub and Skeleton layer, which lies just beneath the view of the developer. This layer intercepts method calls made by the client to the interface reference variable and redirects these calls to a remote RMI service. The next layer is the Remote Reference Layer. This layer understands how to interpret and manage references made from clients to the remote service objects. Dr M. E. AYDIN / Dr M. CONRAD

RMI Architecture Layers The transport layer is based on TCP/IP connections between machines in a network. It provides basic connectivity, as well as some firewall penetration strategies. What are the advantages to use a layered architecture? Dr M. E. AYDIN / Dr M. CONRAD

RMI Architecture Layers The transport layer is based on TCP/IP connections between machines in a network. It provides basic connectivity, as well as some firewall penetration strategies. What are the advantages to use a layered architecture? By using a layered architecture each of the layers could be enhanced or replaced without affecting the rest of the system. For example, the transport layer could be replaced by a UDP/IP layer without affecting the upper layers. Dr M. E. AYDIN / Dr M. CONRAD

Stub and Skeleton Layer The stub and skeleton layer of RMI lie just beneath the view of the Java developer. In this layer, RMI uses the Proxy design pattern in which an object in one context is represented by another (the proxy) in a separate context. The proxy knows how to forward method calls between the participating objects. Dr M. E. AYDIN / Dr M. CONRAD

Remote Reference Layer (RRL) The RRL defines and supports the invocation semantics of the RMI connection. This layer provides a RemoteRef object that represents the link to the remote service implementation object. The stub objects use the invoke() method in RemoteRef to forward the method call. The RemoteRef object understands the invocation semantics for remote services. Dr M. E. AYDIN / Dr M. CONRAD

Remote Reference Layer (RRL) Other types of connection semantics are possible. For example, with multicast, a single proxy could send a method request to multiple implementations simultaneously and accept the first reply (this improves response time and possibly improves availability). In the future, Sun may add additional invocation semantics to RMI. Dr M. E. AYDIN / Dr M. CONRAD

Transport Layer The Transport Layer makes the connection between JVMs. All connections are stream-based network connections that use TCP/IP. Dr M. E. AYDIN / Dr M. CONRAD

Transport Layer

Transport Layer On top of TCP/IP, RMI uses a wire level protocol called Java Remote Method Protocol (JRMP). JRMP is a proprietary, stream-based protocol that is only partially specified. In two versions: The version of RMI, called RMI-IIOP, was available with Java 2 SDK Version 1.3. Instead of using JRMP, it uses the OMG Internet Inter-ORB Protocol (IIOP), to communicate between clients and servers.

Naming Remote Objects How does a client find an RMI remote service? Clients find remote services by using a naming or directory service. A naming or directory service is run on a well-known host and port number. (Well-known meaning everyone in an organisation knowing what it is). RMI can use many different directory services, including the Java Naming and Directory Interface (JNDI). RMI itself includes a simple service called the RMI Registry, rmiregistry. The RMI Registry runs on each machine that hosts remote service objects and accepts queries for services, by default on port 1099.

Naming Remote Objects Server side: Client side: On a host machine, a server program creates a remote service by first creating a local object that implements that service. Next, it exports that object to RMI. When the object is exported, RMI creates a listening service that waits for clients to connect and request the service. After exporting, the server registers the object in the RMI Registry under a public name. Client side: The RMI Registry is accessed through the static class Naming.

Naming Remote Objects The Naming class provides the method lookup() that a client uses to query a registry. The method lookup( ) accepts a URL that specifies the server host name and the name of the desired service. The method returns a remote reference to the service object. The URL takes the form: rmi://<host_name>[:<name_service_port>]/<service_name> where the host_name is a name recognized on the local area network (LAN) or a DNS name on the Internet. The name_service_port only needs to be specified only if the naming service is running on a different port to the default 1099.

Naming Remote Objects The following illustration depicts an RMI distributed application that uses the RMI registry to obtain a reference to a remote object. The server calls the registry to associate (or bind) a name with a remote object. The client looks up the remote object by its name in the server's registry and then invokes a method on it. The illustration also shows that the RMI system uses an existing web server to load class definitions, from server to client and from client to server, for objects when needed.

Naming Remote Objects