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

2. Outline Introduction to RMI RMI architecture RMI naming service
Dr M. E. AYDIN / Dr M. CONRAD

3. Introduction to RMI

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

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

6. 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.
Dr M. E. AYDIN / Dr M. CONRAD

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

8. RMI Introduction
Dr M. E. AYDIN / Dr M. CONRAD

9. 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.
Dr M. E. AYDIN / Dr M. CONRAD

10. 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?
Dr M. E. AYDIN / Dr M. CONRAD

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

12. RMI Introduction
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.
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

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

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

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

16. 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
Dr M. E. AYDIN / Dr M. CONRAD

17. 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.
Dr M. E. AYDIN / Dr M. CONRAD

18. 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.
Dr M. E. AYDIN / Dr M. CONRAD

19. RMI Introduction Disadvantages?
Concurrent Processing: RMI is multi-threaded, allowing your servers to exploit Java threads for better concurrent processing of client requests.
Disadvantages?
Dr M. E. AYDIN / Dr M. CONRAD

20. Java RMI Architecture
Dr M. E. AYDIN / Dr M. CONRAD

21. 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
Dr M. E. AYDIN / Dr M. CONRAD

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

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

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

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

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

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

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

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

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

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

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

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

34. Stub and Skeleton Layer
In RMI's use of the Proxy pattern, the stub class plays the role of the proxy, and the remote service implementation class plays the role of the RealSubject.
A skeleton is a helper class that is generated for RMI to use. The skeleton understands how to communicate with the stub across the RMI link. The skeleton carries on a conversation 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 the Java 2 SDK implementation of RMI, the new wire protocol has made skeleton classes obsolete. You only have to worry about skeleton classes in JDK 1.1.
Dr M. E. AYDIN / Dr M. CONRAD

35. 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.
The JDK 1.1 implementation of RMI provides only one way for clients to connect to remote service implementations: a unicast, point-to-point connection.
Dr M. E. AYDIN / Dr M. CONRAD

36. 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.
Before a client can use a remote service, the remote service must be instantiated on the server and exported to the RMI system. (If it is the primary service, it must also be named and registered in the RMI Registry).
Dr M. E. AYDIN / Dr M. CONRAD

37. Transport Layer
The Transport Layer makes the connection between JVMs. All connections are stream-based network connections that use TCP/IP.
In the current release of RMI, TCP/IP connections are used as the foundation for all machine-to-machine connections.
As you know, TCP/IP provides a persistent, stream-based connection between two machines based on an IP address and port number at each end.
Notice: Even if two JVMs are running on the same physical computer, they connect through their host computer's TCP/IP network protocol stack.
This is why you must have an operational TCP/IP configuration on your computer to run an RMI system.
Dr M. E. AYDIN / Dr M. CONRAD

38. Transport Layer

39. 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 JDK 1.1 version of RMI required the use of Skeleton classes on the server.
The Java 2 SDK version has been optimised for performance and does not require skeleton classes.
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.

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

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

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

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

44. Naming Remote Objects