Figure 5.

1
Middleware layers
Slides for Chapter 5:
Distributed objects and remote invocation
Applications

From Coulouris, Dollimore and Kindberg

RMI, RPC and events

Distributed Systems:
Middleware
Request reply protocol layers
Concepts and Design External data representation
Edition 4, © Addison-Wesley 2005 Operating System

1 2

5.1 Introduction

Middleware Middleware (Cont’d)

Software that provides a programming model above the basic building Communication protocols: The protocols that support the middleware
blocks of processes and message passing. abstractions are independent of the underlying transport protocols.
An important aspect of middleware is the provision of location Computer hardware: External data representations are described in
transparency and independence from the details of communication last chapter.
protocols, operating systems, and computer hardware. Operating systems: The higher-level abstractions provided by the
middleware layer are independent of the underlying operating
Location transparency:
systems.
⌧In RPC, the client that calls a procedure cannot tell whether the procedure
runs in the same process or in a different process, nor does the client Use of several programming language: some middleware is designed
need to know the location of the server. to allow distributed applications to use more than one programming
⌧In RMI, the object making the invocation cannot tell whether the object it language.
invokes is local or remote.
⌧In distributed event-based programs, the objects generating events and
the objects that receive notifications of those events need not be aware of
one another's location.

3 4
5.1.1 Interfaces

An explicit interface is defined for each programming module in order to Interfaces in distributed systems:
control the possible interactions between modules. In a distributed program, the modules can run in separate processes.
The interface of a module specifies the procedures and the variables that It is not possible for a module running in one process to access the
can be accessed from other modules. variables in a module in another process – thus, the interface of a module
that is intended for RPC or RMI cannot specify direct access to variables.
Modules are implemented so as to hide all information about them except The specification of a procedure or method in the interface of a module in a
that which is available through its interface. distributed program describes the parameters as input or output.
Input parameters are passed to the remote module by sending the values of
the arguments in the request message and then supplying them as
arguments to the operation to be executed in the server.
Output parameters are returned in the reply message.
When a parameter is used for both input and output, the value must be
transmitted in both the request and reply messages.
Another different between local and remote modules is that pointers in one
process are not valid in another remote one.

5 6

Service interfaces: Interface definition languages:

In the client-server model, each server provides a set of procedures An RMI mechanism can be integrated with a particular programming
that are available for use by clients. language if it includes an adequate notation for defining interfaces –
The service interface is used to refer to the specification of the allowing input and output parameters to be mapped onto the
procedures offered by a server, defining the types of the input and language’s normal use of parameters.
output arguments of each of the procedures.

Remote interfaces:
In the distributed object model, a remote interface specifies the
methods 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.
The difference is that the methods in remote interfaces can pass
object as arguments and results of methods.
Reference to remote objects may also be passed.
7 8
Figure 5.2
CORBA IDL example 5.2 Communication between distributed objects

Address communication between distributed objects by

// In file [Link] means of RMI. The material is presented under the following
struct Person { headings
string name;
string place;
The object model
long year; Distributed objects
}; The distributed object models
interface PersonList {
readonly attribute string listname;
Design issues
void addPerson(in Person p) ; Implementation
void getPerson(in string name, out Person p); Distributed garbage collection
long number();
};

9 10

5.2.1 The object model

An object’s data should be accessible only via its methods. Actions:

Object references: Action in an object-oriented program is initiated by an object invoking
a method in another object.
Objects can be accessible via object reference.
An invocation can include additional information (arguments) needed
To invoke a method in an object, the object reference and method
to carry out the method.
name are given, together with any necessary arguments.
The receiver executes the appropriate method and then returns
The object whose method is invoked is called the target or receiver.
control to the invoking object.
Interfaces: An invocation of a method can have three effects:
Provides a definition of the signatures of a set of methods without ⌧The state of the receiver may be changed.
specifying their implementation. ⌧A new object may be instantiated.
⌧Further invocations on methods in other objects may take places.

11 12
 Exceptions: Garbage collection
Programs can encounter many sorts of errors and unexpected Necessary to provide a means of freeing the space occupied by
conditions of varying seriousness. objects when they are no longer needed.
Exceptions provide a clean way to deal with error conditions without This process is called garbage collection.
complicating the code. When a language does not support garbage collection, the
A block of code may be defined to throw an exception whenever programmer has to cope with the freeing of space allocated to objects.
particular unexpected conditions or error arise.
This means that control passes to another block of code that catches
the exception.
Control does not return to the place where the exception was thrown.

13 14

Figure 5.3
5.2.2 Distributed objects Remote and local method invocations

