Chapter-two

Architectures
By
Andargie Mekonnen

07/04/2026 Compiled by: Andargie Mekonnen 1

INTRODUCTION
Distributed systems are complex pieces of software with components dispersed
across multiple machines. To master this complexity, proper organization is
crucial. There are different ways to view the organization of a distributed system,
but an obvious one is to distinguish between:
Software architecture: The logical organization of software components and
how they interact
System architecture: The actual physical realization ,instantiating and placing
software components on real machines
07/04/2026 Compiled by: Andargie Mekonnen 2
ARCHITECTURAL STYLES
An architectural style is formulated in terms of:
Components: Modular units with well-defined required and provided interfaces
Connectors: Mechanisms that mediate communication, coordination, or cooperation
among components
Using components and connectors, we can come to various configurations, which, in
turn, have been classified into architectural styles. Several styles have by now been
identified, of which the most important ones for distributed systems are:
Layered architectures
 Object-based architectures
Resource-centered architectures
 Event-based architectures
07/04/2026 Compiled by: Andargie Mekonnen 3
Layered Architectures
The basic idea: components are organized in layers where a component at layer Lj can call
components at lower-level layers Li (with i < j).

07/04/2026 Compiled by: Andargie Mekonnen 4

Layered Architectures
Three common organizations:
Pure layered: Only down calls to the next lower layer (common in network
communication)
Mixed layered: An application uses different libraries that may share common lower
layers
Layered with upcalls: Lower layers can call higher layers (e.g., operating system
signaling events to applications)

07/04/2026 Compiled by: Andargie Mekonnen 5

Layered Architectures
Layered Communication Protocols
Communication-protocol stacks follow a layered architecture.
Each layer implements communication services and offers an
interface specifying available functions.
Important distinction:
 Service: What the layer offers
 Interface: How the service is made available
 Protocol: The rules parties follow to exchange information
 Example: TCP provides a reliable, connection-oriented
service. The protocol specifies message exchange for
connection setup, ordering, error detection, etc. The service
is made available through a programming interface (like
sockets).
07/04/2026 Compiled by: Andargie Mekonnen 6
Layered Architectures
Application Layering
Many distributed applications can be divided into three logical
levels:
 Application-interface level: Handles user interaction
 Processing level: Contains core application functionality
 Data level: Maintains persistent data
 Examples: Internet search engine: User interface
(keywords), processing (transforming keywords to queries,
ranking results), data (database of indexed Web pages)
Decision support system: Front end (user interface), analysis
programs, back end (financial database)
Office suite: Common user interface, collection of programs,
remote file server
07/04/2026 Compiled by: Andargie Mekonnen 7
 Object-Based and Service-Oriented Architectures
In object-based architectures, components are objects that encapsulate state and methods. Objects are
connected through procedure call mechanisms (which can be remote).
Distributed objects: An object's interface is placed on one machine while the object resides on another.
When a client binds to a distributed object:
 A proxy (client stub) is loaded into the client's address space
 The proxy marshals method invocations into messages
 The actual object resides at the server with a skeleton (server stub)
Note: In most distributed objects, the state resides at a single machine (remote objects), not distributed.

07/04/2026 Compiled by: Andargie Mekonnen 8

 Object-Based and Service-Oriented Architectures
Service-Oriented Architectures (SOAs):
 Applications are constructed as compositions of many different services
 Services may belong to different administrative organizations
 Each service offers a well-defined programming interface

07/04/2026 Compiled by: Andargie Mekonnen 9

Resource-Based Architectures
view a distributed system as a huge collection of resources that are individually managed by
components. Resources may be added or removed by (remote) applications, and likewise can
be retrieved or modified. This approach has now been widely adopted for the Web and is
known as Representational State Transfer (REST)
Representational State Transfer (REST) is an architectural style for Web-based distributed
systems. Key characteristics:
 Resources are identified through a single naming scheme
 All services offer the same interface (PUT, GET, DELETE, POST)
 Messages are fully self-described
 Stateless execution—component forgets everything about the caller after executing an operation

