Chapter 05

Chapter 5:
Distributed objects and remote invocation
From Coulouris, Dollimore and Kindberg

Distributed Systems:
Concepts and Design
Edition 4, © Addison-Wesley 2005
Figure 5.1
Middleware layers
Applications
RMI, RPC and events

Middleware
Request reply protocol layers
External data representation
Operating System
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
© Pearson Education 2005
1
Topics
Remote method invocations

Events and notifications
Remote Method Invocations
The object model

Distributed objects
The distributed object model
Design issues
Implementation
Distributed garbage collection
2
The Object Model
Objects have data and methods

Data should be accessible only via its methods
Objects can be accessed via object references
Interfaces
Provide signatures of methods without implementation
Serve as contracts
Actions
Exceptions
GC
Distributed Objects
Objects located in different processes, not

necessarily different computers
Remote vs. local
Objects
Method invocation
Distributed objects collaborate via remote method
invocations, which enforces encapsulation
The state of an object can be accessed only via methods
3
Figure 5.3
Remote and local method invocations
remote local C
local E
invocation invocation
remote
invocation invocation F
B local
A
invocation D
The Distributed Object Model
Remote object reference

Invoked remote objects are identified by reference
⌧Reference vs. pointer
Remote object references can be passed as arguments
and results of RMIs
Remote interface
Every remote object has a remote interface
May be specified by IDL, e.g. CORBA IDL
Passing parameters can be described as input and output
⌧Input parameters serves as arguments
⌧Output parameters will be returned and used as results or to replace the
values of the corresponding variables in the calling environment
4
Figure 5.2
CORBA IDL example
// In file Person.idl
struct Person {
string name;
string place;
long year;
};
interface PersonList {
readonly attribute string listname;
void addPerson(in Person p) ;
void getPerson(in string name, out Person p);
long number();
};
Figure 5.4
A remote object and its remote interface
remoteobject
Data
remote
interface
m1 implementation m4
{ m2
m3 of methods
m5
m6
5
Figure 5.5 Instantiation of remote objects
L
C remote remote K
instantiate instantiate
invocation invocation
M N
The Distributed Object Model (con’t)
Actions
After invocation request received, an action is initiated and
may result further invocations on other objects
Remote GC
Reclaim the unused space
Cooperation between existing local GCs and a coordinator
Exceptions
Errors may occur and raise exceptions
Client programs need to be able to handle exceptions,
e.g. C++
6
Design Issues
Invocation semantics
Local: exact once
Remote: maybe, at-least-once, at-most-once
Transparency
Should local and remote invocations have the same
syntax?
Remote invocations may have many failures that local
invocations don’t have
The difference should be revealed in remote interfaces
Figure 5.6
Invocation semantics
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
7
Figure 5.7
The role of proxy and skeleton in remote method invocation
client server
remote
object A proxy for B skeleton object B
Request & dispatcher
for B’s class
Reply
servant
Remote Communication Communication Remote reference
reference module module module module
Implementation
Communication module: carry out the request-reply

protocol
Remote reference module: translating between local
and remote object references
Proxy: make RMI transparent to clients by behaving
like a local object to the invoker
Dispatcher: use method id to find the appropriate
method
Skeleton: implement the method interface, but its
actual duty is to unmarshal arguments and marshal
result
8
Implementation (con’t)
Remote object interfaces do not have constructors;

how a remote object can be created via its remote
interface?
Factory method: a method can be used to create a remote
object
⌧Recall how you can create a local object, their syntaxes are different
Activation: a remote object may be passivated to
save resources, and activated when one of its
methods is invoked
An object that is guaranteed to live between
activations of process is called a persistent object.
Figure 5.8 Role of client and server stub procedures in RPC in the context of
a procedural language
client process server process
Request
Reply
client stub server stub
procedure procedure
client service
program Communication Communication procedure
module module dispatcher
9
Distributed Garbage Collection
Goal: to reclaim the memory of unreferred objects

Reference count
A remote object has a list that maintains all the processes
have reference to itself
When a client process invoke its method for the first time,
the proxy will be created and inform the server to add the
client to the list
When the client’s GC notifies that the proxy of the server
is no longer reachable; the proxy will be deleted and
inform server to remove the client from the list
When the list is empty, the server’s GC will reclaim its
space unless it is referred by local objects
Events and notifications
Use of event: an object can react to a change

occurring in another object
Notifications of events are essentially asynchronous
and determined by the receivers
Publish-subscribe paradigm
Two main characteristics of distributed event-based
systems
Heterogeneous
⌧Event notifications can be used as means to coordinate two components
that are not designed to work together
Asynchronous
⌧Publishers and subscribers do not need to synchronize; they are
decoupled
10
Figure 5.10
Dealing room system
Dealer’s computer External Dealer’s computer

source
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
Figure 5.11
Architecture for distributed event notification
Event service
object of interest subscriber
1. notification
object of interest observer subscriber
2. notification notification
object of interest observer subscriber
3. notification
11
Distributed Event Notification
The object of interest: the object that experiences

changes of state as a result of its method being
invoked, and the change may be of interest to other
objects
Event: An event occurs at an object of interest as the
result of the completion of a method execution
Notification: an object that contains information
about an event
Subscriber: an object has subscribed to some type
of events in another object. It receives notifications
about such events
Distributed Event Notification (con’t)
Observer objects: Its main purpose is to decouple an

object of interest from its subscribers. Since a
subscribe may subscribe very complicated patterns
of events and then the object of interest needs to
implement the patterns for sending the notification,
such tasks could be done by observers and thus
decoupling them
Publisher: an object that will generate notifications of
events. It could be an object of interest or observer
12
Distributed Event Notification (con’t)
Event service: a set of objects that maintains a

database of published events and of subscriber’s
interests
Roles of observers
Forwarding
Filtering of notifications
Patterns of events
Notification mailboxes
13

Chapter 05

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 05

Uploaded by

Copyright:

Available Formats

Chapter 5:

Distributed objects and remote invocation

From Coulouris, Dollimore and Kindberg

RMI, RPC and events

External data representation

Remote method invocations

Remote Method Invocations

The object model

Objects have data and methods

Objects located in different processes, not

The Distributed Object Model

Remote object reference

The Distributed Object Model (con’t)

Fault tolerance measures Invocation

Retransmit request Duplicate Re-execute procedure

Yes Yes Retransmit reply At-most-once

Communication module: carry out the request-reply

Remote object interfaces do not have constructors;

client process server process

Goal: to reclaim the memory of unreferred objects

Events and notifications

Use of event: an object can react to a change

Dealer’s computer External Dealer’s computer

Dealer Notification Notification Dealer

object of interest observer subscriber

object of interest observer subscriber

The object of interest: the object that experiences

Distributed Event Notification (con’t)

Observer objects: Its main purpose is to decouple an

Event service: a set of objects that maintains a

You might also like