Chapter 2(Part 1)

Distributed Objects and File System

Chapter Outline
2.1 Introduction 2.6 Introduction to DFS

2.2 Communication between distributed objects 2.7 File Service Architecture

2.3 Remote Procedure Call 2.8 Sun Network File System

2.4 Events And Notifications 2.9 Introduction to Name Services

2.10 Name Services and DNS

2.5 Java RMI Case Study
2.11 Directory and Discovery Services

2.12 Comparison of Different Distributed File Systems

2.1 Introduction
● Concerned with programming models for distributed applications - that is, those
applications that are composed of cooperating programs running in several
different processes.
● Such program need to be able to invoke operations in other processes, often
running in different computers.
● To achieve this , some familiar programming models have been extended to apply to
distributed systems:
➔ Earliest, was the extension of the conventional procedure call model to the remote
procedure call model, which allows client programs to call procedures in server
programs running in separate processes and generally in different computers from
the client.
2.1 Introduction
➔ In the 1990s, object-based programming model was extended to allow objects
in different processes to communicate with one another by means of remote
method invocation(RMI). RMI is 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 programming model allows objects to receive notification of the
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.
● The middleware layer uses protocols based on messages between processes
to provide its higher-level abstractions such as remote invocations and events.
● For example, the remote method invocation abstraction is based on the
request-reply protocol.
● An important aspect is the provision of location transparency and
independence from the details of communication protocols, operating
systems and computer hardware.
Middleware
Middleware
Location Transparency:
● In RPC, the client that calls a procedure cannot tell whether the procedure
runs in the same process or in different process , possibly on a different
computer. Nor does the client need to know the location of the server.
● Similarly, in RMI the object making the invocation cannot tell whether the
object it invokes is local or not and does not need to know its location.
● Also in distributed event-based programming, the object generating events
and the objects that receive notifications of those events need not be aware of
one another’s locations.
Middleware
Communication Protocols:
● The protocols that support the middleware abstractions are independent of the underlying
transport protocols.
● For example, the request-reply protocol can be implemented over either UDP or TCP.
Computer Hardware:
● An agreed standard for the representation of data structures and primitive values is called an
external data representation.
● These are used when marshalling and unmarshalling messages.
● They hide the differences due to hardware architectures , such as a byte ordering.
Middleware
Operating Systems:
● The higher-level abstraction provided by the middleware layer are independent of the
underlying operating system.
Use of several programming languages:
● Some middleware is designed to allow distributed applications to use more than one
programming language.
● For example, CORBA. It allows clients written in one language to invoke methods in objects
that live in server programs written in another language. This is achieved by using an
interface definition language or IDL to define interfaces.
Interfaces
● In order to control the possible interactions between modules, an explicit
interface is defined for each module.
● The interface of a module specifies the procedures and the variables that can
be accessed from other modules.
Interfaces in distributed systems
● The parameter-passing mechanisms, for example call by value and call by
reference, used in local procedure call are not suitable when the caller and
procedure are in different processes.
● The specification of a procedure or program describes the parameters as
input or output or sometimes both.
● When the parameter for both input and output, the value must be transmitted
in both the request and reply messages.
● Another difference between local and remote modules is that pointers in one
process are not valid in another remote one.
Interfaces in distributed systems
Service interfaces:
● The term service interface is used to refer to the specification of the procedures offered by
a server, defining the types of the input and output arguments of each of the procedures.
● For example, a file server would provide procedures for reading and writing files.
● It is used in client-server model.
Remote interfaces:
● In distributed object model, a remote interface specifies the methods of an object that are
available for innovation by objects in other processes, defining the types of the input and
output arguments of each of them.
Interface definition languages
● An RMI mechanism can be integrated with a particular programming language
if it includes an adequate notation for defining interfaces, allowing input and
output parameters to be mapped onto the language’s normal use of
parameters.
● Java RMI is an example in which an RMI mechanism has been added to an
object-oriented programming language.
● This approach is useful when all the parts of a distributed application can be
written in the same language.
● It is also convenient because it allows the programmer to use a single
language for local and remote invocation.
●
Interface definition languages
● However, many existing useful services are written in C++ and other
languages.
● It would be beneficial to allow programs written in a variety of languages,
including Java, to access them remotely.
● Interface definition languages(or IDLs) are designed to allow objects
implemented in different languages to invoke one another.
● An IDL provides a notation for defining interfaces in which each of the
parameters of a method may be described as for input or output in addition
to having its type specified.
Common Object Request Broker Architecture (CORBA) IDL example
Interface definition languages
● Person structure with different data types.
● Interface PersonList specifies the methods available for RMI in a remote
object that implements that interface.
● The method addPerson() specifies its argument as in, meaning that it is an
input argument.
● The method getPerson that retrieves an instance of Person by name specifies
its second argument as out, meaning that it is an output argument.
Interface definition languages
● Other examples include the interface definition language for the RPC system in
the OSF’s Distributed Computing Environment (DCE) [OSPF 1997] here ,
which uses C language syntax and is called IDL.
● DCOM IDL which is based on DCE IDL [Box 1998] here and is used in
Microsoft’s Distributed Component Object Model.
2.2 Communication between distributed
objects
● Distributed Applications are composed of cooperating programs running in
several different processes.
● Such program need to be able to invoke operations in other processes, often
running in different computers.
● Distributed objects are a concept in computer science where objects, which
are units of code containing both data and the methods that operate on that
data, are distributed across different systems in a network.
● This allows these objects to communicate and collaborate with each other,
even though they may be running on separate machines.
2.2 Communication between distributed
objects
● An object oriented program consists of a collection of interacting objects,
each of which consists of a set of data and a set of methods.
● An object communicates with other objects by invoking their methods,
generally passing arguments and receiving results.
● Object can encapsulate their data and the code of their methods.
Distributed Object Model
● Each process contains a collection of objects, some of which can receive both
local and remote invocations.
● Methods invocations between objects in different processes, whether in the
same computer or not, are known as remote method invocations.
● Method invocations between objects in the same process are local method
invocations.
● We refer to objects that can receive remote invocations as remote objects.
 Remote Invocation Local
