Architectures

of
Distributed System

1
Smart Garbage Bin Using IoT
Communication
Network

GPS Signal

GSM Modem
Waste Level Sensor
Central Repository
GSM Network

Threshold Level

Current Waste
Level

Domestic waste Waste Distribution Dashboard as a input for a

more efficient waste collection planning
Digital Water Strider: System Overview
Topics to be discussed are
• Architectural styles
• Software/System architectures

4
Architectural Models
• The architecture of a system is its structure in terms of
separately specified components and their
interrelationships.
• The overall goal is to ensure that the structure will meet
present and likely future demands on it. Major concerns
are to make the system reliable, manageable, adaptable
and cost-effective.
Architectural Models
Generations of distributed systems
Architectural Elements
• To understand the fundamental building blocks of a
distributed system, it is necessary to consider four key
questions:
• What are the entities that are communicating in the distributed
system?
• How do they communicate, or, more specifically, what
communication paradigm is used?
• What (potentially changing) roles and responsibilities do they
have in the overall architecture?
• How are they mapped on to the physical distributed
infrastructure (what is their placement)?
Architectural Elements
• The first two questions above are absolutely central to an
understanding of distributed systems;
• what is communicating, and
• how those entities communicate
together define a rich design space for the distributed systems
developer to consider.
• It is helpful to address the first question from a system-oriented
(software) and a problem-oriented perspective.
• From a system perspective, the answer is normally very clear in that
the entities that communicate in a distributed system are typically
processes, leading to the prevailing view of a distributed system as
processes coupled with appropriate interprocess communication
paradigms
Architectural Elements
• We now turn our attention to how entities communicate in
a distributed system, and consider three types of
communication paradigm:
• interprocess communication;
• remote invocation;
• indirect communication.
Architectural Elements
• Interprocess communication refers to the relatively low-
level support for communication between processes in
distributed systems, including message-passing primitives,
direct access to the API offered by Internet protocols
(socket programming) and support for multicast
communication.
Architectural Elements
• Remote invocation represents the most common
communication paradigm in distributed systems, covering
a range of techniques based on a two-way exchange
between communicating entities in a distributed system
and resulting in the calling of a remote operation,
procedure or method
Architectural Elements
• Request-reply protocols: Request-reply protocols are
effectively a pattern imposed on an underlying message-
passing service to support client-server computing.
• In particular, such protocols typically involve a pairwise
exchange of messages from client to server and then from
server back to client, with the first message containing an
encoding of the operation to be executed at the server
and also an array of bytes holding associated arguments
and the second message containing any results of the
operation, again encoded as an array of bytes.
Architectural Elements
• Remote procedure calls: The concept of a remote procedure call (RPC),
initially attributed to Birrell and Nelson [1984], represents a major
intellectual breakthrough in distributed computing.
• In RPC, procedures in processes on remote computers can be called as if
they are procedures in the local address space. The underlying RPC
system then hides important aspects of distribution, including the
encoding and decoding of parameters and results, the passing of
messages and the preserving of the required semantics for the procedure
call.
• This approach directly and elegantly supports client-server computing with
servers offering a set of operations through a service interface and clients
calling these operations directly as if they were available locally.
• RPC systems therefore offer (at a minimum) access and location
transparency.
Architectural Elements
• Remote method invocation: Remote method invocation (RMI)
strongly resembles remote procedure calls but in a world of
distributed objects.
• With this approach, a calling object can invoke a method in a
remote object.
• As with RPC, the underlying details are generally hidden from the
user.
• RMI implementations may, though, go further by supporting object
identity and the associated ability to pass object identifiers as
parameters in remote calls.
• They also benefit more generally from tighter integration into object-
oriented languages
Architectural Elements
• Key techniques for indirect communication:
• Group communication: Group communication is concerned with
the delivery of messages to a set of recipients and hence is a
multiparty communication paradigm supporting one-to-many
communication.
• Publish-subscribe systems: Many systems, such as the financial
trading can be classified as information-dissemination systems
wherein a large number of producers (or publishers) distribute
information items of interest (events) to a similarly large number
of consumers (or subscribers).→also called distributed event-
based systems
Architectural Elements
• Key techniques for indirect communication:
• Message queues: Whereas publish-subscribe systems offer a one-
to-many style of communication, message queues offer a point-
to-point service whereby producer processes can send
messages to a specified queue and consumer processes can
receive messages from the queue or be notified of the arrival of
new messages in the queue. Queues therefore offer an
indirection between the producer and consumer processes
Architectural Elements
• Key techniques for indirect communication:
• Tuple spaces: Tuple spaces offer a further indirect
communication service by supporting a model whereby
processes can place arbitrary items of structured data, called
tuples, in a persistent tuple space and other processes can either
read or remove such tuples from the tuple space by specifying
patterns of interest. Since the tuple space is persistent, readers
and writers do not need to exist at the same time.
Architectural Elements
• Key techniques for indirect communication:
• Distributed shared memory: Distributed shared memory (DSM)
systems provide an abstraction for sharing data between
processes that do not share physical memory.
• Programmers are nevertheless presented with a familiar abstraction of
reading or writing (shared) data structures as if they were in their own local
address spaces, thus presenting a high level of distribution transparency.
• The underlying infrastructure must ensure a copy is provided in a timely
manner and also deal with issues relating to synchronization and
consistency of data.
Architectural Elements (communication
paradigm)
Architecture Styles
Layered Architecture
Object Oriented Architecture
Data Centered Architecture
Event-based Architecture

