RMI Interview Questions and Answers

RMI uses a layered architecture, each of the layers could be enhanced or replaced without affecting the rest of the system. The details of layers can be summarised as follows:

Application Layer: The client and server program
Stub & Skeleton Layer: Intercepts method calls made by the client/redirects these calls to a remote RMI service.
Remote Reference Layer: Understands how to interpret and manage references made from clients to the remote service objects.
Transport layer: Based on TCP/IP connections between machines in a network. It provides basic connectivity, as well as some firewall penetration strategies.

The most significant difference between RMI and CORBA is that CORBA was made specifically for interoperability across programming languages. That is CORBA fosters the notion that programs can be built to interact in multiple languages. The server could be written in C++, the business logic in Python, and the front-end written in COBOL in theory. RMI, on the other hand is a total Java solution, the interfaces, the implementations and the clients--all are written in Java.

RMI allows dynamic loading of classes at runtime. In a multi-language CORBA environment, dynamic class loading is not possible. The important advantage to dynamic class loading is that it allows arguments to be passed in remote invocations that are subtypes of the declared types. In CORBA, all types have to be known in advance. RMI (as well as RMI/IIOP) provides support for polymorphic parameter passing, whereas strict CORBA does not. CORBA does have support for multiple languages which is good for some applications, but RMI has the advantage of being dynamic, which is good for other applications.

An RMI "service" could well be any Java method that can be invoked remotely. The other service is the JRMP RMI naming service which is a lookup service.

Yes. The JDK 1.2 support the dynamic class loading.

RMI has at least three protocol implementations: Java Remote Method Protocol(JRMP), Internet Inter ORB Protocol(IIOP), and Jini Extensible Remote Invocation(JERI). These are alternatives, not part of the same thing, All three are indeed layer 6 protocols for those who are still speaking OSI reference model.

No, RMI-IIOP doesn't support dynamic downloading of the classes as it is done with CORBA in DII (Dynamic Interface Invocation).Actually RMI-IIOP combines the usability of Java Remote Method Invocation (RMI) with the interoperability of the Internet Inter-ORB Protocol (IIOP).So in order to attain this interoperability between RMI and CORBA,some of the features that are supported by RMI but not CORBA and vice versa are eliminated from the RMI-IIOP specification.

Yes they can. RMI is available with IIOP as the transport protocol instead of JRMP.

A request from one program that is located in one computer can be used by another computer in a network environment without understanding the underlying network details. This is done by a protocol called Remote Procedure Calls. In this client / server environment (network environment), the request is from a client to the server that provides the service from a server.

RPC is also called as inter-process communication. RPC extends the normal procedure calls across the network which is necessary in distributed computing models and for harnessing the power of the multiple processors.

In distributed systems, a client calls a procedure stored on a server. This is called calling a remote procedure stored on a server. Though, the call is made as if the procedure was stored on the local machine.

The steps in which a RPC is made are:

* The client calls the procedure
* The client stub builds the message.
* The message is sent over the network.
* The Server OS gives the message to the server stub.
* The server stub unpacks the message.
* The stub makes a local call to the procedure.
* The server does the work and returns the result to the server stub.
* The stub packs the message and traps to the kernel.
* The remote kernel sends the message the client kernel.
* The client kernel gives the message to the client stub.
* The client stub unpacks the result and gives to the client.

Advantages of RPC:

* Server independent
* Process-oriented and thread oriented models supported by RPC
* The development of distributed systems is simple because it uses straightforward semantics and easier.
* Like the common communications between the portions of an application, the development of the procedures for the remote calls is quite general.
* The procedure calls preserves the business logics which is apt for the application.
* The code re-writing / re-developing effort is minimized.
* Enables the usage of the applications used in the distributed environment, not only in the local environment.
* RPC provides interoperability between CORBA ORB implementations.
* A lightweight RPC protocol permits efficient implementations.

Disadvantages of RPC:

* Context switching increases scheduling costs
* RPC is not a standard – it is an idea that can be implemented in many ways
* RPC does not solve the most of the distribution creation problems
* RPC is only interaction based. This does not offer any flexibility in terms of hardware architecture.
* RPC implementations are not yet mature.
* It requires the TCP/IP protocol. Other transport protocols are not supported yet.
* Not yet proven over wide-area networks.

RMI:

* The remote objects are accessed by the references
* Implements object to object implementation among different java objects to implement distributed communication model.
- RMI passes the objects as parameters to remote methods.
- RMI invokes the remote methods from the objects

RPC:

* The process is through methods / functions
* Proxy server is involved in processing the procedure calls
* Calls a procedure remotely like invoking the methods
* The remoteness is not exactly transparent to the client

RMI is a java object equivalent process that invokes a method in a distributed environment.

RMI performs the communication among objects using object-to-object communication. RMI uses the objects distribution techniques and invokes methods of objects which are located in a remote site.

Working of RMI:

The code from machine A is being accessed for the object that is residing on machine B in a remote relocation. There are two intermediate objects called a 'stub' and a 'skeleton', which actually handles the communication. The following are the tasks that performed by these two objects:

Task that are to be handled by the stub object (on machine X):

* Building a information block which consists of
- an identifier of the remote object
- an operation number that describes the method to be called and
- the method parameters called marshaled parameters that are to be encoded into a suitable format for transporting over the network
* Sending the information to the server.

The tasks that are to be handled by the skeleton object (on machine Y) are:

* Unmarshalling the parameters
* Invoking the required method of the object which is lying on the server
* Capturing and returning the value if successful or an exception if unsuccessful , after the call on the server
* Marshalling the returned value
* Packaging the value that is in the marshaled form and sending to the stub on the client.

Subsequently the stub object unmarshals the return value or exception from the server as the case may be. This is the returned value of the remote method invocation. If an exception is thrown, the stub object will rethrow the exception to the caller.

RMI

* RMI is tightly-coupled mechanism.
* The destination object need to be available online at the time of sending messages from client to server.
* RMI has RPC-model

JMS

* JMS provides loosely coupled mechanism.
* The destination object need not be available online at the time of sending messages from client to server.
* JMS has messaging model.

The class rebind () method of java.rmi.Naming class is used to specify the port number . For example if the registry is running on a port number 3271 of an application named HelloRMIRegistry the following is the usage of the URL to reference the remote object:

Naming.rebind ("//host:1111/RMIRegistry", obj);

The URL stored on the web page needs to specify the non-default port number.
When the server’s remote objects created by the server can include the URL from which the stub class can dynamically be downloaded to the client. The following example depicts this:

java -Djava.rmi.server.codebase=http://host/username/codebase/examples.ExampleRMIURL

The methods of remote objects are to be invoked by implementing the java.rmi.Remote interface.

Methods:

bind(): binds the specified name to the remote object. The name parameter of this method should be in an URL format.

unbind(): Destroys the binding for a specific name of a remote method in the registry

rebind(): Binds again the specified name to the remote object. The current binding will be replaced by rebinding.

list(): Returns the names of the names that were bound to the registry in an array form. These names are in the form of URL-formatted string.

lookup(): A stub, a reference will be returned for the remote object which is related with a specified name.

Creation of RMI-based Server:

* Create the Servant interface and the Servant component class
* To host these servant classes create the RMI Server
* Compile the class files and generate the Skeletons and IDL File
* Start up the Server

Creation of RMI-based Client:

* Create the Client class
* Copy the IIOP Stubs and compile the Client
* Make sure the Server is running and then startup the Client

Data in a file can be transferred by using the method getFileContents(filename) in the remote interface.

RMI supports to transfer data that is available in JDOM data objects.

Remote interfaces are defined by extending ,an interface called Remote provided in the java.rmi package. The methods must throw RemoteException. But application specific exceptions may also be thrown.

During communication between two machines through RPC or RMI, parameters are packed into a message and then sent over the network. This packing of parameters into a message is called marshalling.

On the other side these packed parameters are unpacked from the message which is called unmarshalling.

Server side stub is refered to as a skeleton.

The role of the stubs is to marshal and unmarshal the messages that are sent and received on the client or the server side.