Invocation Object C
Object A
Object B
Local
Object D
Invocation

Remote Invocation

Object E

Fig. Remote and local method invocations

Distributed Object Model
Remote Object References:

● The notion of object reference is extended to allow any object that can receive
an RMI to have a remote object reference.
● A remote object reference is an identifier that can be used throughout a
distributed system to refer to a particular unique remote object.
● Other objects can invoke the methods of a remote object if they have access
to its remote object reference. For example, a remote object reference for B
in figure must be available to A.
Distributed Object Model
Remote Interfaces:

● Every remote object has a remote interface that specifies which of the
methods can be invoked remotely.
● For example, the object B and E must have remote interfaces.
● Objects in other processes can invoke the methods that belong to it’s in the
remote interface.
 Remote Object
Object
A Object A

Data

M4
M1 Implementation
M5
Remote M2 of methods
interface M6
M3

Fig. A remote object and its remote interface

Distributed Object Model
Actions
● Action in an object oriented program is initiated by an object invoking a
method in another object.
● An invocation can include additional information(arguments) needed to carry
out the method.
● The receiver executes the appropriate method and then returns control to
the invoking object , sometime supply the result.
● As an invocation can lead to further invocations of methods in other objects,
an action is a chain of related method invocations, each of which eventually
returns.
Distributed Object Model
Actions
● The objects involved in a chain of related invocations may be located in
different processes or different computers.
● When an invocation crosses the boundary of a process or computer, RMI is
used, and the remote reference of the object must be available to the
invoker.
● When an action is instantiation of a new object, that object will normally live
within the process where instantiation is requested.
● If newly instantiated object has a remote interface, it will be a remote object
with a remote object reference.
Distributed Object Model
Exceptions:
● Program can encounter many sorts of errors and unexpected conditions of
varying seriousness.
● Any remote invocations may fail for reasons related to the invoked object
being in a different process or computer from the invoker.
● For example, the process containing the remote object may have crashed or
may be too busy to reply, or the invocation or result message may be lost.
● Therefore, remote method invocation should be able to raise exceptions such
as timeouts that are due to distribution as well as those raised during the
execution of the method invoked.
Distributed Object Model
Garbage Collection:

