Course Outline COURSE NAME: DISTRIBUTED SYSTEM

COURSE CODE: COMP4191

 Introduction
ECTS: 6ECTS
 Architectures DELIVERY MODE: Student centered lecture and
 Processes laboratory works
COURSE INSTRUCTORS: Mr. Alemayehu M
 Communication and Mr. Dawit M.
 Naming TEXT BOOK: . S. Tanenbaumand Maartenvan
 Synchronization Steen, Distributed Systems, Principles and
Paradigms, 2nd edition, Prentice
 Consistency and Hall, 2007
Replication Assessment
 Fault Tolerance 1) DS Project _G_20%
Prerequisites 2) Seminar Presentation_G_15%
 Operating System 3) Scientific paper synthesis_G_15%
 Data Structure 4) DS_Comunication_code_Project_G_10%
 Programing concepts 5) Final Exam _Chapter 1,2,3,4 and
 Data Communication Seminar presentations done_40%
 Database
 IS security …….. 1
Chapter 1 - Introduction

2
 Outline

1.1 Introduction and Definition

1.2 Goals of a Distributed System
1.3 Types of Distributed Systems

3
1.1 Introduction and Definition
 before the mid-80s, computers were
 very expensive (hundred of thousands or even millions of
dollars)
 very slow (a few thousand instructions per second)
 not connected among themselves
 after the mid-80s: two major developments
 cheap and powerful microprocessor-based computers
appeared
 computer networks
 LANs at speeds ranging from 10 to 1000 Mbps
 WANs at speed ranging from 64 Kbps to gigabits/sec
 consequence
 feasibility of using a large network of computers to work
for the same application; this is in contrast to the old
centralized systems where there was a single computer
with its peripherals
4
 Definition of a Distributed System
 a distributed system is:
a collection of independent computers that appears to its
users as a single coherent system - computer (Tanenbaum
& Van Steen)

 this definition has two aspects:

1. hardware: autonomous machines
a distributed system consists of components (i.e.,
computers) that are autonomous.

[Link]: a single system view for the users

users think they are dealing with a single system

5
 Other Definitions
A distributed system is a system designed to support the
development of applications and services which can exploit a
physical architecture consisting of multiple, autonomous
processing elements that do not share primary memory but
cooperate by sending asynchronous messages over a
communication network (Blair & Stefani)

A distributed system is one that stops you getting any work

done when a machine you’ve never even heard of crashes
(Leslie)

6
 Why Distributed?
 Resource and Data Sharing
 printers, databases, multimedia servers, ...
 Availability, Reliability
 the loss of some instances can be hidden
 Scalability, Extensibility
 the system grows with demand (e.g., extra servers)
 Performance
 huge power (CPU, memory, ...) available

Etc.. . . . . . .

7
 Problems of Distribution
 Concurrency, Security
 clients must not disturb each other
 Privacy
 e.g., when building a preference profile
 unwanted communication such as spam
 Partial failure
 we often do not know where the error is
 Location, Migration, Replication
 clients must be able to find their servers
 Heterogeneity
 hardware, platforms, languages, management

8
 Characteristics of Distributed Systems
 differences between the computers and the ways they
communicate are hidden from users
 users and applications can interact with a distributed system
in a consistent and uniform way regardless of location
 distributed systems should be easy to expand and scale
 a distributed system is normally continuously available, even
if there may be partial failures

9
  to support heterogeneous computers and networks and
to provide a single-system view, a distributed system is
often organized by means of a layer of software called
middleware that extends over multiple machines

a distributed system organized as middleware; note that the

middleware layer extends over multiple machines, and offers each
application the same interface
Ack: most drawings in all slides are taken from the textbook
10
1.2 Goals of a Distributed System

11
 Goals of a distributed system: a distributed system should
 make resources easily accessible (printers, computers,
storage facilities, data, files, Web pages, ...)
 reasons: economics, to collaborate and exchange
information
 be transparent: hide the fact that the resources and
processes are distributed across multiple computers
 be open
 be scalable

 Transparency in a Distributed System

 a distributed system that is able to present itself to users
and applications as if it were only a single computer
system is said to be transparent

12
 different forms of transparency in a distributed system