20
Architecture Styles (1/3)
• Basic idea: Organize into logically different components,
and subsequently distribute those components over the
various machines.

(a) Layered style is used for client-server system; (b) object-

based/service-oriented (SOAs) style for distributed object systems.
Architecture Styles (2/3)
• Decoupling processes in space (“anonymous”) and also time
(“asynchronous”) has led to alternative styles:

(a) Publish/subscribe and (b) Shared data space (combination of

Event based and data centered architecture)
22
Architecture Styles (3/3)
• Problem with service composition
• connecting various components is an integration nightmare
• Alternative: Resource-based Architecture
• View a distributed system as a huge collection of resources that are
individually managed by components
• Resources may be added or removed by (remote) application, retrieved or
modified
• Adopted in Web as Representational State Transfer (REST)
• Key characteristics:
• Resources are identified through a single naming scheme
• All services offer that same interface
• Message 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 execution)
System Architecture
• Describe the software components’ interaction and their
placement in a distributed system
• Types:
Centralize Architectures
Decentralized Architectures
Hybrid

24
Centralized Architectures
• Simple/basic Client–Server
Model
• Characteristics:
• There are processes
offering services (servers)
• There are processes that
use services (clients)
• Clients and servers can be
distributed across different General interaction between a
machines client and a server

• Clients follow request-reply

model/behavior with
respect to using services
25
Multi-Tiered Architectures (Physical
Distribution)
• Single-tiered: dumb terminal/mainframe configuration
• Two-tiered: client/single server configuration
• Three-tiered: each layer on separate machine
• Traditional two-tiered configurations:

26
Application Layering (logical view) (1/2)
• Traditional three-layered view:
• User-interface layer contains units for an application’s user interface
• Processing layer contains the functions of an application, i.e. without
specific data
• Data layer contains the data that a client wants to manipulate through
the application components

• This layering is found in many distributed information systems,

using traditional database technology and accompanying
applications.
• Also referred as Vertical Distribution: Placing logically different
components on different machine

27
Application Layering (logical view) (2/2)

The simplified organization of a Internet search engine into three different layers
Fat Client and Fat Server
• Fat Client: Most of the application’s code resides on client
side
• Fat Server: Most of the application’s code resides on the
server side

• What is Thin Client and Thin Server?

29
2-Tier Application
• Two-tier applications remain the most common client/server
architecture.
• The entire application is decomposed into two sets of services.
• The client combines UI services + business services and the
other data services.

SQL
or Database
File IO
Client Program
(UI + Business Logic)
running on Server machine
the client machine
TIER 1 TIER2 30
3-Tier Application
• It decomposes an application into three sets of services: UI, business,
and data.
• Business logic is moved to an application server
• Shared data to a database server

Via
Gateways

Legacy System

Business Network
Network Logic
Client Program
(UI + Business Logic)
SQL Queries
running on Server machine Database
the client machine

Server machine

TIER 1 TIER 2 TIER 3 31

2 Tier Vs 3 Tier
2Tier 3 Tier
System Administration Complex Less Complex
Security Low High
Encapsulation of Data Low High
Performance Good Good
Scalability Poor Excellent
Application Reuse Poor Excellent
Legacy Application Difficult to implement Yes (Via Gateways)
Integration
Hardware Architecture Limited Excellent
Flexibility

32
Decentralized Architectures
• Peer-to-peer systems:
• A horizontal distribution where 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, thus
balancing the load.
• Interaction between processes is symmetric: each process will
act as a client and a server at the same time (acting as a
servant)

33
Peer to Peer
• All of the processes involved in a task or activity play
similar roles, interacting cooperatively as peers
• No distinction between client and server processes or the
computers that they run on
• Aim of P2P:
• Exploit the resources (data and hardware) in a large number
participating computers for the fulfillment of a given task or
activity

34
A distributed application based on peer
processes
Peer 2

Peer 1
Ap plication

Ap plication

Sharable Peer 3
objects
Ap plication

Peer 4

Ap plication

Peers 5 .... N

35
Peer to Peer Application
• Application are
• Composed of large number of peer processes running on
separate computers
• Pattern of communication between depends on application
requirements
• An individual computer holds only a small part of the
application database and the storage, processing and
communication loads are distributed across many
computers and network links.

36
Superpeers
• Sometimes it helps to select a few nodes to do specific work:
superpeer

• Examples:
• Peers maintaining an index (for search)
• Peers monitoring the state of the network
• Peers being able to setup connections

37
Hybrid Architectures (1/2)
• Client-server architectures combined with decentralized
architecture (peer-to-peer solutions)
• Example: Edge-server architectures, which are often used for
Content Delivery Networks (example: youtube):

Internet as a collection of edge servers 38

Hybrid Architectures (2/2)
• Example: Collaborative Distributed Systems -
Combining a P2P download protocol with a client-
server architecture for controlling the downloads:
Bittorrent

• Basic idea: Once a node has identified where to

download a file from, it joins a swarm of downloaders
who in parallel get file chunks from the source, but BitTorrent Network: The middle
also distribute these chunks amongst each other. computer uploads "seed" to provide a
file to the other computers which act as
peers (Wikipedia).
39
Thank You
Question?

40