What is RMI:
RMI – Remote Method Invocation.
RMI allows object-to-object communication between different Java Virtual Machines (JVM).
JVM can be distinct entities located on the same or separate computer.
This enables applications to call object methods located remotely, sharing resources, and processing load across systems.
Methods can even pass objects that a foreign virtual machine has never encountered before, allowing the dynamic loading of new classes as required.
In Java distributed object model, a remote object is one whose methods can be invoked from another JVM, potentially on a different host. An object of this type is described by one or more remote interfaces, which are Java Interfaces that declare the methods of the remote object. Remote Method Invocation is the action of invoking a method of a remote interface on a remote object.
RMI’S purpose is to make objects in separate JVM’S look and act like local objects. The JVM that calls the remote object is usually referred to as a client and the JVM that contains the remote object is the server. One of the most important aspects of the RMI design is its intended transparency. Applications do not know whether an object is remote or local. A method invocation on a remote object has the same syntax as a method invocation on a local object.
A Remote object is always accessed via its remote interface. In the other words the client invokes methods on the object only after casting the reference to the remote interface.
The RMI implementation is essentially built from three abstraction layers :
The Stub/Skeletons Layer :
This layer intercepts method calls made by the client to the interface reference and redirects these calls to a remote object. It is worth remembering that stubs are specific to the client side, whereas skeletons are found on the server side.
The Remote Reference Layer :
This layer handles the details relating to interpreting and managing references made by clients to the remote objects. It connects clients to remote objects that are running and exported on a server by a one-to one connection link.
The Transport Layer :
This layer is based on TCP/IP connections between machines in a network. It provides basic connectivity, as well as some firewall penetration strategies.
--------------------------------------------------------------------------------
Explain Stub And Skeleton Briefly:
To achieve location transparency, RMI introduces two special kinds of objects known as
stubs and skeletons that serve as an interface between an application and the rest of the RMI
system.
A stub is a client side proxy representing the remote object.
A skeleton is a server side proxy that communicate with the stub.
This layer’s purpose is to transfer data to the Remote Reference Layer via Marshaling and UN marshaling.
§ MARSHALING refers to the process of converting the data or object being transferred into a byte stream and UNMARSHALING is the reveres – converting the stream into an object or date. This conversion is achieved via object serialization.
§ The stub and skeleton layer of RMI lies just below the actual application and is based on the proxy design pattern.
 |
In the RMI use of proxy pattern, the stub class plays the role of the proxy for the remote service implementation.
The skeleton is a helper class that is generated by RMI to help the object communicate
with the stub across the RMI link.
§ The skeleton carries on a conversation with the stub; it reads the parameters for the method callfrom 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.
S STUB:
The stub is a client side object that represents the remote object. The stub has the same interface, or list of methods as the remote object. However, when the client calls a stub method, the stub forwards the request via the RMI infrastructure to the remote object (via skeleton), which actually executes it.
The following sequence of events performed by the stub in detail.
§ The stub is the client side proxy for the remote object.
§ Initiates a connection with the remote VM containing the remote object.
§ Marshals (write and transmits) the parameters to the remote VM.
§ Waits for the result of the method invocation.
§ Unmarshals (reads) the return value of exception returned.
§ Returns the value to the caller.
The stub hides the serialization of method parameters and the network level communication in order to present a simple invocation mechanism to the caller.The stub class must implement all the sameinterfaces as the remote object that it represents, it can be cast as any of those remote interface.The remote object may contain non-remote methods and fields, but these are not defined in any of the remote interface.
In the remote VM, each remote object may have a corresponding skeleton.
SKELETONS
On the server-side, the skeleton object takes care of all of the details of “remoteness” so that the actual remote object doesn’t need to worry about them.In other words, we can pretty much code a remote object the same way as if it were local; the skeleton insulates the remote object from the RMI infrastructure.During remote method requests, the RMI infrastructure automatically invokes the skeleton object so it can work its magic.
The following lists the sequence of events in detail;
§ The Skelton class stays on the server side of the connection and deals directly with the implementation classes of the remote methods being exported.
§ Unmarshals (reads) the parameters for the remote method (these were marshaled by the stub on the client side ).
§ Invokes the method on the actual remote object implementation.
§ Marshals (writes and transmits the result (return value or exception) to the caller (which is then unmarshaled by the stub.
The JDK contains the rmic tool that creates the class files for the stubs and skeletons.
--------------------------------------------------------------------
