Remote Method Invocation (RMI)

1
Introduction

• Remote Method Invocation (RMI) provides a framework

for building distributed Java systems.
• Using RMI, a Java object on one system can invoke a
method in an object on another system on the network.
• The aim of the RMI architecture is to allow the
programmer to invoke services from remote objects
(almost) the same way as from local objects.
• RMI uses an OOP where the user needs to know the
object and the method of the object he needs to invoke.
• RMI handles the complexities of passing along the
invocation from the local to the remote computer.
• But instead of passing a procedural call, RMI passes a
reference to the object and the method that is being
2
called.
RMI Basics

• RMI is a higher-level API built on top of sockets

• RMI enables you also to invoke methods in a remote
object
• An RMI component can act as both a client and a server,
depending on the scenario
• in question.
• An RMI system can pass functionality from a server to a
client, and vice versa.
• Typically a client/server system only passes data back
and forth between server and client

3
RMI - Terms

• Local objects are accessible only within the local host.

• Remote Objects are accessible from a remote host
• Server object interface: A sub-interface that defines the
methods for the server object.
• Server class: A class that implements the remote object
interface.
• Server object: An instance of the server class.
• RMI registry: A utility that registers remote objects and
provides naming services for locating objects.
• Client program: A program that invokes the methods in the
remote server object.
• Server stub: An object that resides on the client host and
serves as a surrogate forthe remote server object.
• Server skeleton: An object that resides on the server host and
communicates with the stub and the actual server object.
4
RMI - Terms

• Services interface is used to refer to the specification of

the procedures offered by a server, defining the types of
the input and output arguments of each of the
procedures.
• Remote interface specifies the method of an object that
are available for invocation by objects in other processes,
defining the types of the input and output arguments of
each of them.
• Interface Definition Languages (or IDLs) are designed
to allow objects implemented in different languages to
invoke one another.
• Remote Object Reference is an identifier that can be
used throughout a distributed system to refer to a
5
particular unique remote object.
RMI - Advantages

• Object Oriented
• Mobile Behavior
• Design Patterns
• Safe and Secure
• Easy to Write/Easy to Use
• Connects to Existing/Legacy Systems
• Write Once, Run Anywhere
• Distributed Garbage Collection
• Parallel Computing
6
Distributed Objects & Remote
Invocation
Objects that can receive remote method invocation are called
remote objects and they implement a remote interface.
Due to the possibility of independent failure of invoker and
invoked objects, RMI have different semantics from local
calls.
RPC is to RMI as procedure call is to object invocation.

7
RMI - Architecture

• The RMI implementation is essentially built from three

abstraction layers.
• Stub and Skeleton layer
• Remote Reference Layer
• Transport layer

8
RMI - Architecture

• Stub and Skeleton Layer

• The stub and skeleton layer of RMI lie just beneath the
view of the Java developer.
• In this layer, RMI uses the Proxy design pattern
• In the Proxy pattern, an object in one context is
represented by another (the proxy) in a separate context.
• The proxy knows how to forward method calls between
the participating objects.

9
RMI - Architecture
• Responsibilities of the stub • Responsibilities of the
• On client side, stub does the skeleton
following: • On the server, the skeleton,
– Initiating remote calls – Unmarshals incoming
– Marshaling arguments to be arguments
sent – Calling the actual
– Informing the remote reference remote object
layer that a call should be implementation
invoked on the server – Marshaling return
– Unmarshalling a return value values for transport to
(or exception) the client
– Informing the remote reference
layer that the call is complete
10
RMI - Architecture

• Remote Reference Layer

• The Remote Reference Layers defines and supports
the invocation semantics of the RMI connection.
• This layer provides a RemoteRef object that
represents the link to the remote service
implementation object.
• The communication is made in a point to point
(unicast) basis

11
RMI - Architecture

• Transport Layer
• The Transport Layer makes the connection between JVMs.
• All connections are stream-based network connections
that use TCP/IP.
• Even if two JVMs are running on the same physical
computer, they connect through their host computer's
TCP/IP network protocol stack.
• The following diagram shows the unfettered use of TCP/IP
connections between JVMs.

12
RMI - RMI Registry
• The RMI registry provides the registry services for the server to
register the object and for the client to locate the object

LocateRegistry class provides the methods for obtaining a registry on a host.

Registry
13
class provides the methods for binding and obtaining references to
remote objects in a remote object registry.
Design Issues for RMI
The two design issues that arise in RMI are:
 The choice of invocation semantics
There is no problem to call local invocations but in remote
invocation the problem of exception may arise like object
not found, object registered, time out, connection failure,
mismatch in semantics etc.

 The level of transparency that is desirable for RMI.

14
RMI invocation semantics
The Request- reply protocols that do Operation can be
implemented in different ways to provide different delivery
guarantees. The main choice are:
Retry request message: whether to retransmit the request
message until either a reply is received or the server is assumed
to have failed.
Duplicate filtering: when retransmission are used, whether to
filter out duplicate requests at the server.
Retransmission of results: whether to keep a history of result
messages to enable lost results to be retransmitted without re-
executing the operations at the server.

