1

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

CHAPTER-5 Distributed Objects & Remote Invocation

A distributed programming model is as an abstraction layer above
communication protocols details.
Different Programming models provided by middleware to support
distributed applications include:
Remote Procedure Call (RPC):
Allows Client programs to call procedures in server
programs running in separate processes and generally in
different computer from client
Remote Method Invocation (RMI):
An extension of local method invocation that allows an
object living in one process to invoke the methods of an
object living in another process
Event-based processing and event notification:
The behavior of the system is driven by events, which
represent local state changes within objects.
Objects receive notifications of events at other objects
in which they have registered interest.

MIDDLEWARE
Software that provides a programming model above the basic
building blocks of processes and message passing is called
middleware
It uses protocols based on messages between processes to provide
its higher level abstractions such as remote invocations and events
Example remote invocation abstraction is based on the request
reply protocol
The important aspects of middleware are
D.ABHISHEKH MSSE

SV COLLEGES

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

Middleware is the provision of transparency and heterogeneity

challenges:
Location transparency:
RMI and RPC invoked without knowledge of the location
of invoked method/procedure.
Transport protocol transparency:
e.g., request/reply protocol used to implement RPC can
use either transport protocols (UDP or TCP).
Transparency of computer hardware and operating system:
e.g., use of external data representations.
Transparency of programming language used
e.g., by use of programming language independent
Interface Definition Languages, such as CORBA IDL.
INTERFACES IN DISTRIBUTED SYSTEMS
In a distributed program, the modules can run separate process. It is not
possible for a module running in one process to access the variables in a
module in another process. Therefore the interface of a module that is
intended for RPC or RMI cannot specify direct access, however the
attributes are not accessed directly but by means of some getter and
setter procedures added automatically to the interface
DISTRIBUTED OBJECTS
The logical partition of object-based programs into objects is
naturally extended by the physical distribution of objects into
different processes or computers in a distributed system.
Distributed object systems adopt the client-server architecture:
Objects are managed by servers and their clients invoke their
methods using remote method invocation.

D.ABHISHEKH MSSE

SV COLLEGES

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

The clients RMI request is sent in a message to the server

managing the invoked method object.
The method of the object at the server is executed and its
result is returned to the client in another message.
Objects in servers are allowed to become clients of objects in
other servers.
DISTRIBUTED OBJECT MODEL
Each process contains a collection of objects, some of which can
receive both local and remote invocations and others can receive
only local invocations.
Objects that can receive remote invocations are called remote
objects.
Other objects need to know the remote object reference in
another process in order to invoke its methods.
A remote object reference is an identifier that can be used
through a distributed system to refer to a particular unique
remote object.
Every remote object has a remote interface to specify which of its
methods can be invoked remotely.
Objects in other processes can invoke only the methods that
belong to the remote interface of the remote object.
Local objects can invoke the methods in the remote interface
as well as other methods of the remote object.

D.ABHISHEKH MSSE

SV COLLEGES

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

Object B and F are remote objects and they must have remote
interface
the remote object to receive a remote method invocation is
specified by the invoker as a remote object reference

DESIGN ISSUES FOR RMI

RMI usually applied via request/reply protocol which can suffer
from many types of failure:
Message omission and duplication can occur if implemented
over UDP.
Process failures (crash or arbitrary) are also possible.
Therefore, different choices of fault-tolerance measures can be
applied:
Retry request message until a reply is received or the server
is assumed to be failed
Duplicate filtering when a retransmission are used whether to
filter out duplicate request at the server.
Retransmission of results when retransmitted request arrives
or result retransmission (requires keeping a history at the
server).
Combinations of fault-tolerance choices lead to a variety of
invocation semantics for the reliability of remote invocation.

D.ABHISHEKH MSSE

SV COLLEGES

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

Maybe invocation semantics:

