Chapter 4:
Distributed Objects &
Remote Invocation
Distributed Objects & Remote
Invocation
Introduction
Communication between
distributed objects
Remote procedure call
Events & notification
Objectives
To study communication between distributed
objects and the integration of remote method
invocation into a programming language.
To explore the extension of the event-based
programming model in order to apply to
distributed event-based programs.
Introduction
Introduced communication between
distributed objects by means of remote method
invocation (RMI)
Objects that can receive remote method
invocation are called remote objects
~ implement a remote interface
RMI have different semantic from local call
because of possibility of independent failure of
invoker & invoked objects
Remote procedure call ~ RMI as procedure call
to object invocation
Introduction (cont).
Concern with programming model in DS:
Remote procedure call model:
~allow client program to call procedure in
server program running in separate process
and generally in different computer from
client.
Object based programming model:
~ allow objects in different processes to
communicate with one another by means
of RMI.
Introduction (cont).
Remote method invocation (RMI)
- extension of local method invocation
- allows an object living in one process to
invoke the methods of an object living in
another process
Introduction (cont).
Distributed event-based programming
model:
~ allow objects to subscribe to event
occurring at remote objects of interest & in
turn to receive notifications when such event
occur.
~ events and notification provide a way for
heterogeneous objects to communicate with
one another asynchronously.
Figure 5.1
Middleware layers
Applications
RMI, RPC and events
Request reply protocol
Middleware
layers
External data representation
Operating System
Software that provides a programming model
above the basic building blocks of processes and
message passing is called middleware.
Middleware Programming Models
Distributed objects & remote object invocation
is model explained as illustrated by Java RMI
CORBA:
~ it provides remote object invocation
between a client program written in one
language and a server program written in
another language
~ another language commonly used is C++
Other programming models
~ remote event notification
~ remote SQL access
~ distributed transaction processing
Interface
To control the possible interactions between
module-explicit interface is designed for each
module.
Specifies the procedures and variables that
can be access from other module.
2 types of interface in DS :
Service interfaces
~ Used in client-server model
~ Refer to the specification of procedures offered by server
and define input and output arguments.
~ Each server provides a set of procedures for client use
Fig. 5.2: CORBA IDL Example
struct Person {
string name;
string place;
CORBA has a
remote interface
long year;
struct
};
interface PersonList {
remote interface
readonly attribute string listname;
defines methods for
void addPerson(in Person p) ;
RMI
void getPerson(in string name, out
Person p);
long number();
parameters are in, out or inout
};
Remote interface:
~ specifies the methods of an object available for remote invocation
~ Can pass object as arguments and result of methods
~ an interface definition language (or IDL) is used to specify remote
interfaces. Ex: the above in CORBA IDL.
~Java RMI have a class for Person, but CORBA has a struct
Communication
Between Distributed
Object Model
Communication between
Distributed Object
Object based model for DS extend oriented programming
language to make it apply the to distributed objects.
We address communication between distributed objects by
mean RMI.
The material is presented under:
~ the object model
~ distributed objects
~ the distributed object model
~ design issue
~implementation
~ distributed garbage collection
Communication between
Distributed Object (Cont.)
Object Model
Communicate with other by invoking their methods
Can encapsulate(summarize) their data and code
Consists of collection of interacting object :
- Object references
- object can be accessed via object ref.
- first class values, assigned to variables, pass as arguments,
and return as result.
- Interfaces
- definition of the signatures of a set of methods without
specifying their implementation.
- object provide interface if its class contains code that
implement the method of that interface.
Communication between
Distributed Object (Cont.)
- Action
- is initiated by an object invoking a method in a another
object.
- Invocation included additional info needed to carry out the
method.
- Exception
- provide the clean way to deal with error without
complicating the code.
- throw and catches – define a block of code
- Garbage collection
- freeing the space occupied by object when they are no
longer needed.
Communication between
Distributed Object (Cont.)
Distributed object:
~ the state of an object consist of the value of its intense
value.
~ adopt the client server architecture
~ objects are managed by server
~ clients invoke method by using RMI
~ in RMI, client’s request to invoke a method of an object is
sent in a message to the server managing the object.
~ execute method of object at server – result is return to
client in a another message
~ object in server are allowed to become client of object in
other server.
Communication between
Distributed Object (Cont.)
The distributed object model:
~each process contains a collection of object.
~can receive both ; local & remote invocation.
RMI = method invocation between object in different
process, whether in comp or not
LMI = method invocation between object in same process
Fig. 5.3: Remote & local method invocations
remote
invocation
local
C
invocation
local E
invocation
A
B
remote
invocation
F
local
invocation
D
each process contains objects, some of which can receive remote
invocations, others only local invocations
those that can receive remote invocations are called remote objects.
- Object B and F are remote object.
- Object C must have reference to object E to invoke their methods.
objects need to know the remote object reference of an object in another
process in order to invoke its methods.
- A remote object for B must be available to A.
remote interface specifies which methods can be invoked remotely.
- Object B and F must have remote interface.
Communication between
Distributed Object (Cont.)
-
Remote Interface
specifies the methods of an object that are available for invocation
by remote objects in other processes.
Interface definition languages (or IDLs) are designed to allow objects
in different languages to invoke one another.
Object in other process can remote only the method belong to it
remote interface.
The semantics of parameter passing are adjusted to suit the
separation of client and remote object.
Input and output parameters are used, and pointers cannot be
passed.
Communication between
Distributed Object (Cont.)
-
-
Remote Object
Object that can receive remote invocations.
one that can be invoked from another process.
Remote Object Reference
an identifier for a remote object
used to refer to a particular remote invocation.
Diff from local object references.
can be passed as an argument or result of a remote invocation.
clients need it in order to invoke remote objects.
may be obtained from a binder or as the result of an RMI.
Fig. 5.4: A remote object & its remote interface
remoteobject
remote
interface
{
m1
m2
m3
Dat
a
implementation
of methods
m4
m5
m6
-Object in other processes can invoke only the methods that
belong to it remote interface
Communication between
Distributed Object (Cont.)
Actions in distributed object system:
- Object involved in a chain of related invocations may be
located in different process or different computer
- When invocation crossed boundary of a process or
computer, RMI is used and remote references of the object
must available to invoker.
-
Object A needs to hold a remote object reference to
object B.(refer to Fig 5.3)
Object A may obtain a remote reference to object F from
object B.(refer to Fig 5.3)
Fig. 5.5: Instantiation of remote objects
L
C
remot e
invocation
instant iate
M
instant iate
remot e
invocation
K
N
Distributed application may provide remote object with method for
instantiating objects which can be accessed by RMI.
Example:
~ Object L contains a method for creating remote object
~ Remote invocation from method C and K could lead to instantiation of
the object M and N respectively.
Communication between
Distributed Object (Cont.)
Garbage collection distributed object system:
- Allow garbage collection of remote object
- Cooperating existing local garbage collector & added module.
Exception:
- process contains remote object – crashed/to busy/result message
lost
-must be able to raise exception.
Design issues for RMI
 The choices of invocation semantic
 The level of transparency that is
desirable for RMI
RMI Invocation Semantics
Apply request-reply protocol.
DoOperation implemented in different way to provide different
delivery guarantees are:
Retry request message – retransmit the request message until
either a reply is received or the server is assumed to have
failed
Duplicate filtering – when retransmission, it filter out duplicate
request at server.
Retransmission of result – keep history of result message, to
enable lost result to be retransmitted without executing the
operation at server.
Fig. 5.6: Invocation Semantics
Fault tolerance measures
Retransmit request
message
Duplicate
filtering
Invocation
semantics
Re-execute procedure
or retransmit reply
No
Not applicable Not applicable
Maybe
Yes
No
Re-execute procedure At-least-once
Yes
Yes
Retransmit reply
At-most-once
Local invocations are executed exactly once
The Request-reply protocol can apply fault-tolerance measures
Invocation Semantics:
Failure Model
Maybe, At-least-once and At-most-once can suffer from crash failures
when the server containing the remote object fails.
Maybe
- remote method my be executed once or not at all
- arise when none of the fault tolerance measures is applied
- if no reply, the client does not know if method was executed or not
~ omission failures if the invocation or result message is lost
- no retries after timeout
~ 2 situation (invocation message lost, method not executed or
method
executed, result message lost) give impact to crash failure.
- use fro apps which occasional failed invocation acceptable
Invocation Semantic: Failure Model
At-least-once
- the client gets a result (and the method was executed at least once) or an
exception (no result)
- suffer from arbitrary failures. If the invocation message is retransmitted, the
remote object may execute the method more than once, possibly causing
wrong values to be stored or returned.
- if idempotent operations are used, arbitrary failures will not occur
- idempotent operations, one that can be performed repeatedly with the
same effect although it have perform exactly once.
- use in Sun RPC
At-most-once
- the client gets a result (and the method was executed exactly once) or an
exception (instead of a result, in which case, the method was executed
once or not at all)
- achieved by using all fault tolerance measure
~ prevent arbitrary failure – ensure each RMI method execute only once.
- applied in JAVA RMI and CORBA, but CORBA allows maybe – requested
method that do return result.
Call semantics cannot be
`exactly once'. The
semantics achieved (e.g. `atmost-once') depends on the
approach to dealing with
failures of processes and
communication.
Transparency
originator aimed to make RPC same as LPC
Hide marshalling, message passing, task of locating and
contacting a remote object
RMI more vulnerable to failure than local invocation .Why?
RMI latency is greater than local- to minimize, caller able to
abort RPC that taking a lot of time.
To differentiate the syntax of RMI with LMI
Implementation of RMI
 Roles of components that involve in
implementation of RMI
Implementation of RMI(cont.)
Communication Module
- Define the client and the server
- Use only first 3 items – specify msg type, requestID and remote
reference.
- Responsible to provide a specified invocation semantics
Remote reference module
- responsible to translate between local and remote object
references
- create remote object reference
- each process have remote object table
Implementation of RMI(cont.)
Servant
- an instance of class which provide the body of remote object
- handles the remote request pass and live within a server
process
- deleted after being used.
The RMI software
- consist a layer of software between apps level objectcommunication- remote reference modules
- Proxy
~ make RMI transparent to client- behave like local object
and hide details
- Dispatcher
~ receive request msg from comm. module
~ use methodID to select appropriate method in skeleton
Fig. 5.7: The role of proxy & skeleton in remote
method invocation
server
client
object A proxy for B
Request
skeleton
& dispatcher
for B’s class
remote
object B
Reply
Communication
Remote
reference module
module
Communication Remote reference
module
module
Proxy - makes RMI transparent to client. Class RMI software carries out Requestimplements remote interface.
Marshals
between application
reply protocol
requests & unmarshals results.Forward request
Dispatcher
- gets
request
fromand
communication
Skeleton
- implements
methods
in remote interface.
translates
between
local
module
and
invokes
method
inand
skeleton
(using
Unmarshals
requests
and marshals
results.
Invokes
remote
object
references
methodID
in
message).
method
in remote
object.
creates
remote
object references.
Uses remote object table
level objects
&communication &
remote reference
modules
Distributed Garbage
Collection
To ensure a local or remote reference to an object remain exist
if still in use
As soon no object any longer hold a reference to it, the object
will be collected and memory uses is recovered.
Remote Procedure Call
 Very similar to remote method
invocation
 Generally implemented in request-reply
protocol
 Client program calls a procedure in
another program running in server process
Its service interface have lack of ability to
create new instance of object – do not
support remote object references
Implemented over request –reply
protocol- same content but object
reference field is omitted(lost).
Remote Procedure Call
Client Stub procedure
- Similar to proxy method
- Behave like local procedure to client
- Marshall procedure identifier and the argument in request
msg
Server stub procedure
- similar to skeleton method
- unmarshals argument in the request msg, call coresponding
service procedure and marshal return value for reply msg
Fig. 5.8: Role of client & server stub procedures in
RPC in the context of a procedural language
client process
server process
Request
Reply
client stub
procedure
client
program
server stub
procedure
Communication
module
Communication
dispatcher
module
service
procedure
Events And Notification
Distributed event-based systems
- use the publish-subscribe paradigm
- event-generating object publishes type of events that will be
available for other objects.  Generally implemented in requestreply protocol
- Object that receive notification of publishes event subscribe the types
of their interest event.
- 2 main characteristics:
i) heterogeneous; ii) asynchronous
- useful for communication between heterogeneous components
- their asynchronous nature allows publishers and subscribers to be
decoupled.
Fig. 5.10: Dealing Room System
Dealer’s computer
Dealer
Dealer’s computer
External
source
Notification
Notification
Information
provider
Notification
Notification
Dealer
Notification
Notification
Notification
Dealer’s computer
Dealer’s computer
Notification
Information
provider
Notification
Notification
Dealer
Dealer
External
source
The figure shows an example of distributed event-based systems.
Dealing Room System
- Allows user to see the latest info about the market price
- Market price are represent by an object with instance variables.
- Info have been updated and collected by information provider.
- 2 different task create here :
i. - information provider update to the appropriate stock object
- update to stock object regards as an event
- notify all the dealer who have subscribe
- for each external source there will be separate info provider
process
ii. - dealer create object to represent named stock
- local object subscribe to the relevant info provider object
- receive info sent to it in notification and display to user
Fig. 5.11: Architecture for distributed event notification
Event service
subscriber
object of interest
1.
notification
object of interest
2.
object of interest
3.
notification
observer
subscriber
notification
observer
subscriber
notification
Distributed event notification
•The object of interest – an object that experience change of state
•Event – occur at an object of interest as the result of completion of
method execution
•Notification – an object that contain info about an event
•Subscriber - an object that subscribe to some type of event in another
object.
•Observer object – to decouple an object of interest of its subscriber.
•Publisher – declare it will generate notification of particular types of an
event. can be object of interest or an observer.
1. An object of interest inside the event service without an observer. It
send notifications directly to the subscribers.
2. inside the event service with an observer. The object interest send
notification via observer.
3. outside the an event service. observer queries the object of interest
to discover when event occur and observer sends notification