The RMI architecture, shown in Figure, describes how remote objects behave and how parameters are passed between remote methods. Remote method invocation allows the program to define separately the behaviour and the code that implements the behaviour and allows running them on separate JVMs. This principle facilitates the clients to focus on the definition of a service while the servers can focus on providing the service.
A remote method can be invoked by referring to the remote object. The object is exported through a server application and a remote client, by either looking up the object name in the registry or by checking the value returned from the remote method. This object must implement at least one interface that is extended by the java.rmi.Remote interface. All interactions with the remote object will be performed through this interface only. Basically, this interface describes the methods, which can be invoked remotely, and the remote object then implements it.
When a remote object is referenced, the object is not sent over the network to the client that requests it. Instead, a proxy object (often referred to as stub), which is a client-side proxy for the remote object, is sent. The client interacts only with this stub class. The stub class is responsible for handling data between the local and the remote systems. One remote object can be referenced by many clients. In that case, each client has its own stub object, which represents that remote object. But in no case is the remote object duplicated.
A skeleton class is responsible for handing over the method, class and data to the actual object being referenced on the server side. This acts as the server side proxy for the object that is being exported.
The actual implementation of the client-server application takes place at the Application layer. Any application that makes some of its methods available to its remote clients must first declare the methods in an interface that extends java.rmi.Remote, which is an empty interface. The main difference between the remote and normal interface is that the remote interface throws the remote exception. If a class is to implement these remote interfaces, it must first implement the UnicastRemoteObject in the java.rmi.server package. Finally, the application registers itself with a naming server or the registry with the name. This name can be used to contact the application and obtain reference to its remote objects. The client simply requests the remote object from the registry with the given name. The reference to the remote object is cast to one of its remote interfaces in order to call the remote methods. The high-level calls can then access and export remote objects.
The Java RMI architecture consists of three layers: (i) Proxy Layer (or Stub/Skeleton layer) (ii) Remote Reference Layer (RRL) (iii) Transport Layer. These are described below:
Proxy layer or stub/skeleton layer
The proxy layer is responsible for managing the remote object interface between the server and client. In this layer, the stub class is the client-side Proxy for the remote object. stub is responsible for initiating a call to the remote object it represents and is the application interface to that object. It is also responsible for marshalling the method arguments to a marshal stream. This stream is a stream object, which simply transports the parameters, exceptions and errors needed for the method dispatch and returns the results. Both the stub and skeleton classes use this stream to communicate with each other. Once the results are returned to the client stub, the results are un-marshalled.
The skeleton class is similar to the stub class in many ways. The only difference is that it exists on the server side. The responsibility of the skeleton class is to send parameters to the method implementation and sending the return values. They are generated using the RMI stub compiler (RMIC). When the remote object from the naming server is requested, the stub class is downloaded to the client machine. The stub and skeleton classes implement the same interfaces as the remote object.
Remote reference layer
This layer gets a stream-oriented connection from the transport layer. It is responsible for dealing with the semantics of remote invocations. It is also responsible for handling duplicated objects and for performing implementation specific tasks with remote objects.
The transport layer is responsible for setting up the connection and transportation of data from one machine to another. The default connection is set up only in the TCP/IP protocol.