0% found this document useful (0 votes)
54 views

Chapter 2-Architectures

The document discusses different architectural styles and system architectures for distributed systems. It describes layered, object-based, data-centered, and event-based architectural styles. For system architectures, it covers centralized client-server models with one-tiered, two-tiered, and three-tiered variations as well as decentralized peer-to-peer architectures. It provides examples to illustrate each type of architecture.

Uploaded by

yekoyesew
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
54 views

Chapter 2-Architectures

The document discusses different architectural styles and system architectures for distributed systems. It describes layered, object-based, data-centered, and event-based architectural styles. For system architectures, it covers centralized client-server models with one-tiered, two-tiered, and three-tiered variations as well as decentralized peer-to-peer architectures. It provides examples to illustrate each type of architecture.

Uploaded by

yekoyesew
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 18

Chapter 2 - Architectures

Introduction

 How to organize the collection of software components


 We will discuss
 Logical organization and physical organization
 i.e., software or system architectures: how they are
organized and how they communicate
 Architectural styles
 System architectures: centralized (client-server) vs
decentralized ones (where machines play equal roles)

2
2.1 Architectural Styles
 Refers to the logical organization of distributed systems into
software components
 A component is a modular unit with well-defined, required and
provided interfaces that is replaceable within its environment;
can be replaced provided that we respect its interfaces
 A connector is a mechanism that mediates communication,
coordination, or cooperation among components, e.g., facilities
for RPC, message passing, or streaming multimedia data
 There are various architectural styles
 Layered architectures
 Object-based architectures
 Data-centered architectures
 Event-based architectures

3
 Layered Architectures
 Components are organized in a layered fashion where a
component at layer Li is allowed to call components at the
underlying layer Li-1, but not the other way around;
 Requests go down the hierarchy and results flow upward
 e.g., network layers

The layered architectural style 4


 Object-based Architectures
 Each object corresponds to a component and these components are
connected through a remote procedure call mechanism (matches the
client-server paradigm)

The object-based architectural style

5
 Data-centered Architectures
 Processes communicate through a common repository; e.g., a
shared distributed file system
 Event-based architectures
 Processes communicate through the propagation of events
(can also optionally carry data)
 Publish/subscribe systems
 Processes publish events and the middleware ensures that only
those processes that subscribed to those events will receive
them
 Processes are loosely
coupled; no need of
explicitly referring to
each other

The event-based architectural style 6


 Shared Data Spaces
 Event-based architectures combined with data-centered
architectures
 Processes are decoupled in time

The shared data-space architectural style

7
2.2 System Architectures
 Refers to the physical organization of distributed systems into
software components or how are processes organized in a
system; where do we place software components
 Deciding on software components, their interaction, and their
placement is what system architecture is all about
 Can be centralized, decentralized or a hybrid

8
2.2.1 Centralized Architectures
 Thinking in terms of clients requesting services from servers
 A server is a process implementing a specific service
 A client is a process that requests a service from a server by
sending a request and waiting for a reply
 We have a request-reply behaviour

General interaction between a client and a server

9
 Communication between client and server can be
 By a connectionless protocol if the underlying network is fairly
reliable; efficient since there is no much overhead
 But assuring reliability is difficult
 We don’t also know the source of error; was the request or the
reply lost, for instance
 When messages are lost or corrupted let the client send the
request again; applicable only for idempotent operations
 An operation is idempotent if it can be repeated multiple
times without harm; e.g., reading a record in a database
 But, transferring an amount to a bank account is not
idempotent
 See later in Chapter 8 - Fault Tolerance
 By a reliable connection-oriented protocol if the underlying
network is unreliable
 Establishing and terminating connections is expensive 10
 Application Layering
 There are many controversies about the client-server model
 e.g., no clear distinction between a client and a server; for
instance a server for a distributed database may act as a
client when it forwards requests to different file servers
 Three levels of distribution (following the layered
architecture)
 The user-interface level: implemented by clients and
contains all that is required by a client; varying from a
character-based screen to more advanced GUI-based
interfaces (more on user interfaces in Chapter 3)
 The processing level: contains the applications
 The data level: contains the programs that maintain the
actual data dealt with

11
 e.g., the general organization of an Internet search engine into three different
layers

12
 Client-Server Architectures
 How to physically distribute a client-server application across
several machines
 Multitiered Architectures

Two-tiered architecture: alternative client-server organizations

(a) Put only terminal-dependent part of the user interface on the client
machine and let the applications remotely control the presentation
13
(b) Put the entire user-interface software on the client side
(c) Move part of the application to the client, e.g. checking
correctness in filling forms
 (a) To (c) are for thin clients
(d) and (e) are for powerful client machines what are called fat clients
(more popular)
(d) and (e) are difficult to manage since client-side software is
distributed and is prone to error; it is also dependent on the
client’s platform such as operating system

14
 A server may sometimes act as a client leading to a physically
three-tiered architecture; an example is the organization of Web
sites

Three tiered architecture: an example of a server acting as a client

15
2.2.2 Decentralized Architectures
 Vertical distribution
 Refers to the ones discussed so far where the different tiers
correspond directly with the logical organization of
applications
 Place logically different components on different machines
 Horizontal distribution
 Physically split up the client or the server into logically
equivalent parts
 An example is a peer-to-peer system where processes are
equal and hence each process acts as a client and a server
at the same time (servent)
 Read about the different approaches of peer-to-peer
architecture - pages 44 - 51 and about Architectures versus
Middleware - pages 54 - 66

16
 Another example is the horizontal distribution of a Web service

17
?
18

You might also like