Transparency Description
Access Hide differences in data representation
(endianness, file naming, ...) and how a resource
is accessed
Location Hide where a resource is physically located; where
is [Link] (naming)
Migration Hide that a resource may move to another location
Relocation Hide that a resource may be moved to another
location while in use; e.g., mobile users using their
wireless laptops
Replication Hide that a resource is replicated
Concurrency Hide that a resource may be shared by several
competitive users; a resource must be left in a
consistent state
Failure Hide the failure and recovery of a resource

13
 Openness in a Distributed System
 An open distributed system is a system that offers services
according to standard rules that describe the syntax and
semantics of those services; e.g., protocols in networks
 In distributed systems, services are generally specified
through interfaces. i.e. we need well-defined interfaces
 interfaces often described using an Interface Definition
Language (IDL)
 specify only syntax: the names of the functions, types of parameters,
return values, possible exceptions, ...
 Semantics are given in an informal way by means of natural
languages
 interoperability
 components of different origin can communicate
 portability
 components work on different platforms

14
 • another goal of an open distributed system is that it should be

flexible and extensible; easy to configure the system out of

different components; easy to add new components, replace

existing ones; easier said than done

 Scalability in Distributed Systems
 a distributed system should be scalable
 size: adding more users and resources to the system
 geographically: users and resources may be far apart
 administratively: should be easy to manage even if it
spans many administrative organizations
 but a scalable system may exhibit performance problems

15
  scalability problems

Concept Example
Single server for all users-mostly for security
Centralized services
reasons
Centralized data A single on-line telephone book
Centralized algorithms Doing routing based on complete information
examples of scalability limitations

 Scaling Techniques
 how to solve scaling problems
 the problem is mainly performance, and arises as a result
of limitations in the capacity of servers and networks
 three possible solutions: hiding communication latencies,
distribution, and replication

16
a. Hide Communication Latencies
 try to avoid waiting for responses to remote service
requests
 let the requester do other useful job
 i.e., construct requesting applications that use only
asynchronous communication instead of synchronous
communication; when a reply arrives the application is
interrupted
 good for batch processing and parallel applications but
not for interactive applications
 for interactive applications, move part of the job to the
client to reduce communication; e.g. filling a form and
checking the entries

17
 (a) a server checking the correctness of field entries
(b) a client doing the job
 e.g., checking the completeness of mandatory fields
 shipping code is now supported in Web applications using
Java Applets and Javascript
18
b. Distribution
 Distribution involves taking a component, splitting it into
smaller parts, and subsequently spreading those parts
across the system.
 e.g., DNS - Domain Name System (mlibsie@[Link])
 divide the name space into non overlapping zones

an example of dividing the DNS name space into zones

19
c. Replication
 replicate components across a distributed system to
increase availability and for load balancing, leading to
better performance
 decided by the owner of a resource
 caching (a special form of replication) also reduces
communication latency; decided by the user
 but, caching and replication may lead to consistency
problems

20
Pitfalls when Developing Distributed Systems
 False assumptions made by first time developers
 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

21
1.3 Types of Distributed Systems
 Three types: distributed computing systems, distributed
information systems, and distributed embedded systems
1. Distributed Computing Systems
 Used for high-performance computing tasks
 two types: cluster computing and grid computing
 Cluster Computing
 a collection of similar workstations or PCs
(homogeneous), closely connected by means of a
high-speed LAN
 each node runs the same operating system
 used for parallel programming in which a single
compute intensive program is run in parallel on
multiple machines

22
an example of a cluster computing system

23
  Grid Computing
 “Resource sharing and coordinated problem solving in
dynamic, multi-institutional virtual organizations” (I.
Foster)
 high degree of heterogeneity: no assumptions are
made concerning hardware, operating systems,
networks, administrative domains, security policies,
etc.
2. Distributed Information Systems
 problem: many networked applications with a problem of
interoperability
 Their goal is to distribute information across several
Servers
 at the lowest level: wrap a number of requests into a
single larger request and have it executed as a distributed
transaction
 how to let applications communicate directly with each
24
other, i.e., Enterprise Application Integration (EAI)
 Transaction Processing Systems
 Consider database applications
 special primitives are required to program transactions,
supplied either by the underlying distributed system or
by the language runtime system
 exact list of primitives depends on the type of application