No fault-tolerance measure is applied.
The invoker cannot tell if a remote method has been executed
or not.
Suffer from the following types of failure:
Omission failures if invocation or result message is lost.
Crash failures if the server containing the remote
object fails.
At-least-once invocation semantics:
Uses only retransmission of request messages masks
omission failures.
The invoker receives either a result (after at least one
execution) or an exception informing no result was received.
Suffer from the following types of failure:
Crash failure if the server containing the remote object
fails.
Arbitrary failures when re-execute the method more
than once which causing wrong values to stored or
returned (non-idempotent operations).
At-most-once invocation semantics:
Uses all the fault-tolerance measures.

D.ABHISHEKH MSSE

SV COLLEGES

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

The invoker receives either a result (after exactly one

execution) or an exception informing no result was received.
Prevents arbitrary failures by ensuring that a method is never
executed more than once for the same RMI.
RMI IMPLEMENTATION
Several separate objects and modules are involved to achieve a
remote method invocation:
Communication modules:
Responsible for providing a specified invocation
semantics.
Carry out the request-reply protocol to transmit request
and reply messages between the cooperating server and
client.
Use only the first three items of the request and reply
messages: message type, request id, and the invoked
remote object reference.
Select the dispatcher software for the invoked object
class in the server.
Remote reference modules:
Translate between local and remote object references
and create remote object references.
Have a remote object table in each process to support
the translation.
An entry for all the remote objects held by the
server in its table.
An entry for each local proxy held by the client in
its table.

D.ABHISHEKH MSSE

SV COLLEGES

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

Create a remote object reference and add it to the

table when a remote object is passed in a request or a
replay message for the first time.
Translate the remote object reference to the
corresponding local object reference which refer either
to a remote object (in the server) or to a proxy (in the
client).
RMI Software:
Proxy:
Make remote method invocation transparent to
clients by behaving like a local object to the
invoker.
Forward the call in a message to the remote object
and hiding all in-between operations (send, receive,
marshalling, and unmarshalling) from the client.
A client has one proxy for each remote object to
hold its remote reference and implement the
methods in its remote interface.
Marshal a reference to the target object, its own
methodId and its arguments into a request
message and send it to the target then await the
reply message to unmarshal it and return the result
to the invoker.
Dispatcher:
A server has one dispatcher for each class
representing a remote object.
Receive the request message from the
communication module and use the methodId to
select the appropriate method in the skeleton and
passing on the request message.
D.ABHISHEKH MSSE

SV COLLEGES

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

Skeleton:
Each class representing a remote object has a
skeleton in the server to implement each method in
the remote interface.
Unmarshal the argument in the request message
and invoke the corresponding method in the remote
object.
Await the invocation to complete to marshal the
result in the reply message to the client proxys
method.
The classes of the proxy, skeleton, and dispatcher used
in RMI are generated automatically by an interface
complier.
The server program contains the classes for the
dispatchers and skeletons together with the
implementations of the classes of all remote objects
that it supports servant classes.
The client program contains the classes of the proxies
for all the remote objects that it will invoke and use a
binder to look up remote object references.

D.ABHISHEKH MSSE

SV COLLEGES

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

Remote Procedure Call (RPC)

Very similar to a remote method invocation
A client process calls a procedure in a server process.
Servers may be clients of other servers to allow chains of
RPCs.
Implemented to have one of the choices of invocation
semantics.
Implemented over a request-reply protocol .
The contents of request and reply messages are the same as
RMI except that the object reference field is omitted.
The supported software is similar except that no remote
reference modules are required and client proxies and server
skeletons are replaced by client and server stub procedures.
The service interface of the server defines the procedures that
are available for calling remotely.
The client and server stub procedures and the dispatcher are
generated by an interface compiler from the definition of the
service interface.

D.ABHISHEKH MSSE

SV COLLEGES

10

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

EVENTS & NOTIFICATIONS

The idea behind the use of events is that one object can react to a
change occurring in another object. Notifications of events are
essentially asynchronous & determined by their receivers
Distributed events- based systems extend the local event model by
allowing multiple objects at different locations to be notified of
events taking place at an object they use PUBLISH-SUBSCRIBE
PARADIGM , in which an object that generates events publishes the
type of events that it will make available for observation by other
objects. Objects that want to receive notifications from an object
that has published its events subscribe to the types of events that
are of interest to them. objects that represent events is called
notifications
Dealing with room system
External
source

