What is a distributed system?

Many definitions
Ø [Coulouris]
§ A distributed system is one in which hardware or software
components located at networked computers communicate and
coordinate their actions only by passing messages.
Ø [Tanenbaum & van Steen]
§ A distributed system is a collection of independent computers
that appears to its users as a single coherent system.
Ø [Lamport]
§ A distributed system is a system that prevents you from doing
any work when a computer you have never heard about, fails.
Ø The above definitions take different perspectives
§ Operational perspective
§ User perspective
§ DS characteristics perspective

Frank Eliassen, Ifi/UiO 3

Examples of distributed
systems

ØWeb search
§ Index the entire contents of the Web.
ØMassively multiplayer online games
§ Very large number of users sharing a virtual
world.
ØFinancial trading
§ Real time access and processing of a wide
rage of information sources.
Frank Eliassen, Ifi/UiO 4

2
Implications of distributed systems
§ Concurrency
– components execute in concurrent processes that read and update
shared resources. Requires coordination
§ No global clock
– makes coordination difficult (ordering of events)
§ Independent failure of components
– “partial failure” & incomplete information
§ Unreliable communication
– Loss of connection and messages. Message bit errors
§ Unsecure communication
– Possibility of unauthorised recording and modification of messages
§ Expensive communication
– Communication between computers usually has less bandwidth, longer
latency, and costs more, than between independent processes on the
same computer

Frank Eliassen, Ifi/UiO 5

Why
distributed systems?
§ resource sharing
– the possibility of using available resources any where
§ openness
– an open distributed system can be extended and improved
incrementally
– requires publication of component interfaces and standards
protocols for accessing interfaces
§ scalability
– the ability to serve more users, provide acceptable response
times with increased amount of data
§ fault tolerance
– maintain availability even when individual components fail
§ allow heterogeneity
– network and hardware, operating system, programming
languages, implementations by different developers
Frank Eliassen, Ifi/UiO 6

3
 Resource sharing

Ø The opportunity to use available hardware,

software or data anywhere in the system
Ø Resource managers control access, offer a
scheme for naming, and control concurrency
Ø A service is a software module that manages a
collection of related resources and presents their
functionality to users.
Ø A resource sharing model describes how
§ resources are made available
§ resources can be used
§ service provider and user interact with each other
Frank Eliassen, Ifi/UiO 7

Models for resource sharing

Ø Client-server resource model

§ Server processes act as resource managers, and offer services
(collection of procedures)
§ Client processes send requests to servers
§ (HTTP defines a client-server resource model)
Ø Object-based resource model
§ Any entity in a process is modeled as an object with a message
based interface that provides access to its operations
§ Any shared resource is modeled as an object
§ Object based middlewares (CORBA, Java RMI) defines object-
based resource models

Frank Eliassen, Ifi/UiO 8

4
 Scalability
Ø A system is scalable if it remains effective when there is
a significant increase in the amount of resources (data)
and number of users
§ Internet: number of users and services has grown enormously
Ø Scalability denotes the ability of a system to handle an
increasing future load
Ø Requirements of scalability often leads to a distributed
system architecture (several computers)

Frank Eliassen, Ifi/UiO 9

Scalability problems (1)

ØOften caused by centralized solutions

Frank Eliassen, Ifi/UiO 10

5
 Scalability problems (2)
ØCharacteristics of decentralized
algorithms:
§ No machine has complete information about
the system state.
§ Machines make decisions based only on local
information.
§ Failure of one machine does not ruin the
algorithm.
§ There is no implicit assumption that a global
clock exists.
Frank Eliassen, Ifi/UiO 11

Scaling techniques
Ø Distribution
§ splitting a resource (such as data) into smaller parts,
and spreading the parts across the system (cf DNS)
Ø Replication
§ replicate resources (services, data) across the system
§ increases availability, helps to balance load
§ caching (special form of replication)
Ø Hiding communication latencies
§ avoid waiting for responses to remote service requests
(use asynchronous communication or design to reduce
the amount of remote requests)

Frank Eliassen, Ifi/UiO 12

6
 Fault tolerance
Ø Hardware, software and network fail!!
Ø DS must maintain availability even in cases where
hardware/software/network have low reliability
Ø Failures in distributed systems are partial
§ makes error handling particularly difficult
Ø Many techniques for handling failures
§ Detecting failures (checksum a.o.)
§ Masking failures (retransmission in protocols)
§ Tolerating failures (as in web-browsers)
§ Recovery from failures (roll back)
§ Redundancy (replicate servers in failure-independent ways)

Frank Eliassen, Ifi/UiO 13

Example: Google File-System

Early days…

Challenges:
…today
- Scalability
- Reliability
- Performance
- Openness

Frank Eliassen, Ifi/UiO 14

7
 Distribution transparency

ØAn important goal of a distributed system

