Architectural

Styles
SE205.3
Level 2

Diluka Wijesinghe ([email protected])

Faculty of Computing | NSBM Green University
What is an Architectural Style?
A software architectural style is
a set of principles that shapes
the structure and organization
of a software system. It
provides a framework for
specifying the structure of a
system in terms of its
components and how these
components interact.
Common Architectural Styles

1 Publish 2 Layered
Subscribe
3 Shared data 4 Client Server

5 Peer to Peer 6 MVC

7 Pipes and Filters

Publish-Subscribe Architecture
Consider a scenario of synchronous message passing. You
have two components in your system that communicate with
each other. Let’s call the sender and receiver. The receiver
asks for a service from the sender and the sender serves the
request and waits for an acknowledgment from the receiver.

• There is another receiver that requests a service from the

sender. The sender is blocked since it hasn’t yet received
any acknowledgment from the first receiver.
• The sender isn’t able to serve the second receiver which
can create problems. To solve this drawback, the Pub-Sub
model was introduced.
Publish-Subscribe Architecture
The Publisher-Subscriber (Pub-Sub) architectural style is a
messaging pattern where publishers send messages without
knowing who will receive them, and subscribers receive
messages without knowing who sent them. This decouples the
producers of information (publishers) from the consumers of
that information (subscribers).
• Publishers: Entities that generate and send messages.
• Subscribers: Entities that receive and consume messages.
• Topics: Channels or categories to which messages are
published.
• Message Brokers: Intermediaries that manage the routing of
Publish-Subscribe Architecture
Example Publish-Subscribe Architecture

Consider a news application:

1. Publishers: Various news agencies publish news articles to

different topics like "Sports", "Politics", "Technology".
2. Subscribers: Users subscribe to their topics of interest.
3. Topic: Page 02
4. Broker: The news application’s backend service routes new
articles to all users subscribed to the corresponding topics.
Characteristics Publish-Subscribe
Architecture
• Decoupling: Publishers and subscribers are decoupled. They
do not need to know about each other's existence.
• Scalability: Supports a many-to-many relationship between
publishers and subscribers.
• Flexibility: Easy to add or remove publishers and
subscribers without affecting the system.
• Asynchronous Communication: Messages are often
delivered asynchronously, allowing for non-blocking
Use cases of Publish-Subscribe
Architecture
• Real-time Systems: Applications requiring real-time updates, like
stock trading platforms, multiplayer online games, and live sports
updates.
• Event-Driven Architectures: Systems that respond to events,
such as IoT systems, where devices generate data and other
components act on that data.
• Notification Services: Sending notifications to users based on
specific events, like email alerts, push notifications, or SMS
alerts.Microservices
Layered Style

As the name suggests, components(code) in this pattern are

separated into layers of subtasks and arranged above one
another. Each layer has unique tasks to do and all the layers
are independent. Since each layer is independent, one can
modify the code inside a layer without affecting others. It is
the most commonly used pattern for designing the majority
of software. This layer is also known as ‘N-tier architecture’.
This pattern has 4 layers.
Layered Architecture
Layered Architecture
1. Presentation Layer (UI Layer):
• Responsibilities: Manages the user interface and user
interaction. It displays data to the user and sends user
commands to the lower layers.
• Examples: Web pages, mobile app screens, and desktop
application windows.
• Technologies: HTML/CSS/JavaScript for web applications,
Swift for iOS apps, Kotlin for Android apps.

2. Business Logic Layer (Domain Layer):

• Responsibilities: Contains the core functionality and
business rules of the application. It processes data and
applies business rules.
Layered Architecture

3. Data Access Layer (Persistence Layer):

• Responsibilities: Manages data storage and retrieval. It
interacts with databases and other data sources.
• Examples: Data Access Objects (DAOs), repositories.
• Technologies: SQL, Hibernate, Entity Framework.

4. Database Layer:
• Responsibilities: Manages the actual storage of data.
• Examples: Relational databases (MySQL, PostgreSQL),
NoSQL databases (MongoDB, Cassandra).
• Technologies: Database management systems (DBMS).
Example of Layered Architecture
Consider an e-commerce application:

Presentation Layer:
• Displays product listings, shopping carts, and checkout forms.
• Handles user input and sends requests to the business logic
layer.
Business Logic Layer:
• Processes user actions like adding items to the cart, applying
discounts, and calculating totals.
• Validates user input and applies business rules.
Data Access Layer:
• Interacts with the database to fetch product details, store user
information, and manage orders.
• Uses SQL queries or an ORM (Object-Relational Mapping) tool to
manage data.
Benefits of Layered Architecture

• Modularity: Each layer can be developed, tested, and