07/04/2026 Compiled by: Andargie Mekonnen 10

Resource-Based Architectures
Example: Amazon S3 (Simple Storage Service)
Resources: objects (files) and buckets (directories)
URI format: [Link]
PUT request creates a bucket or object
GET request retrieves object names

Comparison with service-specific interfaces:

RESTful architectures: simpler but may not support intricate communication schemes
Service-specific interfaces: better compile-time checking, easier semantic specification

07/04/2026 Compiled by: Andargie Mekonnen 11

Publish-Subscribe Architectures

The idea is to view a system as a collection of autonomously operating processes. In this

model, coordination encompasses the communication and cooperation between processes.
Coordination models can be distinguished along two dimensions
Temporally Coupled Temporally Decoupled

Referentially Coupled Direct coordination Mailbox coordination

Referentially Decoupled Event-based coordination Shared data space

Event-based coordination:
 Processes publish notifications;
 processes subscribe to specific notification types.
 Publishers and subscribers don't know each other explicitly.

07/04/2026 Compiled by: Andargie Mekonnen 12

Publish-Subscribe Architectures
Shared data space (referentially and temporally decoupled):
 Processes communicate through tuples (structured data records)
 Processes put tuples into the shared space
 To retrieve a tuple, a process provides a search pattern
 Implements associative search mechanism
Example: Linda tuple spaces
Three operations:
 in(t) (remove matching tuple),
 rd(t) (obtain copy),
 out(t) (add tuple)
Blocking operations—caller waits until a matching tuple is found

07/04/2026 Compiled by: Andargie Mekonnen 13

Publish-Subscribe Architectures
Shared data spaces are often combined with event-based coordination: a process subscribes to
certain tuples by providing a search pattern; when a process inserts a tuple into the data space,
matching subscribers are notified. In both cases, we are dealing with a publish-subscribe
architecture, and indeed, the key characteristic feature is that processes have no explicit
reference to each other.

07/04/2026 Compiled by: Andargie Mekonnen 14

Publish-Subscribe Architectures
An important aspect of publish-subscribe systems is that communication takes place by
describing the events that a subscriber is interested in. As a consequence, naming plays a
crucial role. In many cases, data items are not explicitly identified by senders and receivers.
Let us first assume that events are described by a series of attributes. A notification describing
an event is said to be published when it is made available for other processes to read. To that
end, a subscription needs to be passed to the middleware, containing a description of the
event that the subscriber is interested in.
Topic-based vs. Content-based publish-subscribe:
 Topic-based: Subscriptions consist of (attribute, value) pairs
 Content-based: Subscriptions may include (attribute, range) pairs or complex predicates

07/04/2026 Compiled by: Andargie Mekonnen 15

Publish-Subscribe Architectures

07/04/2026 Compiled by: Andargie Mekonnen 16

 SYSTEM ARCHITECTURE
 Deciding on software components, their interaction, and their placement leads to an instance
of a software architecture, also known as a system architecture.
It can have centralized and decentralized organizations or hybrid.

07/04/2026 Compiled by: Andargie Mekonnen 17

Centralized Organizations
Simple client-server architecture
In the basic client-server model, processes in a distributed
system are divided into two (possibly overlapping) groups.
A server is a process implementing a specific service, for
example, a file system service or a database service.
A client is a process that requests a service from a server
by sending it a request and subsequently waiting for the
server’s reply.

07/04/2026 Compiled by: Andargie Mekonnen 18

 Centralized Organizations
Simple client-server architecture
Communication between a client and a server can be implemented by means of a simple
connectionless protocol when the underlying network is fairly reliable as in many local-area
networks. It is efficient but handling transmission failures is non-trivial
 When an operation can be repeated multiple times without harm, it is said to be idempotent. Since