is to hide the fact that its processes and
resources are physically distributed across
multiple computers
ØA distributed system that is able to present
itself to its users and applications as if it
were only a single computer system is said
to be transparent
Frank Eliassen, Ifi/UiO 15

Transparency in a distributed
system

Different forms of transparency in a distributed system (ISO, 1995).

Trade-off between degree of transparency and performance of a system
Frank Eliassen, Ifi/UiO 16

8
 Pitfalls when Developing
Distributed Systems

ØFalse assumptions made by first time

developer:
§ The network is reliable.
§ The network is secure.
§ The network is homogeneous.
§ The topology does not change.
§ Latency is zero.
§ Bandwidth is infinite.
§ Transport cost is zero.
§ There is one administrator.
Frank Eliassen, Ifi/UiO 17

Quality of Service (QoS)

ØNon-functional properties of the system:

§ Reliability
§ Security
§ Performance (Responsiveness and
throughput)
Ø Adaptability to meet changes is an
important aspect of QoS

Frank Eliassen, Ifi/UiO 18

9
 The role of middleware in
distributed systems
Ø Layer of software offering a single-system view
Ø Offers transparencies (access, location, …)
Ø Simplifies development of distributed applications
and services
Distributed
applications
and services

Platform Independent API - transaction oriented (ODTP XA)

- message oriented(IBM MQSeries)
DISTRIBUTION MIDDEWARE
- remote procedure call (X/Open DCE)
Platform Dependent API - object-based (CORBA, COM, Java)
Local OS Local OS Local OS
... n
1 2
Frank Eliassen, Ifi/UiO 19

Types of distributed system

Ø Distributed Computing Systems
§ Used for high performance computing tasks
§ Cluster and Cloud computing systems
§ Grid computing systems
Ø Distributed Information Systems
§ Systems mainly for management and integration of
business functions
§ Transaction processing systems
§ Enterprise Application Integration
Ø Distributed Pervasive (or Ubiquitous) Systems
§ Mobile and embedded systems
§ Home systems
§ Sensor networks
Frank Eliassen, Ifi/UiO 20

10
Distributed Computing Systems:
Cluster Computing Systems
Collection of similar PCs, closely connected, all run same OS

An example of a cluster computing system.

Frank Eliassen, Ifi/UiO 21

Distributed Computing Systems:

Grid Computing Systems
Federation of autonomous and heterogeneous
computer systems (HW,OS,...), several adm domains

A layered architecture for grid computing systems.

Frank Eliassen, Ifi/UiO 22

11
Distributed Information Systems:
Enterprise Application Integration
Allowing existing applications to directly exchange
information using communication middleware

Middleware as a communication facilitator in enterprise

application integration Frank Eliassen, Ifi/UiO 23

Example communcation
middleware: CORBA
Clients may invoke methods of remote objects without worrying about:
object location, programming language,
operating system platform, communcation
protocols or hardware.

X Y Z Different
invoke Z’s programming languages
method foo()
foo() (or object models)
IDL IDL IDL
Common object model

RMI over IIOP

Object Request Broker (ORB)

Frank Eliassen, Ifi/UiO 24

12
 Distributed Pervasive
Systems

Ø Pervasive systems is about exploiting the increasing

integration of services and (small/tiny) computing
devices in our everyday physical world
Ø (Mobile) Devices in distributed pervasive systems
discovers the environment (its services) and
establishes themselves in this environment as best
as possible.
Ø Requirements for pervasive applications
§ Embrace contextual changes.
§ Encourage ad hoc and dynamic composition.
§ Recognize sharing as the default.
Frank Eliassen, Ifi/UiO 25

Distributed pervasive system :

MUSIC context-aware adaptation middleware
http://www.euronews.net/2010/06/16/music-to-you-mobile-s-ears/

services
temperature devices
light
context-aware,
varying context provided utility self-adaptive
applications
environment
context user

user optimizes
context adapts
monitors (reconfigures)
device
context MUSIC Context & Adaptation Middleware
Inspects &
reasons about
activity
position
(e.g., driving) Application
memory use
variability
model
battery
26
CPU use http://ist-music.berlios.de/

13
 Distributed Computing as a
Utility
Ø View: Distributed resources as a commodity or utility
Ø Resources are provided by service suppliers and effectively
rented rather than owned by the end user.
Ø The term cloud computing capture the vision of computing as
a utility
SalesForce CRM
SaaS
Clients LotusLive

Google App
Internet PaaS Engine

IaaS
Frank Eliassen, Ifi/UiO 27

Summary
Ø Distributed systems:
§ components located in a network that communicates and
coordinates their actions exclusively by sending messages.
Ø Consequences of distributed systems
§ Independent failure of components
§ Unsecure communication
§ No global clock
Ø Distribution transparency: providing a single computer
system view
Ø Requirements like resource sharing, openness,
scalability, fault tolerance and heterogeneity can be
satisfied by distributed systems
Ø Many pitfalls when developing distributed systems
Frank Eliassen, Ifi/UiO 28

14