1. INTRODUCTION
The network programs that we have developed so far use the concept of sockets. Although, socket provides a simple way to write network programs, it is neither very convenient nor the most powerful. This is because everything must be transferred over the network as a stream of bytes. Though, Java provides a rich set of interfaces and classes to accomplish this, writing a complex application using these facilities is undoubtedly not so easy.
Having realized this fact, in the later versions of Java, a new object-oriented version of networking (known as Remote Method Invocation) was incorporated. This technology elevates network programming to a higher plane. In this chapter, we shall explore how this mechanism can be used easily to develop sophisticated networking applications.
2. REMOTE METHOD INVOCATION
Java Remote Method Invocation (RMI) is an object-oriented Remote Procedure Call (RPC) technique. It allows us to invoke methods on an object that exists in a different address space. This address space may exist on the same computer or even on a different computer connected to the source computer by a network. So, it enables objects, distributed in different computers, to communicate with one another. Although it provides a simple but elegant model [Figure 14.1:], it is remarkably powerful and can be used to invoke remote methods easily and in a natural way.
Figure 14.1: RMI programming model
The underlying communication between clients and server in this model takes place seamlessly using sockets. It means that the message from the client is not method invocation in the OO sense. Instead, it is a stream of data that must be interpreted by the server before it can invoke method on the target object. However, RMI application developers need not know this complex socket communication. Originally, in general, RMI architecture was developed taking the following goals into consideration:
- A primary goal of Java RMI technology was to allow programmers to develop distributed Java programs with the same syntax and semantics used for non-distributed programs.
- Another goal was to create a distributed object model that fits the Java programming language and the local object model naturally. RMI architects finally succeeded in creating such a powerful system that extends the safety and robustness of the Java architecture to the distributed computing world.
2.1. Application components
Three entities are often involved [Figure 15.1:] in an RMI application: a server program, a client program and object registry.
Server
This is a program that typically creates a remote object to be used for method invocation. This object is an ordinary object except that its class implements a Java RMI interface. Upon creation, the object is exported and registered with a separate application called object registry (or simply registry).
Client
A client program typically consults the object registry to get a reference (handle) to a remote object with a specified name. It can then invoke methods on the remote object using this reference (handle) as if the object is stored in the client’s own address space. The RMI handles the details of communication (using sockets) between the client and the server and passes information back and forth. Note that this complex communication procedure is absolutely hidden to the client and server applications.
Object Registry
It is essentially a table of objects. Each entry of the table maps the object name to its proxy known as stub. The server registers the stub by a name to the object registry. Once the stub is registered to the object registry successfully, the object is said to be available for others’ use. Clients can now get a reference (handle) to the remote object (actually stub) from this registry and can invoke methods on it.
2.2. Basic Steps
Developing and running RMI applications involves the following steps:
- Define the remote interface
- Implement the remote interface
- Create, export and register a remote object in the server program
- Get a reference of the remote object in the client program
- Compile the Java source files
- Run the application
Define a remote interface
First, we define an interface that contains methods that the server wishes to publish. Since method invocations on remote object occurs in a very different way from local method invocation, an interface for the remote object must be declared as follows:
- The remote interface must be public.
- The remote interface extends (either directly or indirectly) the interface rmi.Remote. The interface Remote is a marker interface and has no methods.
public interface java.rmi.Remote {
}
A remote interface implements this Remote interface only to indicate that its methods may be invoked remotely.
- Each method in the interface must declare that it throws rmi.RemoteException. Note that remote objects may fail in a very different way from local objects. Therefore, every method exposes the additional exception RemoteException so that programmers can handle this failure appropriately.
Implement the remote interface
We then write a concrete class implementing one or more such remote interfaces. These classes may implement other interfaces or other methods may be added that can only be invoked locally. All classes that are used by these methods as parameters or return type must also be implemented. More than one implementation of the interface may be provided. Caller need not be aware of the underlying implementation.
Implement the server
Implementing a server application that creates an instance of the remote object and registers it to the RMI registry with a name is called object deployment. There are many ways to register an object to the RMI registry. We shall describe them separately later in this chapter.
Implement the client
A client application gets a handle to this remote object and invokes methods on it. There are different procedures to get a reference to the remote object. A detailed discussion can be found later in this chapter.
Compile them
Use Java compiler (javac) to compile all source files including interfaces and other subsidiary classes. To make the RMI technology work successfully, we should get help from the stub and the skeleton. Note that with Java versions before Java 5.0, programmers had to generate RMI stubs in a separate compilation step using rmic. Version 5.0 of Java and beyond no longer require this step. Anyway, the functions of stub and skeleton [see Figure 14.2:] are as follows:
- When a client invokes a remote method, a similar method call occurs on local stub.
- The stub packs (marshals) the necessary information (method name, parameters etc.) and sends to the server-side skeleton. The process of gathering data and transforming it into a standard format before it is transmitted over a network is called marshalling. The stub knows all information (IP address, port) of the skeleton.
- The server-side skeleton, upon receiving the information, unpacks (un-marshals) the information and invokes methods on the actual object. The process of retrieving data from the marshalled data is known as un-marshalling. Finally, it packs the result and sends the result (if any) to the stub.
- The stub unpacks the information and forwards the result to the client.
Start the application
First, start an object registry. In Java, the object registry is started using the application rmiregistry. It can also be created dynamically. Then start the server program. Finally, start the client program.
3. JAVA RMI INTERFACES AND CLASSES
The Java RMI provides remote method invocation a framework as package java.rmi. Application developers use this package to create their programs. Java RMI hides almost all aspects of the distribution and provides a uniform way by which objects (distributed or not) may be accessed. The hierarchy of primary classes and interfaces is shown in Figure 14.3:
Source: Uttam Kumar Roy (2015), Advanced Java programming, Oxford University Press.