maintained independently.
• Reusability: Components within a layer can be reused across
different parts of the application or in different applications.
• Maintainability: Changes in one layer have minimal impact
on other layers, making it easier to update and maintain the
system.
• Scalability: Individual layers can be scaled independently to
Shared Data Architecture

The Shared Data architectural style revolves around a central

repository where data is stored and accessed by various
components or systems. This pattern is particularly useful for
applications that require a high level of data consistency and
where multiple components need to share the same data.
Shared Data Architecture
Key Concepts

1. Central Repository: A single data source that holds the data

shared by multiple components.
2. Components: These are the different parts of the application
that interact with the central repository.
3. Data Access: The mechanisms through which components
read from and write to the central repository.
Shared Data Architecture
Shared Data Architecture
Structure

1. Central Data Store: This could be a database, a file system, or

any other centralized data storage mechanism.
2. Data Access Components: These components are responsible for
accessing the data in the central repository. They can include:
• Data Access Objects (DAOs)
• Repositories
• APIs
3. Processing Components: These components perform operations
on the data. They can include:
• Business logic components
• Service layers
• Data processing modules
Characteristics of Shared Data
Architecture
1. Data Consistency: Ensures that all components have a consistent
view of the data.
2. Simplicity: Simplifies data management by centralizing data
storage.
3. Scalability: Can be challenging to scale as the central repository
can become a bottleneck.
4. Coupling: Components are often tightly coupled to the data
schema of the central repository.
Use Cases of Shared Data Architecture

1. Enterprise Applications: Systems where multiple departments or

modules need access to the same data, such as CRM and ERP
systems.
2. Content Management Systems (CMS): Centralized storage of
content that is accessed and managed by various users and
components.
3. Data Warehousing: Central repositories that collect data from
multiple sources for reporting and analysis.
Example of Shared Data Architecture

Consider a hospital management system where patient records

need to be accessed by various departments such as reception,
doctors, billing, and pharmacy.
1. Central Repository: A database that stores patient records.
2. Components:
• Reception Module: Reads and writes patient check-in data.
• Doctor Module: Reads patient medical history and updates
diagnosis and treatment records.
• Billing Module: Reads patient treatment records and
updates billing information.
• Pharmacy Module: Reads prescriptions and updates
Client Server Architecture

The Client-Server architectural style is a widely used design pattern

that separates a system into two main components: clients and
servers. Clients request services and resources, while servers
provide these services and resources. This architecture is
foundational to many types of networked applications, including
web applications, email systems, and database systems.
Client Server Architecture

Key Concepts
1. Client: A component that initiates requests to a server. Clients
are typically user-facing applications, such as web browsers,
mobile apps, or desktop applications.
2. Server: A component that receives and processes requests from
clients. Servers provide services, such as hosting web pages,
running applications, or storing data.
3. Network: The communication medium that connects clients and
servers. This can be a local network (LAN) or the internet.
Client Server Architecture
Client Server Architecture

Structure

1. Client: Sends requests to the server and waits for responses.

2. Server: Listens for requests from clients, processes these
requests, and sends back responses.
3. Network: Facilitates communication between clients and
servers.
Characteristics of Client Server
Architecture
Characteristics
• Centralization: The server centralizes resources and
services, making it easier to manage and secure data.
• Scalability: Servers can be scaled vertically (adding more
resources to a single server) or horizontally (adding more
servers).
• Decoupling: Clients and servers are decoupled, allowing
each to be developed, maintained, and scaled
independently.
•
Use Cases Client Server Architecture
Use Cases
• Web Applications: Web browsers (clients) request web
pages from web servers.
• Email Systems: Email clients (like Outlook) communicate
with email servers (like Microsoft Exchange).
• Database Systems: Applications (clients) query databases
(servers) to retrieve or store data.
When a user types a URL into their browser, the browser (client)
sends an HTTP request to the web server. The server processes the
request, retrieves the requested web page, and sends an HTTP
response back to the browser, which then displays the page to the
Peer-to-Peer Architecture
The Peer-to-Peer (P2P) architectural style is a decentralized network
model where each participant, referred to as a peer, acts as both a
client and a server. In a P2P network, peers share resources directly
with each other without the need for a centralized server.
Key Concepts

1. Peers: Individual nodes in the network that both provide and