15
RMI invocation semantics
Combinations of these choices lead to a variety of possible
semantics for the reliability of remote invocations as seen by the
invoker. Table shows the choice of interest, with corresponding
names for the invocation semantics that they produce.

Fault tolerance measures Invocation

semantics

Retransmit request Duplicate Re-execute procedure

message filtering or retransmit reply
No Not applicable Not applicable Maybe
Yes No Re-execute procedure At-least-once

Yes Yes Retransmit reply At-most-once

16
RMI invocation semantics / Policies

Maybe Invocation Semantics : With Maybe invocation

semantics, the remote method may be executed once or not
at all. Maybe semantics arises when none of the fault
tolerance measures is applied.
At least once Invocation Semantics : With this, the
invocation semantics, the invoker receives either a result or
an exception informing that no result is received. This
semantics can also be achieved by retransmission of request
messages.
At most once Invocation Semantics : With this, the invoker
receives either a result (where invoker knows that the
method was executed exactly once, or an exception informing
that no result was received. This semantics can also be
achieved by using all of the fault tolerance measures.
17
RMI - Working

18
RMI - Working

• This is concerned with Middleware.

19
RMI - Working

1. Server creates remote object

2. The remote object is registered at the binding server
(rmiregistry ) by the server
3. The client sends request to the binding server seeking the
remote object
4. If remote object is found, the binding server returns the
remote reference
5. Client invokes stub method
6. Stub talks to skeleton
7. Skeleton invokes remote object

20
CORBA
• CORBA is the acronym for Common Object Request
Broker Architecture
• CORBA is a middleware design that allows application
programs to communicate with one another irrespective
of their programming languages, their hardware and
software platforms, the networks they communicate over
and their implementers.
• CORBA products provide a framework for the
development and execution of distributed applications.
• CORBA services provide generic facilities that may be of
use in a wide variety of applications, like
• Naming Service, the Event and Notification Services,
the Security Service, the Transaction and Concurrency
21
Services and the Trading Service.
CORBA - History

• CORBA is OMG's (formed in 1989) open, vendor independent

specification for an architecture and infrastructure that
computer applications use to work together over networks
• They introduced the object request broker (or ORB), whose
role is to help a client to invoke a method on an object.
• This role involves locating the object, activating the object if
necessary and then communicating the client’s request to the
object, which carries it out and replies
• In 1991, a specification for an object request broker
architecture known as CORBA was agreed by a group of
• companies.
• This was followed in 1996 by the CORBA 2.0 specification,
which defined standards enabling implementations made by
different developers to communicate with one another
22
CORBA – Main Components

• An interface definition language known as IDL

• An architecture
• The GIOP (General Inter-ORB protocol) defines an
external data representation, called CDR
• The IIOP, an implementation of GIOP defines a standard
form for remote object references

23
CORBA - Architecture

Main components of CORBA Architecture

24
CORBA - Architecture

• The architecture is designed to support the role of an

object request broker that enables clients to invoke
methods in remote objects, where both clients and
servers can be implemented in a variety of programming
languages.
• CORBA provides for both static and dynamic invocations.
• Static invocations are used when the remote interface of
the CORBA object is known at compile time, enabling
client stubs and server skeletons to be used.
• If the remote interface is not known at compile time,
dynamic invocation must be used.

25
CORBA - Architecture
• ORB core: The role of the ORB core is similar to that of the
communication module . An ORB core provides an interface
that includes the following:
• operations enabling it to be started and stopped;
• operations to convert between remote object references
and strings;
• operations to provide argument lists for requests using
dynamic invocation.
• Portable object adapter: POA is the object adapters
• It is called portable because it allows applications and servants
• to be run on ORBs produced by different developers
• The POA supports CORBA objects with two different sorts of
lifetimes:
• Those whose lifetimes are restricted to that of the process
their servants are instantiated in;
• Those whose lifetimes can span the instantiations of servants
26
in multiple processes.
CORBA - Architecture

• Object adapter: The role of an object adapter is to bridge the

gap between CORBA objects with IDL interfaces and the
programming language interfaces of the corresponding servant
classes.
• An object adapter gives each CORBA object a unique object
name, which forms part of its remote object reference
• An object adapter has the following tasks
• it creates remote object references for CORBA objects
• it dispatches each RMI via a skeleton to the appropriate
servant;
• it activates and deactivates servants.

27
CORBA - Architecture

• Skeletons: Skeleton classes are generated in the language of

the server by an IDL compiler.
• Client stubs/proxies: The class of a proxy or a set of stub
procedures is generated from an IDL interface by an IDL
compiler for the client language
• Implementation repository: An implementation repository is
responsible for activating registered servers on demand and
for locating servers that are currently running.

Fig: Implementation repository Entry

• Interface repository: The role of the interface repository is to
provide information about registered IDL interfaces to clients
and servers that require it.

28
CORBA - Working

29 Fig:. Working of CORBA

CORBA - Services

• CORBA includes specifications for services that may be

required by distributed objects
• The CORBA services include the following
• Naming Service
• Event Service and Notification Service
• Security service
• Transaction service and concurrency control service
• Persistent state service

30