May adopt the client-server architecture.

Objects are managed by servers and their clients invoke their methods
using remote method invocation.
In RMI, the client’s request to invoke a method of an object is sent in a
message to the server managing the object. remote local C
local E
The invocation is carried out by executing a method of the object at the invocation invocation
remote
invocation
server and the result is returned to the client in another message. B
invocation F
A local
Can assume other architectural models. invocation D
E.g., objects can be replicated in order to obtain the usual benefits of fault
tolerance and enhance performance.
The fact that objects are accessed only via their methods gives
another advantage for heterogeneous systems in that different
formats may be used at different sites.

15 16
5.2.3 The distributed object model

Each process contains a collection of objects Remote object references:

Some of which can receive both local and remote invocations. Remote object reference is an identifier that can be used throughout a
The other objects can receive only local invocations. distributed system to refer to a particular unique remote object.
Method invocations between objects in different processes Remote object references are analogous to local ones in that:
are known as remote method invocations. ⌧The remote object to receive a remote method invocation is specified by
the invoker as a remote object references
Method invocations between objects in the same process are ⌧Remote object references may be passed as arguments and results of
local method invocations. remote method invocations.
Two fundamental concepts Remote interfaces:
Remote object reference: Other objects can invoke the methods of a The class of a remote object implements the methods of its remote interface.
remote object if they have access to its remote object reference. Objects in other processes can invoke only the methods that belong to its
Remote interface: Every remote objects has a remote interface that remote interface.
specifies which of its methods can be invoked remotely. Local objects can invoke the methods in the remote interfaces as well as
other methods implemented by a remote object.

17 18

Figure 5.4
A remote object and its remote interface

Actions in a distributed object system:

An action is initiated by a method invocation – which may result in
remoteobject further invocations on methods in other objects.
However, in the distributed case, the objects involved in a chain of
Data related invocations may be located in different processes or different
remote
computers.
interface
m1 m4
implementation When an invocation crosses the boundary of a process or computers,
{ m2
m3 of methods
m5
m6 RMI is used, and the remote reference of the object must be available
to the invoker.
When an action leads to the instantiation of a new object, that object
will normally live within the process where instantiation is requested.
Distributed applications may provide remote objects with methods for
instantiating objects which can be accessed by RMI.

19 20
Figure 5.5 Instantiation of remote objects

Garbage collection in a distributed-object system:

If a language supports garbage collection, then any associated RMI
L
system should allow garbage collection of remote objects.
C K
remote instantiate instantiate remote Distributed garbage collection is generally achieved by cooperation
invocation invocation
between the existing local garbage collector and an added module
M N that carries out a form of distributed garbage collection.
If garbage collection is not available, then remote objects that are no
longer required should be deleted.
Exceptions:
Any remote invocation may fail for reasons related to the invoked
object being in a different process or computer from the invoker.
Remote method invocation should be able to raise exceptions.

21 22

Figure 5.6
5.2.4 Design issues for RMI Invocation semantics

RMI is a natural extension of local method invocation.

RMI invocation semantics:
Fault tolerance measures Invocation
Request-reply protocols where doOperation can be implemented in different semantics
ways to provide different delivery guarantees.
⌧Retry request message: whether to retransmit the request message until
either a reply is received or the server is assumed to have failed. Retransmit request Duplicate Re-execute procedure
message filtering or retransmit reply
⌧Duplicate filtering: when retransmissions are used, whether to filter out
duplicate requests at the server. No Not applicable Not applicable Maybe
⌧Retransmission of results: whether to keep a history of result messages to
enable lost results to be retransmitted without re-executing the operations Yes No Re-execute procedure At-least-once
at the server.
Yes Yes Retransmit reply At-most-once
Combinations of these choices lead to a variety of possible semantics
for the reliability of remote invocations as seen by the invoker (Fig 5.6)

23 24
Maybe invocation semantics: At-least-once invocation semantics:
the remote method may be executed once or not at all. The invoker receives either a result or an exception informing it that no
Maybe semantics arises when none of the fault tolerance measures is result was received.
applied. Can suffer from the following types of failure:
Can suffer from the following types of failure: ⌧Crash failures when the server containing the remote object fails.
⌧Omission failure, if the invocation or result message is lost: ⌧Arbitrary failures. In cases when the invocation message is retransmitted,
⌧Crash failure, when the server containing the remote object fails. the remote object may receive it and execute the method more than once,
possibly cause wrong values to be stored or returned.
Maybe semantics is useful only for applications in which occasional
failed invocations are acceptable.
At-most-once invocation semantics:
The invoker receives either a result or an exception informing it that no
result was received, in which case the method will have been
executed either once or not at all.

25 26

Figure 5.7
The role of proxy and skeleton in remote method invocation

Transparency
Remote invocations should be made transparent in the sense that the server
syntax of a remote invocation is the same as that of a local invocation, client
remote
but that the difference between local and remote objects should be object A proxy for B skeleton object B
Request & dispatcher
expressed in their interfaces.
for B’s class

Reply

servant
Remote Communication Communication Remote reference
reference module module module module

27 28
5.2.5 Implementation of RMI

Figure 5.7 Remote reference module

Communication module Responsible for translating between local and remote object
references and for creating remote object references.
The two cooperating communication modules carry out the request-
reply protocol. The remote reference module in each process has a remote object
table that records the correspondence between local object references
The communication module in the server selects the dispatcher for the
in that process and remote object references.
class of the object to be invoked, passing on its local reference, which
it gets from the remote reference module in return for the remote The actions of the remote reference module are as follows:
object identifiers in the request message. ⌧When a remote object is to be passed as argument or result for the first
time, the remote reference module is asked to create a remote object
reference, which it adds to its table.
⌧When a remote object reference arrives in a request or reply message,
the remote reference module is asked for the corresponding local object
reference, which may refer either to a proxy or to a remote object.
This module is called by components of the RMI software when they
are marshalling and unmarshalling remote object references.

29 30

Servants The RMI software

A servant is an instance of a class which provide the body of a remote Consists of a layer of software between the application-level objects
object. and the communication and remote reference modules.
Handles the remote requests passed on by the corresponding skeleton. The roles of the middleware objects are as follows:
Live within a server process. ⌧Proxy – to make remote method invocation transparent to clients by
behaving like a local object to the invoker; instead of executing an
Created when remote objects are instantiated and remain in use until they
invocation, it forwards it in a message to a remote object.
are no longer needed.
⌧Dispatcher – A server has one dispatcher and skeleton for each class
Finally, being garbage collected or deleted. representing a remote object.
⌧Skeleton – the class of a remote object has a skeleton, which implements
the methods in the remote interface. A skeleton method unmarshals the
arguments in the request message and invokes the corresponding method
in the servant.

31 32
Generation of the classes for proxies, dispatchers, and The binder:
skeletons --- are generated automatically by an interface A binder in a distributed system is a separate service that maintains a
compiler. table containing mappings from texture names to remote object
references.
Server and client programs
It is used by servers to register their remote objects by name and by
The server program contains the classes for the dispatchers and clients to look them up.
skeletons, together with the implementations of the classes of all of
the servants that it supports. Server threads:
In addition, the server program contains an initialization section – for Whenever an object executes a remote invocation, that execution may
creating and initializing at least one of the servants to be hosted by the lead to further invocations of methods in other remote objects – which
server. may take some time to return.
The client program will contain the classes of the proxies for all of the To avoid the execution of one remote invocation delaying the
remote objects that it will invoke. execution of another, servers generally allocate a separate thread for
the execution of each remote invocation.

33 34

Activation of remote objects Activation of remote objects (cont’d)

Some applications require that information survive for long periods of Activation consists of creating an active object from the corresponding
time. However, it’s not practical for the objects representing such passive object by creating a new instance of its class and initializing its
information to be kept in running processes for unlimited periods. instance variables from the stored state.
To avoid the potential waste of resources, the servers can be started An activator is responsible for
whenever they are needed by clients. ⌧Registering passive objects that are available for activation.
Processes that start server processes to host remote objects are ⌧Starting named server processes and activating remote objects in them.
called activators for the following reasons. ⌧Keeping track of the locations of the servers for remote objects that it has
⌧A remote object is described as active when it is available for invocation already activated.
within a running process.
⌧It is called passive if it is not currently active but can be made active.
A passive object consists of two parts
⌧The implementation of its methods
⌧Its state in the marshalled form.

35 36
 5.2.6 Distributed garbage collection

Object location Aim: to ensure that if a local or remote reference to an object is still held
A location service helps clients to locate remote objects from their anywhere in a set of distributed objects, then the object itself will continue
remote object references. to exist, but as soon as no object any longer holds a reference to it, the
Use a database that maps remote object references to their probable object will be collected and the memory it uses recovered.
current locations – the location are probable because an object may
have migrated again since it was last heard of.

37 38

Figure 5.8 Role of client and server stub procedures in RPC in the context of
a procedural language 5.3 Remote procedure call

Very similar to an RMI in that a client program calls a procedure in another

program running in a server process.
Servers may be clients of other servers to allow chains of RPCs.
client process server process However, it lacks the ability to create new instances of objects and therefore
does not support remote object references.
Request
RPC may be implemented to have one of the choices of invocation semantics
discussed in Sec 5.2.4 – at-least-once or at-most-once are generally chosen.
Reply
client stub server stub Generally implemented over a request-reply protocol.
procedure procedure
client service This software is similar to RMI except that no remote reference modules are
program Communication Communication procedure
module module dispatcher required, since procedure call is not concerned with objects and object
references.

39 40
 Figure 5.10
Dealing room system

The client that accesses a service includes one stub procedure for each Dealer’s computer External Dealer’s computer
source
procedure in the service interface. It behaves like a local procedure to the
client, but instead of executing the call, it marshals the procedure identifier and Dealer Notification Notification Dealer
the arguments into a request message – which it sends via its communication
Information
module to the server. Notification
provider Notification

When the reply message arrives, it unmarshals the results.

The server process contains a dispatcher together with one server stub Notification
Notification
Notification
procedure and one service procedure for each procedure in the service Dealer’s computer Dealer’s computer
interface. Notification

The dispatcher selects one of the server stub procedures according to the Information
provider
procedure identifier in the request message. Notification
Dealer Notification
A server stub procedure is like a skeleton method in that it unmarshals the Dealer
arguments in the request message, calls the corresponding service procedure, External
source
and marshals the return values for the reply message.

41 42

5.4 Events and notifications

The idea behind the use of events is that one object can react to a Use the publish-subscribe paradigm
change occurring in another object. An object that generates events publishes the types of events that are of
interest to them.
Notifications of events are essentially asynchronous and determined by Different event types may refer to the different methods executed by the
their receivers. object of interest.
Distributed event-based systems extend the local event model by allowing Objects that represent events are called notifications.
multiple objects at different locations to be notified of events taking place When a publisher experiences an event, subscribes that expressed an
at an object. interest in that type of event will receive notifications.
Subscribing to a particular type of event is called registering interest in that
type of event.

43 44
Distributed event-based systems have two main characteristics Event types:
Heterogeneous: An event source can generate events of one or more different types.
⌧When event notifications are used as a means of communication between Each event has attributes that specify information about that event, such as
distributed objects, components in a distributed system that were not the name or identifier of the object that generated it, the operations, its
designed to interoperate can be made to work together. All that is parameters, and the time.
required is that event-generating objects publish the types of events they Types and attributes are used both in subscribing to events and in
offer, and that other objects subscribe to events and provide an interface notifications.
for receiving notifications.
Asynchronous:
⌧Notification are sent asynchronously by event-generating objects to all the
objects that have subscribed to them to prevent publishers needing to
synchronize with subscribers.

45 46

Figure 5.11
Architecture for distributed event notification 5.4.1 The participants in distributed event notification

Figure 5.11 shows an architecture that specifies the roles played by

Event service
the objects that participate in distributed event-based systems.
object of interest subscriber
The main component is an event service that maintains a database
1. notification of published events and of subscribes’ interests.
object of interest observer subscriber

2. notification notification

object of interest observer subscriber

3. notification

47 48
The roles of the participating objects are as follows: Figure 5.11 shows three cases:
The object of interest: an object that experiences changes of state, as a An object of interest inside the event service without an observer. It sends
result of its operations being invoked and is considered as part of the event notifications directly to the subscribers.
service if it transmits notifications. An object of interest inside the event service with an observer. The object of
Event: an event occurs at an object of interest as the result of the interest sends notifications via the observer to the subscribers.
completion of a method execution. An object of interest outside the event service. In this case, an observer
Notification: is an object that contains information about an event. Typically, queries the object of interest in order to discover when events occur. The
it contains the type of the event and its attributes. observer sends notifications to the subscribers.
Subscriber: is an object that has subscribed to some type of events in
another object. Delivery semantics:
Observer objects: to decouple an object of interest from its subscribers. A variety of different delivery guarantees can be provided for notifications –
Publisher: an object that declares that it will generate notifications of the chosen one should depend on the requirements of applications.
particular types of event. A publisher may be an object of interest or an
observer.

49 50

Roles for observers

The task of processing notification can be divided among observer
processes playing a variety of different roles. E.g.,
⌧Forwarding –carry out all the work of sending notifications to
subscribers on behalf of one or more objects of interest.
⌧Filtering of notifications – to reduce the number of notifications received
according to some predicate on the contents of each notification.
⌧Patterns of events – A pattern specifies a relationship between several
events.
⌧Notification mailboxes – in some cases, notifications need to be
delayed until a potential subscriber is ready to receive them.

51