some requests are idempotent and others are not it should be clear that there is no single solution for
dealing with lost messages.
As an alternative, many client-server systems use a reliable connection oriented protocol. Although
this solution is not entirely appropriate in a local-area network due to relatively low performance, it
works perfectly fine in wide-area systems in which communication is inherently unreliable. For
example, virtually all Internet application protocols are based on reliable TCP/IP connections.
07/04/2026 Compiled by: Andargie Mekonnen 19
 Centralized Organizations
Multitiered Architectures
Based on the three logical levels, applications can be physically distributed in several ways:
Two-tiered architectures:
The simplest organization is to have only two types of machines
1. A client machine containing only the programs implementing (part of) the user-interface level
2. Aserver machine containing the rest, that is, the programs implementing the processing and data level

07/04/2026 Compiled by: Andargie Mekonnen 20

 Centralized Organizations
Multitiered Architectures
Three-tiered architecture.
In this architecture, traditionally programs that form part of the
processing layer are executed by a separate server, but may
additionally be partly distributed across the client and server
machines. A typical example of where a three-tiered architecture is
used is in transaction processing. A separate process, called the
transaction processing monitor, coordinates all transactions across
possibly different data servers. Another, but very different
example were we often see a three-tiered architecture is in the
organization of Web sites. In this case, a Web server acts as an
entry point to a site, passing requests to an application server
where the actual processing takes place. This application server, in
urn, interacts with a database server.
07/04/2026 Compiled by: Andargie Mekonnen 21
Decentralized Organizations: Peer-to-Peer Systems
Vertical distribution: Placing logically different components on different machines
Horizontal distribution(Peer-to-peer (P2P)) : Splitting clients or servers into logically
equivalent parts operating on their own share of data (load balancing).
Peer-to-peer (P2P) systems:
 All processes are equal
 Interaction is symmetric (each process acts as both client and server)
 Processes organized into an overlay network

07/04/2026 Compiled by: Andargie Mekonnen 22

 Decentralized Organizations: Peer-to-Peer Systems
Structured Peer-to-Peer Systems
 Overlay adheres to a specific, deterministic topology
 Based on distributed hash tables (DHTs)
 Each data item is associated with a key (hash of data item's value)
 Each node assigned an identifier from the same hash space
 System provides a lookup(key) function that maps a key to an existing node

Example: Chord
 Nodes organized logically in a ring
 Data item with key k maps to node with smallest identifier id ≥ k (successor succ(k))
 Lookup takes O(log N) steps
 Each node maintains shortcuts (finger table) to other nodes
 Nodes can join and leave dynamically
07/04/2026 Compiled by: Andargie Mekonnen 23
 Decentralized Organizations: Peer-to-Peer Systems
Unstructured Peer-to-Peer Systems
 Each node maintains an ad hoc list of neighbors
 Overlay resembles a random graph

Looking up data requires searching:

 Flooding: Pass request to all neighbors (with TTL to limit scope)
 Random walks: Forward request to randomly chosen neighbor

Policy-based search: Keep track of peers who responded positively

Comparison: Random walks impose less network traffic but may take longer; flooding is
expensive but may find data faster.

07/04/2026 Compiled by: Andargie Mekonnen 24

 Decentralized Organizations: Peer-to-Peer Systems
Hierarchically Organized Peer-to-Peer Networks
 Some nodes become superpeers that maintain indexes or act as brokers
 Superpeers are organized in a peer-to-peer network
 Weak peers connect as clients to superpeers

Example: Skype network

 Weak peers connect to superpeers (Skype super nodes)
 Host cache contains addresses of reachable superpeers
 Login server handles registration and user authentication

07/04/2026 Compiled by: Andargie Mekonnen 25

 Hybrid Architectures
classes of distributed systems in which client-server architectures are combined with
decentralized architectures.

07/04/2026 Compiled by: Andargie Mekonnen 26

07/04/2026 Compiled by: Andargie Mekonnen 27