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.
RMI Architecture: 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.
--------------------------------------------------------------------
