Overview of RMI Architecture
In distributed application architecture, it is always a need for communication between two different applications. In Java-based applications, one application communicates with another remote/different application running somewhere else by using a mechanism called RMI architecture.
RMI stands for Remote Method Invocation. It is an API provided by java which allows an object residing in one JVM (Java Virtual Machine) to access or invoke an object running on another JVM. The other JVM could be on the same machine or remote machine. This is an interesting feature because in real time applications it becomes very easy for Java applications to communicate directly with each other without any external communication mechanism. Also, it is always a need for secure communication between applications based on distributed application architecture.
Before we go into detailed architecture, we will understand the basic design of RMI architecture.
- RMI API is provided in the package java.rmi. Let’s introduce two terms for the understanding of RMI design architecture. First is the client; the JVM that will call remote object and second is server; the JVM that contains the remote object. So, the client will call the server, in this case on the object for method invocation.
- The server will then return the reference of the object to the client. The catch here is both the objects i.e. local and remote will appear as a local object on the server. There will be no differentiation between the two. The syntax of the methods of both objects is also the same. Therefore, the server JVM acts like normal JVM without knowing of any object whether it is local or remote.
- The same object can be both a server and a client. The remote objects reference is obtained, and it is used as if it was a local object. The RMI infrastructure is responsible for finding the remote object, intercepting method call and processing the remote request remotely. The client invokes methods on the object only after obtaining a reference to a remote object.
Below is the diagram of RMI architecture in a simple way. On the internet, you will find various forms of the same architecture, but we have a simple one which will help to explain it better.
Let’s start by connecting dots from a design perspective with an architecture diagram.
The client application and server application are the respective JVMs of the client machine and server machine. In RMI application we write two programs respectively; the client program which resides on the client and server program which resides on the server machine.
This layer is the actual systems i.e. client and server which are involved in communication. The java program on the client side communicates with the java program on the server-side.
From design intro, we have client objects; In RMI architecture it is known as Stub. It is an object that resides on the client machine and it acts as a proxy for the remote object. It is like a gateway for the client program.
The stub has the same methods as a remote object. When the client calls on the stub object, the stub forwards this request to a remote object (Skeleton) via RMI infrastructure which is then executed on the server.
Stub Performs the following events:-
- Initiates connection with remote JVM,
- Writes and transmits (Marshals) parameters to remote JVM,
- Waits for the result,
- Reads (Unmarshalls) the returned result,
- Pass the received result to the caller.
The server object which resides in a server machine is known as Skeleton. Stub communicates with server application with the help of an intermediate Skeleton object.
The responsibility of the skeleton object is to send parameters to method implementation and send the return values back to the client.
Skeleton Performs the following events:-
- Reads the parameter passed by the client,
- Invokes the method on actual Remote object,
- Transmit/pass the result to the caller.
Stub / Skeleton layer
- The Stub/Skeleton layer is responsible for intercepting calls made by the client and redirecting these calls to the remote object. This layer is also called as Proxy Layer. Stub and Skeleton are the proxies for client and server. The Stub and Skeleton objects are like an interface between an application and the rest of the RMI System.
- This layer’s purpose is to transfer data to Remote Reference Layer by Object Serialization. This process of converting data/object into byte stream is known as Marshalling and the reverse is known as Unmarshalling. Marshaling is performed when requesting the object from the server and Unmarshalling is performed when data/object reference is received from the server.
Remote Reference Layer
- The proxy layer is connected to the RMI mechanism through Remote Reference Layer. This layer is responsible for communication and transfer of objects between client and server. The invocation semantics of the RMI connection is defined and supported by this layer.
- Remote Reference Layer is responsible to maintain the session during the method call. i.e. It manages the references made by the client to the remote server object. This layer is also responsible for handling duplicated objects.
The transport layer is responsible for setting up communication between the two machines. This layer uses standard TCP/IP protocol for connection. The actual transportation of data is performed through this layer. This layer is part of Remote Reference Layer.
- The Remote Method Invocation (RMI) is a very useful API provided in JAVA which helps in communication between two different JVMs. It allows an object to invoke a method on an object residing in another address space.
- It provides a secure way for applications to communicate with each other. It achieves this functionality by the means of concepts Stub (Client calling object) and Skeleton (Remote object residing on the server).
- RMI is used to build distributed applications. It preserves the type of safety. RMI architecture minimizes the complexity of the application in a distributed architecture.
This has been a guide to RMI Architecture. Here we discuss RMI design and the architecture in detail with an appropriate block diagram. You can also go through our other suggested articles to learn more –