Primitive Description
BEGIN_TRANSACTION Mark the start of a transaction
Terminate the transaction and try to
END_TRANSACTION
commit
Kill the transaction and restore the old
ABORT_TRANSACTION
values
Read data from a file, a table, or
READ
otherwise
Write data to a file, a table, or
WRITE
otherwise
25
 The Transaction Model
 the model for transactions comes from the world of
business
 a supplier and a retailer negotiate on
 price
 delivery date
 quality
 etc.
 until the deal is concluded they can continue
negotiating or one of them can terminate
 but once they have reached an agreement they are
bound by law to carry out their part of the deal
 transactions between processes is similar with this
scenario

26
 e.g., assume the following banking operation
 withdraw an amount x from account 1
 deposit the amount x to account 2
 what happens if there is a problem after the first activity
is carried out?
 group the two operations into one transaction; either
both are carried out or neither
 we need a way to roll back when a transaction is not
completed

27
 e.g. reserving a seat from White Plains to Malindi through
JFK and Nairobi airports

BEGIN_TRANSACTION BEGIN_TRANSACTION
reserve WP  JFK; reserve WP  JFK;
reserve JFK  Nairobi; reserve JFK  Nairobi;
reserve Nairobi  Malindi; reserve Nairobi  Malindi full 
END_TRANSACTION ABORT_TRANSACTION
(a) (b)

(a) transaction to reserve three flights commits

(b) transaction aborts when third flight is unavailable

28
 properties of transactions, often referred to as ACID
1. Atomic: to the outside world, the transaction happens
indivisibly; a transaction either happens completely or
not at all; intermediate states are not seen by other
processes
2. Consistent: the transaction does not violate system
invariants; e.g., in an internal transfer in a bank, the
amount of money in the bank must be the same as it
was before the transfer (the law of conservation of
money); this may be violated for a brief period of time,
but not seen to other processes
3. Isolated or Serializable: concurrent transactions do not
interfere with each other; if two or more transactions
are running at the same time, the final result must look
as though all transactions run sequentially in some
order
4. Durable: once a transaction commits, the changes are
permanent; see later in Chapter 8 29
 Classification of Transactions
 a transaction could be flat, nested or distributed
 Flat Transaction
 consists of a series of operations that satisfy the ACID
properties
 simple and widely used but with some limitations
 do not allow partial results to be committed or aborted
 i.e., atomicity is also partly a weakness
 in our airline reservation example, we may want to
accept the first two reservations and find an
alternative one for the last
 some transactions may take too much time

30
 Nested Transaction
 constructed from a number of subtransactions; it is
logically decomposed into a hierarchy of
subtransactions
 the top-level transaction forks off children that run in
parallel, on different machines; to gain performance or
for programming simplicity
 each may also execute one or more subtransactions
 permanence (durability) applies only to the top-level
transaction; commits by children should be undone
 Distributed Transaction
 a flat transaction that operates on data that are
distributed across multiple machines
 problem: separate algorithms are needed to handle the
locking of data and committing the entire transaction;
see later in Chapter 8 for distributed commit
31
(a) a nested transaction
(b) distributed transaction

32
 Enterprise Application Integration
 how to integrate applications independent from their
databases
 transaction systems rely on request/reply
 how can applications communicate with each other

middleware as a communication facilitator in enterprise application

integration 33
 3. Distributed Pervasive Systems
 These are the distributed systems involving mobile and
embedded computer devices like Small, wireless, battery-
powered devices (PDA’s, smart phones, sensors, wireless
surveillance cams, portable ECG monitors, etc.)
 These systems characterized by their “instability
(unpredictable)” when compared to more “traditional”
distributed systems
 Pervasive Systems are all around us, and ideally should be able
to adapt to the lack of human administrative control
 Automatically connect to a different network; Discover services
and react accordingly; Automatic self configuration
 Examples: Home Systems, Electronic Health Care Systems,
Sensor Networks, etc.

34
 three requirements for pervasive applications
 embrace contextual changes: a device is aware that
its environment may change all the time
 encourage ad hoc composition: devices are used in
different ways by different users
 recognize sharing as the default: devices join a
system to access or provide information
 examples of pervasive systems
 Home Systems
 Electronic Health Care Systems
 Sensor Networks

35
 Further Reading Assignment
 ERP Systems and Enterprise Application Integration

 TPS Transaction Processing Systems

36