consume resources.
2. Decentralization: Unlike client-server models, there is no central
authority or server. Each peer is equally privileged.
3. Resource Sharing: Peers share resources such as files, processing
Characteristics of Peer-to-Peer
Architecture
• Scalability: P2P networks can easily scale as more peers
join since each new peer contributes additional resources.
• Fault Tolerance: The decentralized nature of P2P networks
makes them resilient to failures; if one peer goes down,
others can continue functioning.
• Resource Distribution: Resources are distributed across all
peers, preventing bottlenecks and reducing the risk of a
single point of failure
Peer-to-Peer Architecture
Use Cases of Peer-to-Peer Architecture
• File Sharing: Applications like BitTorrent allow users to
share files directly with each other.
• Content Distribution: Platforms like peer-to-peer
streaming services distribute content directly between
users.
• Cryptocurrencies: Blockchain technologies, such as
Bitcoin, rely on P2P networks for transaction processing
and validation.
• Distributed Computing: Projects like SETI@home use P2P
Example of Peer-to-Peer Architecture

Consider a file-sharing application:

• Peers: Users' devices that share and download files.
• Network: The internet, allowing peers to connect and
transfer files directly.
• When a user wants to download a file, their peer
software locates other peers that have the file and
downloads pieces of the file from multiple sources. This
distributes the load and speeds up the download
MVC Architecture

The Model-View-Controller (MVC) architectural pattern is a

design paradigm used for developing user interfaces that
separates an application into three interconnected
components. This separation of concerns facilitates
modularity, maintainability, and testability.
MVC Architecture
MVC Architecture
1. Model:
• Represents the application's data and business logic.
• Manages the data, logic, and rules of the application.
• Responds to requests for information about its state and can
change its state in response to instructions.
• Examples: Database schemas, business rules, data access
methods.
2. View:
• Represents the UI elements that render the model's data to the
user.
• Displays data from the model and sends user commands to the
controller.
• Examples: HTML pages, GUI components, web templates.
3. Controller:
• Acts as an intermediary between the model and the view.
• Responds to user input and interacts with the model to perform
MVC Architecture

1. Separation of Concerns: Each component has a distinct

responsibility, making the system easier to manage and
evolve.
2. Reusability: Components can be reused across different
parts of the application or in different applications.
3. Testability: The clear separation between components
facilitates unit testing.
Use Cases of MVC Architecture

1. Web Applications: MVC is commonly used in web

frameworks like Ruby on Rails, Django, and ASP.NET.
2. Desktop Applications: Frameworks like Java Swing and .NET
Windows Forms often use MVC or similar patterns.
3. Mobile Applications: MVC can be adapted for mobile
development, with frameworks like iOS's UIKit supporting
the pattern.
Example of MVC Architecture

Consider a simple web application for managing tasks:

1. Model: Defines the task data, including attributes like
task name, description, and status.
2. View: Displays a list of tasks and forms for creating or
editing tasks.
3. Controller: Handles user actions like adding a new task,
updating an existing task, or deleting a task.
Pipe-and-Filter Architecture

The Pipe-and-Filter architectural style is a design pattern used

for streamlining the processing of data by breaking down a
complex processing task into a sequence of smaller, discrete
steps. Each step is encapsulated in a filter component, and
these filters are connected by pipes, which pass data from
one filter to the next.
Pipe-and-Filter Architecture
Pipe-and-Filter Architecture

Key Concepts
1. Filter: A processing component that transforms input
data into output data. Filters are designed to be
independent and reusable.
2. Pipe: A conduit that transports data from one filter to the
next. Pipes are responsible for data transfer but do not
process data themselves.
3. Pipeline: The overall sequence of connected filters and
Pipe-and-Filter Architecture

Structure
1. Filters: Perform specific processing tasks, such as data
transformation, aggregation, or validation.
2. Pipes: Transfer data between filters, ensuring a
unidirectional flow.
3. Pipeline: The entire sequence of filters and pipes,
representing the complete processing workflow
Characteristics of Pipe-and-Filter
Architecture
1. Modularity: Filters are self-contained and can be developed,
tested, and maintained independently.
2. Reusability: Filters can be reused across different pipelines
or applications.
3. Flexibility: Pipelines can be easily reconfigured by adding,
removing, or rearranging filters.
4. Scalability: Pipelines can be scaled by parallelizing filters or
distributing them across multiple nodes.
Use Cases of Pipe-and-Filter
Architecture
1. Data Processing: ETL (Extract, Transform, Load) processes
in data warehousing.
2. Compiler Design: Lexical analysis, syntax analysis, and
code generation stages in compilers.
3. Multimedia Processing: Audio and video processing
pipelines.
4. Network Protocol Stacks: Processing network packets
through various protocol layers.
Example of Pipe-and-Filter Architecture
Consider a data processing application that reads data from a
file, processes it, and writes the output to another file:
1. Filters:
• ReadFilter: Reads data from the input file.
• ProcessFilter: Processes the data (e.g., data
transformation).
• WriteFilter: Writes the processed data to the output file.
2. Pipes:
• Pipe1: Connects ReadFilter to ProcessFilter.