DISTRIBUTED Implementation Types

OBJECTS MODELS
 RMI Remote Method
Invocation

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 2

DISTRIBUTED OBJECTS
MODEL
RMI IMPLEMENTATION
client server
remote
skeleton
object A proxy for B object B
Request & dispatcher
for B’s class

Reply

Remote Communication Communication Remote reference

reference module module module module

The proxy and skeleton role in remote method invocation

Proxy is stub
March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 3
DISTRIBUTED OBJECTS
MODEL
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.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 4

DISTRIBUTED OBJECTS
MODEL
RMI IMPLEMENTATION
 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.

 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).

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 5

DISTRIBUTED OBJECTS
MODEL
RMI IMPLEMENTATION

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 un-marshalling) 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 un-marshall it and
return the result to the invoker.
March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 6
DISTRIBUTED OBJECTS
MODEL
RMI IMPLEMENTATION
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.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 7

DISTRIBUTED OBJECTS
MODEL
RMI IMPLEMENTATION
Skeleton:
 Each class representing a remote object has a skeleton in the server to
implement each method in the remote interface.
 Un-marshall 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 proxy’s method.
e classes of the proxy, skeleton, and dispatcher used in RMI are generated
 Th
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.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 8

DISTRIBUTED OBJECTS
MODEL DISTRIBUTED
GARBAGE COLLECTION
Free resources occupied by objects that have no more reference to it
in the system.
Work in cooperation with the local garbage collector in each process
in the system.
Java Distributed Garbage Collection algorithm:
 Each server maintains a list of clients that hold remote object references for
each of its remote objects.
 When a client C first receives a remote reference to a particular remote object
X, it makes an addRef(X) invocation to the server of that remote object and then
the server adds C to the list of object X.
 When a client C’s garbage collector notices that a proxy for a remote object X is
no longer referenced, it sends removeRef(X) invocation to the corresponding
server which deletes C from the list of object X.
 When the list of a remote object X is empty and there are no local references to
it, the server’s local garbage collector collect resources held by the object X.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 9

DISTRIBUTED OBJECTS
MODEL DISTRIBUTED
GARBAGE COLLECTION
Java algorithm fault tolerance:
 Carried out by request/reply communication with at-most-once invocation
semantics between the remote reference modules in processes.
 Toleration of communication failures:
 addRef and removeRef are indempotent.
 If addRef(X) returns exception, then client will not instantiate proxy but will send
removeRef(X).
 Effect of removeRef(X) is correct no matter whether addRef(X) succeeded or not.
 Failure of removeRef(X) is masked by the use of leases.
 Leases
 Servers lease their objects to clients for limited periods of time, starting with addRef.
 Helps tolerate failures of removeRef as well as client failures.
 Avoids problem of having to maintain lists of remote object references if all object
references are handled through leases.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 10

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 11
 RPC Remote Procedure Call

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 12

REMOTE PROCEDURE
CALL
Birrell and Nelson (1984)

“To allow programs to call procedures located on other machines.”

Effectively removing the need for the Distributed Systems

programmer to worry about all the details of network programming
(i.e. no more sockets).

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 13

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.
March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 14
REMOTE PROCEDURE
CALL (RPC)
client process server process

Request

Reply
client stub server stub
procedure procedure
client service
program Communication Communication procedure
module module
dispatcher

Role of client and server stub procedures in RPC

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 15

REMOTE METHOD
INVOCATION
--RPC –an extension of the conventional procedure call model: It
allows client programs to call procedure in server programs running
in separate processes and generally in different computers from the
client.
--RMI– is 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.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 16

 EVENT AND Publish-subscribe
NOTIFICATIONS
March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 17
EVENTS AND
NOTIFICATIONS
Distributed event-based systems allowing multiple objects at
different locations to be notified of an event occurrence at a
particular object.
The publish-subscribe paradigm is used:
 An object generating events publishes the list of events available for
observation by other objects.
 Objects requiring notifications subscribes to the notification service at an
object offering notification for this particular event through its publication list.
When a publisher experiences an event, subscribers that expressed
an interest in that type of event will receive notifications.
Events and notifications can be used in a wide variety of different
applications:
 A piece of equipment or an electronically tagged book is at new location.
 A client has entered participation in a collaborative work environment.
 An electronic document has been modified.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 18

EVENTS AND
NOTIFICATIONS
DEALING ROOM SYSTEM
Allow dealers using computer to see the latest information about
the market prices of the stocks.
 The market price for a single named stock is represented by an object with
several instance variables.
 The information is arrived from different external sources in the form of
updates to some or all instance variables of the stock objects and collected
by information providers.
 Dealers are interested only in their specialist stocks.

Modeled by processes with two different tasks:

 An information provider process continuously receives information from a
single external source to apply it to the appropriate stock objects as an event
and notifies all the dealers subscribed to the corresponding stock.
 A dealer process creates a local object to represent each named stock to
subscribe the stock object at the relevant information provider and receive
all information sent in notifications to display it to the user.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 19

EVENTS AND
NOTIFICATIONS
DEALING ROOM SYSTEM
Dealer’s computer External
source
Dealer’s computer

Dealer Notification Notification Dealer

Notification Information
provider Notification

Notification
Notification
Notification
Dealer’s computer Dealer’s computer
Notification
Information
provider
Notification
Dealer Notification

Dealer
External
source
March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 20
EVENTS AND
NOTIFICATIONS
EVENT TYPES
An event source can generate events of one or more different types.
Each event has attributes to specify information about that event: the
name of object generated it, the operation, its parameters and the
time.
Types and attributes are used in subscribing to events and in
notifications.
Whenever an event of a specific type that matches the attributes
occurs, the interested parties will be notified.
In dealing room system example:
 There is one type of event – the arrival of an update to a stock.
 The attributes might specify the name of a stock, its current price, and latest
rice or fall.
 Dealers may specify the interesting in all the events of a particular stock.

March 2018 IMPLEMENTATIONS OF DISTRIBUTED OBJECT MODELS 21