The Stub/Skeleton Layer:

The stub/skeleton layer sits in between application layer and the rest of the RMI system and acts as an interface. This layer transmits the information to remote layer. This transmission is done through the marshalling of streams. These streams performs the object serialization.

A stub is a remote object at the client-side. This stub implements all the interfaces which remote object implementation supports.

A skeleton is a remote object at the server-side. This stub consists of methods that invokes dispatch calls to the remote implementation of objects.

The Remote Reference Layer:

The lower level transport interfaces is dealt by this layer. This layer carries a specific remote reference protocol independent of stub and skeletons.

Every remote object is implemented by choosing their individual remote reference subclasses.

The Transport Layer:

The transport layer sets up the connections to remote address spaces, manages them, monitors the connection liveliness, and listens the incoming calls.

The transport layer maintains the remote object’s table available in the address space, in a table. For incoming calls, the transport layer establishes a connection. It locates the target dispatcher of the remote calls and passes the connection to the dispatcher.

* The client procedure calls the client stub in the normal way.
* The client stub builds a message and traps to the kernel.
* The kernel sends the message to the remote kernel.
* The remote kernel gives the message to the server stub
* The server stub unpacks the parameters and calls the server.
* The server does the work and returns the result to the stub.
* The server stub packs it in a message and traps to the kernel.
* The remote kernel sends the message to the clients kernel.
* The clients kernel gives the message to the client stub.
* The stub unpacks the result and returns to the client.

* Assigning the security manager and then obtaining the reference to the service
* Contacting the RMI registry to obtain the remote object’s reference and invoking its methods
* Requesting the name for the service
* Invoke the remote method.

RMI stands for Remote Method Invocation. Traditional approaches to executing code on other machines across a network have been confusing as well as tedious and error-prone to implement. The nicest way to think about this problem is that some object happens to live on another machine, and that you can send a message to the remote object and get a result as if the object lived on your local machine. This simplification is exactly what Java Remote Method Invocation (RMI) allows you to do. Above excerpt is from "Thinking in java". For more information refer to any book on Java.

The registration of the remote object must be done by the server in order for the client to look it up, is called the RMI Registry. In RMI, the client must contact an RMI registry, so that the server side application will be able to contact the client’s registry which points the client in the direction of the service. The client registers the service with the registry so that it is transparent to even for the server.

If an object implements the java.rmi.Remote interface, an object is to be bound to registry context. Each registry context implements the Referenceable interface.

The object factory is implemented by the RegistryContextFactory which converts the registry references into the corresponding registry contexts or remote objects. To construct the registry constructs, the URL of the registry must be determined. In this way the remote objects will be bounded with registry contexts.

To marshal and unmarshall the parameters involves the object serialization and does not truncate types.

The methods of local object and their bytecodes are not passed directly in the ObjectOutputStream. At times the name of the class of the objects may be needed that is to be loaded by the receiver if at all the class is not available locally. Just like the names of the classes, the class files themselves will not be serialized. All classes must load during the process of deserialization using the normal mechanisms of class loading.

When one service passes an object which is the proxy for another service, the RMI callback mechanism occurs. The methods will be invoked by the recipient in the object it received and be calling back to the calling point. The stub contains the information that is needed to call back to server at the time of the need.

In client-server technology / architecture, a server responds to a remote client. A call back is a method invocation from one application (Application A) from another application (Application B), as a result of action that was performed by the Application B earlier. The Application A may run on a client and the Application may run on a server. To perform the call back mechanism the system that Application A runs acts as a Server and that of the Application B runs acts as a client.

Object Activation is a process of providing persistent references to the objects. It also includes the managing the execution of implementing of objects. RMI activates the objects for the execution as and when needed. The appropriate execution is initiated inside the appropriate JVM when the activatable remote object is accessed which is not currently running.

The difference between unicast and multicast is that in unicast approach the sender sends the data stream to a single receiver at a time. Thus there is one to one communication.

In a multicast the sender and the interested receivers communicate. This is one to many communication. This communication can take place between data terminals spread across various LANs too.