● It is necessary to provide a means of freeing the space occupied by object

when they are no longer needed.
● A language, for example Java, that can detect automatically when an object is
no longer accessible recovers the space and makes is available for allocation
to other objects. This process is called garbage collection.
Distributed Object Model
Garbage Collection:

● If any language supports garbage collection, then associated RMI system

should allow garbage collection of remote objects.
● Distributed garbage collection is generally achieved by cooperation between
the existing local garbage collector and an added module that carries out a
form of distributed garbage collection, usually based on reference counting.
Design issues for RMI
● The choice of invocation semantics - although local invocations are executed
exactly once, this cannot always be the case for remote method invocations.
● The level of transparency that is desirable for RMI.
RMI Invocation Semantics
● Request-reply protocols, methods can be implemented in different ways to
provide different delivery guarantee, for fault tolerance measures as follows:
● Retry request message: whether to retransmit the request message until
either a reply is received or ther server is assumed to have failed.
● Duplicate filtering: when retransmissions are used, whether to filter out
duplicate request at the server.
● Retransmission of results: whether to keep a history of result messages to
enable lost results to be retransmitted without re-executing the operations at
the server.
● For local method invocations, the semantics are exactly once, meaning that
every method is executed exactly once.
RMI Invocation Semantics
The choices of RMI invocation semantics are defined as follows:
Maybe invocation semantics:
● With maybe invocation semantics, the remote method may be executed once
or not at all.
● Maybe semantics arises when none of the fault tolerance measures is
applied .
● This can suffer omission errors, crash failures.
● Maybe semantics is useful only for applications in which occasional failed
invocations are acceptable.
● Example: CORBA
RMI Invocation Semantics
The choices of RMI invocation semantics are defined as follows:

At-least-once invocation semantics:

● With at-least-once invocation semantics, the invoker receives either a result ,

in which case invoker knows that the method was executed at least once , or
an exception informing it that no result was received.
● Can be achieved by retransmission of request messages, which masks the
omission failures of the innovation or result message.
● Can suffer crash failures, arbitrary failures(multiple execution).
● Example: Sun RPC
RMI Invocation Semantics
The choices of RMI invocation semantics are defined as follows:
At-most-once invocation semantics:
● With at-most-once invocation semantics, the invoker receives either a result ,
in which case invoker knows that the method was executed at least once , 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.
● Can be achieved by using all of the fault tolerance measures.
● Prevents arbitrary failures by ensuring that for each RMI a method is never
executed more than once.
● Example : Java RMI, CORBA
Transparency
In the context of RMI (Remote Method Invocation), transparency issues primarily
refer to the ability of RMI to make distributed computing appear as if it were local.

Network Transparency:

● RMI aims to hide the complexities of network communication from the

developer, making remote method calls feel like local method calls.
● However, network latency, reliability, and bandwidth limitations can impact
the performance and reliability of RMI.
Transparency
Location Transparency:
● RMI abstracts the location of objects, allowing clients to invoke methods on remote
objects without needing to know their physical location.
● However, if the network topology changes or if there are issues with naming and
directory services, locating remote objects can become challenging, leading to
transparency issues.
Access Transparency:
● RMI aims to provide a seamless mechanism for accessing remote objects, hiding the
details of communication and access mechanisms from the developer.
● However, security configurations, authentication, and authorization mechanisms can
introduce complexities that may affect access transparency.
Transparency
Concurrency Transparency:

● RMI does not inherently handle concurrency issues such as concurrent method invocations
or synchronization across distributed objects.
● Developers need to ensure proper synchronization mechanisms to maintain consistency and
avoid race conditions, which can impact the transparency of concurrent operations.

