Yarmouk Private University (YPU)
Faculty Of Informatics And
Communication Engineering
Distributed Systems
Lecture 2
Architectures of distributed systems
Fundamental Models
TVS Chapter 2 (System Architecture)
1
Architectural styles
A style is formulated in terms of:
➢ (replaceable) components with well-defined interfaces
➢ the way that components are connected to each other
➢ the data exchanged between components
➢ how these components and connectors are jointly configured into a system.
❑ Connector:
➢ mechanism that mediates communication, coordination, or cooperation among
components
➢ Example: facilities for (remote) procedure call, message passing, or streaming
data
2
Architectural Styles:
Based on the logical organization of the components of distributed
systems:
❑ Layered architectures
❑ Object-based architectures
❑ Resource-based Architecture
❑ Event-based architectures
3
Layered architectures
The layered architectural style
Object-based architectures
Resource-based Architecture
Event-based architectures
Figure 2.1: (a) Pure layered organization. (b) Mixed layered organization.
(c) Layered organization with upcalls (adopted from [Krakowiak, 2009]).
4
Layered architectures
The layered architectural style-2
Object-based architectures
Resource-based Architecture
Event-based architectures
5
Layered architectures
The object-based architectural style
Object-based architectures
Resource-based Architecture
Event-based architectures
❑ Components are objects, connected to each other through procedure calls mechanism.
❑ Objects may be placed on different machines; calls can thus execute across a network.
Encapsulation:
❑ Objects are said to encapsulate data (Object’s state) and offer methods on that data without
revealing the internal implementation.
6
Layered architectures
Object-based architectures
Resource-based Architecture Resource-based Architecture
Event-based architectures
RESTful architecture
❑ View a distributed system as a collection of resources, individually managed by components
❑ Resources may be added, removed, retrieved, and modified by (remote) applications
❑ Resources are identified through a single naming scheme (e.g., URI)
❑ All services offer the same interface
❑ Messages sent to or from a service are fully self-described
❑ After executing an operation at a service, that component forgets everything about the caller (stateless)
❑ Basic Operations:
7
Layered architectures
Example: Amazon’s Simple Storage Service
Object-based architectures
Resource-based Architecture
Event-based architectures
❑ Objects (i.e., files) are placed into buckets (i.e., directories)
❑ Buckets cannot be placed into buckets
❑ Operations on ObjectName in bucket BucketName require the following identifier:
http://BucketName.s3.amazonaws.com/ObjectName (S3: Simple Storage Service)
Typical operations:
All operations are carried out by sending HTTP requests:
➢ Create a bucket/object: PUT, along with the URI
➢ Listing objects: GET on a bucket name
➢ Reading an object: GET on a full URI
8
Layered architectures
Object-based architectures
The Publish-Subscribe
Resource-based Architecture
Event-based architectures
The referential coupling: There exist
❑ Dependencies between processes are as loose as possible explicit referencing in communication.
❑ Strong separation between processing and coordination e.g., a process can communicate only if it
(communication and cooperation) knows the name or identifier of the other
processes
❑ A process published a notification describing the occurrence of
an event
Temporal coupling: processes that are
❑ Processes may subscribe to a specific kind of notification communicating will both have to be up
and running
Event-based and Shared data space
Temporal and referential coupling
Coordination 9
Layered architectures
Example: Linda Tuple Space
Object-based architectures
Resource-based Architecture
Event-based architectures
10
Layered architectures
Example: Linda Tuple Space
Object-based architectures
Resource-based Architecture
Event-based architectures
11
System Architecture
Organizing distributed systems by considering where software components are placed:
➢ Centralized organization
➢ Decentralized organization
12
Centralized organization
Basic Client-Server Model
Decentralized organization
Characteristics:
➢ There are processes offering services (servers)
➢ There are processes that use services (clients)
➢ Clients and servers can be on different machines
➢ Clients follow request/reply model with respect to
using services
13
Centralized organization
Client-Server Model Decentralized organization
❑ Characteristics of a server:
➢ Passive (slave)
➢ Waits for requests
➢ Upon receipts of requests, it processes them and sends replies
➢ Can be stateless (does not keep any information between requests) or stateful
(remembers information between requests)
❑ Characteristics of a client:
➢ Active (master)
➢ Sends requests
➢ Waits for and receives server replies
14
Centralized organization
Decentralized organization
Multi-tiered centralized system architectures
❑ Some traditional organizations:
➢ Single-tiered: dumb terminal/mainframe configuration
➢ Two-tiered: client/single server configuration
➢ Three-tiered: each layer on separate machine
Traditional two-tiered configurations
15
Two-tiered configuration
a. The terminal-dependent part of the user interface on the client machine and the
applications remote control over the presentation of their data
b. We divide the application into a graphical front end, which communicates with the rest of the application
through an application-specific protocol. the front end does no processing other than necessary for presenting
the application’s interface
c. e.g., where the application makes use of a form that needs to be filled in entirely before it can be processed;
The front end can then check the correctness and consistency of the form, and where necessary interact with
the user; another example is where a word processor in which the basic editing functions execute on the client
side where they operate on locally cached, or in-memory data, but where the advanced support tools such as
checking the spelling and grammar execute on the server side
d. These organizations are used where the client machine is a PC, connected through a network to a distributed
file system or database; most of the application is running on the client machine, but all operations on files or
database entries go to the server. For example, many banking applications run on an end-user’s machine where
the user prepares transactions. Once finished, the application contacts the database on the bank’s server and
uploads the transactions for further processing
e. represents the situation where the client’s local disk contains part of the data. For example, when browsing the
Web, a client can gradually build a huge cache on local disk of most recent inspected Web pages.
16
Centralized organization
Being client and server at the same time
Decentralized organization
17
Centralized organization
Alternative organizations (P2P)
Decentralized organization
Vertical distribution
Comes from dividing distributed applications into three logical layers, and running the
components from each layer on a different server (machine).
Horizontal distribution
A client or server may be physically split up into logically equivalent parts, but each part is
operating on its own share of the complete data set.
Peer-to-peer architectures
Processes are all equal: the functions that need to be carried out are represented by every
process → each process will act as a client and a server at the same time (i.e., acting as a
servant).
18
Centralized organization
Structured P2P
Decentralized organization
❑ Make use of a semantic-free index: each data item is uniquely associated with a key, in turn used as
an index. Common practice: use a hash function
key(data item) = hash(data item’s value)
❑ P2P system now responsible for storing (key,value)pairs
❑ Simple example: hypercube:
Looking up d with key 𝑘 ∈ {0, 1, 2, … , 24 means
− 1} routing request to node with identifier k.
19
Centralized organization
Example: Chord
Decentralized organization
Principle:
➢ Nodes are logically organized in a ring
➢ Each node has an m-bit identifier
➢ Keys and identifiers are typically 128 or
160 bits long
➢ Each data item is hashed to an m-bit key
➢ Data item with key k is stored at node
with smallest identifier id ≥ k,
➢ called the successor of key k
➢ The ring is extended with various
shortcut links to other nodes
20
Centralized organization
Distributed hash table (DHT) in Chord
Decentralized organization
▪ m = 5 with nine nodes {1, 4, 9, 11, 14, 18, 20,
21, 28}
▪ Succ(7) = 9
▪ succ(5) = 9
▪ succ(9) = 9
▪ P is the identifier of the node
▪ Resolving key 26 from node 1 and key 12
from node 28 in a Chord system.
21
Centralized organization
Unstructured P2P
Decentralized organization
22
Hybrid Architectures Hybrid Architectures: client-server solutions are
combined with decentralized architectures
Edge-server architecture
Systems deployed on the Internet where servers are placed at the edge of the network: the boundary
between enterprise networks and the actual Internet.
23
Client-Server vs P2P
❑ Client-Server ❑ P2P
➢ Widely Used ➢ Symmetrical, computers have
➢ Functional Specialisation same “rights”
➢ Asymmetrical ➢ Truly Distributed
➢ Tends to be centralised ➢ Share / exploit resources with a
large number of participants
➢ Tends to scale poorly
➢ Resource discovery is a
challenge
24