Dealers
Dealer

Dealers

Notification

Notification

Notification

Information
provider Notification

Notification
Dealers

Notification

Notification

Notification

Dealer

Notification

Dealer

Dealers

Information
provider
Notification
Dealer
Externa
sourc

D.ABHISHEKH MSSE

SV COLLEGES

11

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

Client

Server

Stubs

Skeletons

Remote
Reference

Remote
Reference
Transport

There are three layers that comprise the basic remoteobject communication facilities in RMI:
1. The stub/skeleton layer, which provides the
interface that client and server application objects
use to interact with each other.

D.ABHISHEKH MSSE

SV COLLEGES

12

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

2. The remote reference layer, which is the

middleware between the stub/skeleton layer and the
underlying transport protocol.
3. The transport protocol layer, which is the binary
data protocol that sends remote object requests
over the wire.

Description of the architecture:

1.

The client uses the client-side stub to make a request of the

remote object. The server object receives this request from a
server-side object skeleton.

2.

A client initiates an RMI invocation by calling a method on a stub

object. The stub maintains an internal reference to the remote
object it represents and forwards the method invocation request
through the remote reference layer by marshaling the method
arguments into serialized form and asking the remote reference
layer to forward the method request and arguments to the
appropriate remote object.

3.

Marshaling involves converting local objects into portable form

so that they can be transmitted to a remote process. Each
object (e.g. a String object, an array object, or a user defined
object) is checked as it is marshaled, to determine whether it
implements the java.rmi.Remote interface. If it does, its remote
reference is used as its marshaled data. If it isnt a Remote
object but is rather a Serializable object, the object is
serialized into bytes that are sent to the remote host and
reconstructed into a copy of the local object. If the object is

D.ABHISHEKH MSSE

SV COLLEGES

13

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

neither Remote nor Serializable, the stub throws a

java.rmi.MarshalException back to the client.
4.

If the marshaling of method arguments succeeds, the client-side

remote reference layer receives the remote reference and
marshaled arguments from the stub.

5.

The remote reference layer converts the client request into lowlevel RMI transport requests, i.e., into a single network-level
request and sends it over the wire to the sole remote object
that corresponds to the remote reference passed along with the
request.

6.

On the server, the server-side remote reference layer receives

the transport-level request and converts it into a request for
the server skeleton that matches the referenced object.

7.

The skeleton converts the remote request into the appropriate

method call on the actual server object. This involves
unmarshaling the method arguments into the server environment
and passing them to the server object. Arguments sent as
remote references are converted into local stubs on the server,
and arguments sent as serialized objects are converted into local
copies of the originals.

8.

If the method calls generates a return value or an exception, the

skeleton marshals the object for transport back to the client
and forwards it through the server reference layer.

The result is sent back using the appropriate transport protocol (e.g.
Socket API using TCP/IP), where it passes through the client reference
layer and stub, is unmarshaled by the stub, and is finally handed back to
the client thread that invoked the remote method.

D.ABHISHEKH MSSE

SV COLLEGES

14

CHAPTER-5(UNIT-2)

DISTRIBUTED OBJECTS & REMOTE INVOCATION

RMI REGISTRY
Naming/Registry Service
A server process needs to register one (or more) RMIenabled objects with its local RMI registry (represented by
the Registry interface) using a name that clients can use to
reference it.
A client can obtain a stub reference to the remote object by
asking for the object by name through the Naming interface.
The Naming.lookup() method takes the name of a remote
object and locates the object on the network. The objects
name is in a URL-like syntax that includes the name of the
objects host and the objects registered name.
Once the lookup() method locates the objects host, it
consults the RMI registry on the host and asks for the object
by name. If the registry finds the object, it generates a
remote reference to the object and delivers it to the client
process, where it is converted into a stub (local) reference
that is returned to the caller.
FORMAT: rmi//ComputerName/ObjectService

D.ABHISHEKH MSSE

SV COLLEGES