Failure Transparency:

● RMI provides mechanisms for handling remote object failures, such as remote exceptions
and retries.
● However, handling failure scenarios gracefully and maintaining the illusion of transparency
can be challenging, especially in the presence of network partitions, transient failures, or
server crashes.
Implementation of RMI
● Several separate object and modules are involved in achieving a remote
method invocation.
● Remote Method Invocation (RMI) is a distributed computing protocol that
allows a client to invoke methods on objects that exist in another address
space, often on a remote server.
Implementation of RMI
Implementation of RMI
Communication module:

● The communication modules on the client and server are responsible of

carrying out the exchange of messages which implement the request/reply
protocol needed to execute the remote invocation.
● The particular messages exchanged and the way errors are handled,
depends on the RMI semantics which is implemented.
Implementation of RMI
Remote reference module:

● The remote reference module translates between local and remote object
references. The correspondence between them is recorded in a remote
object table.
● Remote object references are initially obtained by a client from a so called
binder that is part of the global name service (it is not part of the remote
reference module). Here servers register their remote objects and clients
look up after services.
Implementation of RMI
The proxy for object B:
● If an object A holds a remote reference to a (remote) object B, there exists a proxy
object for B on the machine which hosts A.
● The proxy is created when the remote object reference is used for the first time. For
each method in B there exists a corresponding method in the proxy.
● The proxy is the local representative of the remote object ⇒ the remote invocation
from A to B is initially handled like a local one from A to the proxy for B.
● At invocation, the corresponding proxy method marshals the arguments and builds
the message to be sent, as a request, to the server. After reception of the reply, the
proxy unmarshals the received message and sends the results, in an answer, to the
invoker.
Implementation of RMI
The skeleton for object B:
● On the server side, there exists a skeleton object corresponding to a class, if
an object of that class can be accessed by RMI. For each method in B there
exists a corresponding method in the skeleton.
● The skeleton receives the request message, unmarshals it and invokes the
corresponding method in the remote object; it waits for the result and
marshals it into the message to be sent with the reply.
● A part of the skeleton is also called dispatcher. The dispatcher receives a
request from the communication module, identifies the invoked method and
directs the request to the corresponding method of the skeleton.
Implementation of RMI
● Remote reference module and communication module belong to the
middleware.
● The proxy for B and the skeleton for B represent the so called RMI software.
They are situated at the border between middleware and application and
usually can be generated automatically with help of available tools that are
delivered together with the middleware software.
Implementation of RMI(Steps)
● The calling sequence in the client object activates the method in the proxy corresponding to
the invoked method in B.
● The method in the proxy packs the arguments into a message (marshalling) and forwards it
to the communication module.
● Based on the remote reference obtained from the remote reference module, the
communication module initiates the request/reply protocol over the network.
● The communication module on the server’s machine receives the request. Based on the
local reference received from the remote reference module the corresponding method in the
skeleton for B is activated.
● The skeleton method extracts the arguments from the received message (unmarshalling) and
activates the corresponding method in the server object B.
Implementation of RMI(Steps)
● After receiving the results from B, the method in the skeleton packs them into
the message to be sent back (marshalling) and forwards this message to the
communication module.
● The communication module receives the reply and forwards it to the
corresponding method in the proxy.
● The proxy method extracts the results from the received message
(unmarshalling) and forwards them to the client.
2.3 Remote Procedure Call
● A remote procedure call is very similar to a remote method invocation 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.
● A server process defines in its service interface the procedures that are
available for calling remotely.
● RPC is generally implemented over a request-reply protocol, which is simplified
by the omission of object references from request messages.
2.3 Remote Procedure Call
2.3 Remote Procedure Call
● RPC only addresses procedure calls.
● RPC is not concerned with objects and object references.
● A client that accesses a server includes one stub procedure for each
procedure in the service interface.
● A client stub procedure is similar to a proxy method of RMI.
● A server stub procedure is similar to a skeleton method of RMI.
2.3 Remote Procedure Call
2.3 Remote Procedure Call
1. The client calls local procedures (client Stub), the stub packages the arguments for the
remote procedure and create more network messages (marshalling).
2. The client stub send MSG to the remote system via system call at the local kernel.
3. The connection oriented/less protocol transfers the MSG to the remote system (RR Protocol).
4. The server stub procedure does unmarshalling the arguments of MSG and converts them.
5. Server Stub executes a local procedure call to invoke actual server function passing it the
argument that it received from the argument client stub.
6. When server procedure is executed, it sends return values to server stub.
7. The server stub converts the return values, marshal them into one or more MSG and send
them back to client.
8. Messages are sent back to client stub.
9. Client stub reads the network MSG from local kernel.
10. Client stub returns to another function call.
2.3 Remote Procedure Call
Advantages:

● Abstraction: RPC hides the complexity of network communication.

● Interoperability: RPC can facilitate communication between different systems
and programming languages, allowing heterogeneous systems to interact
seamlessly.
● Scalability: RPC can scale well to handle a large number of concurrent
requests.
2.3 Remote Procedure Call
Disadvantages:

● Complexity of debugging.
● Performance overhead: While RPC frameworks strive for efficiency, there is
still overhead involved in serializing/deserializing data, network
communication, and marshaling/unmarshaling parameters.
● Network dependency: RPC relies on network communication, which
introduces the possibility of latency, packet loss, and network failures.
● Security concerns: RPC systems need to implement security measures.
2.5 Events and notifications
● One object can react to a change occurring in another object.
● Events cause changes in the object that maintain the state of the application.
● Distributed event-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 the publish-subscribe paradigm, in which an object that generates
events publishes the type of event that it will make available for observation by
other objects.
● Objects that wants to receive notifications from an object that has published its
events subscribe to the types of events that are of interest to them.
2.5 Events and notifications
● Objects that represent event are called notifications.
● Subscribing to a particular type of event is also called registering interest in
that type of event.
● For example, a modification to a document, the fact that a person has entered
or left a room.
● Distributed event-based systems have two main characteristics:
○ Heterogeneous
○ Asynchronous
2.5 Main Characteristics
Heterogenous:

● When event notifications are used as a means of communication between

distributed objects, components in a distributed system that were not
designed to interoperate can be made to work together.
● All that is required is that event-generating objects publish the types of events
they offer, and that other objects subscribe to events and provide an interface
for receiving notifications.
2.5 Main Characteristics
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.
2.5 Event Types

● An event source can generate events of one or more different types. `

● Each event has attributes that specify information about that event, such as
the name or identifier of the object that generated it, the operations, its
parameters, and the time.
● `Types and attributes are used both in subscribing to events and in
notifications.
Architecture for distributed event
notification
The participants in distributed event
notification

● Above architecture specifies the roles played by the objects that participate in
distributed event-based systems.
● The main component is an event service that maintains a database of
published events and of subscribes’ interests.
The roles of the participating objects
● The object of interest: an object that experiences changes of state, as a result of its
operations being invoked and is considered as part of the event service if it transmits
notifications.
● Event: an event occurs at an object of interest as the result of the completion of a
method execution. `
● Notification: is an object that contains information about an event. Typically, it
contains the type of the event and its attributes.
● Subscriber: is an object that has subscribed to some type of events in another
object.
● Observer objects: to decouple an object of interest from its subscribers.
● Publisher: an object that declares that it will generate notifications of particular types
of event. A publisher may be an object of interest or an observer.
Three cases in fig
1. An object of interest inside the event service without an observer. It sends
notifications directly to the subscribers.
2. An object of interest inside the event service with an observer. The object of
interest sends notifications via the observer to the subscribers.
3. An object of interest outside the event service. In this case, an observer
queries the object of interest in order to discover when events occur. The
observer sends notifications to the subscribers
Delivery semantics: A variety of different delivery guarantees can be provided
for notifications – the chosen one should depend on the requirements of
applications.
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.
Ok
THIS MUCH FOR TODAY !!