[go: up one dir, main page]

0% found this document useful (0 votes)
24 views2 pages

RMI and Its Architecture

Uploaded by

mohitchandel2110
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views2 pages

RMI and Its Architecture

Uploaded by

mohitchandel2110
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

RMI and its Architecture

Java Remote Method Invocation API (Java RMI)


It enables the programmer to create distributed Java technology-based to Java technology-based
applications, in which the methods of remote Java objects can be invoked from other Java virtual
machines, possibly on different hosts.
RMI uses object serialization to marshal and unmarshal parameters and does not truncate types,
supporting true object-oriented polymorphism.
API Specification
• java.rmi Package
• java.rmi.dgc Package
• java.rmi.registry Package
• java.rmi.server Package
• java.rmi.activation Package

Architecture of an RMI Application


• We write two programs, a server program (resides on the server) and a client program (resides on
the client)
• Inside the server program, a remote object is created and reference of that object is made available
for the client (using the registry).
• The client program requests the remote objects on the server and tries to invoke its methods.
Components of this architecture
• Transport Layer: This layer connects the client and the server. It manages the existing
connection and also sets up new connections.
• Stub: A stub is a representation (proxy) of the remote object at client. It resides in the client
system; it acts as a gateway for the client program.
• Skeleton: This is the object which resides on the server side. stub communicates with this
skeleton to pass request to the remote object.
• RRL (Remote Reference Layer): It is the layer which manages the references made by the client
to the remote object.
Working of an RMI Application
• When the client makes a call to the remote object, it is received by the stub which eventually
passes this request to the RRL.
• When the client-side RRL receives the request, it invokes a method called invoke() of the
object remoteRef. It passes the request to the RRL on the server side.
• The RRL on the server side passes the request to the Skeleton (proxy on the server) which finally
invokes the required object on the server.
• The result is passed all the way back to the client.

Marshalling and Unmarshalling


Whenever a client invokes a method that accepts parameters on a remote object, the parameters are
bundled into a message before being sent over the In case the parameters are objects, then they are
serialized. This process is known as marshalling.
At the server side, the packed parameters are unbundled and then the required method is invoked. This
process is known as unmarshalling.
RMI Registry
RMI registry is a namespace on which all server objects are placed. Each time the server creates an
object, it registers this object with the RMIregistry (using bind() or reBind() methods). These are
registered using a unique name known as bind name.
To invoke a remote object, the client needs a reference of that object. At that time, the client fetches the
object from the registry using its bind name (using lookup() method).

You might also like