Architecture Styles

Architecture Styles

Getinet Y. and Rebira G. 1

 Architecture Styles
Software Model Layers

Application System System Pattern

Software Architecture Architecture Pattern

Object/Class Component Pattern

(design pattern)

123-9475775 84775.99 …
Data Structure Data Model
01010101 0xFFFFEBAAA …

Getinet Y. and Rebira G. 2

 Architecture Styles

Various Patterns for Software Arch Layer Abstraction

System Pattern: presents the macroscopic system pattern for software applications, such as batch
processing system, Web service architecture, SOA, cloud computing architecture, mobile application
system, etc.

Architecture Pattern: the architectural patterns used to design and build the software
applications/systems, such as filter-pipe, C/S, B/S, MVC, broker, three-tier arch, etc.

Component Pattern (design pattern): the design reuse of class/module that carries certain
type of structure and behavior

Data Model: the abstraction of data records through data structure design that can be used for further
processing and manipulation

Getinet Y. and Rebira G. 3

 Architecture Styles

Software Architectural Style

• A system family defined by the architectural pattern and structure
• Specifically ， it describes a common structure and a shared set of attributes for a
group of software architectures

Software Architectural Pattern

• A reused design or an architectural solution for a set of design tasks under certain
conditions

Getinet Y. and Rebira G. 4

 Architecture Styles

Types of Software Architecture

• Data Flow Architecture
- batch processing
- filter/pipe
• Data Centered Architecture
- repository design
- blackboard architecture
• Hierarchical Architecture
- layered architecture
- main/subroutine
• Interaction Oriented Architecture
- MVC (Model-View-Control)
- PAC (Presentation-Abstraction-Control)

Getinet Y. and Rebira G. 5

 Architecture Styles

Software Architecture Types (cont’d)

• Object Oriented Architecture
- OOAD
- UML model
• Component- Based Architecture
- framework approach
• Distributed Architecture
- client/server,
- peer-to-peer
- multi-tier
• Service-Oriented Architecture
- integration with business process

Getinet Y. and Rebira G. 6

 Architecture Styles
Architectural Styles

1. Client/Server Architecture Style 8. Micro services Architecture

2. Layered Architecture Style 9. Architecture in the Edge/ cloud
3. Pipeline Architecture Style 10. Big data Architecture
4. Microkernel Architecture Style 11. Machine Learning Architecture
5. Event-Driven Architecture Style
6. Space-Based Architecture Style
7. Orchestration-Driven Service-Oriented Architecture

Getinet Y. and Rebira G. 7

 Architecture Styles

1. Client Server
-- scalability is an issue at the server
Three tier architecture
-- Split the server
-- server-> web server-> application server

Getinet Y. and Rebira G. 8

 Architecture Styles

Pros of C/S Architecture

• Client program and Server application are running on separate machines, which is
good to data distribution
• Architecture transparency – Client doesn’t need to know where Server is located
• Client program and Server application may run on distinct platforms, with the focus
on various tasks
• Client program is independent and geographically separate from Server application,
which makes the deployment of system considerably flexible

Getinet Y. and Rebira G. 9

 Architecture Styles
Cons of C/S Architecture
• Since a certain amount of functions is built on the Client side, the Client program
tends to grow and become large, makes it hard to main and upgrade.
• The Clients are connected to the centralized Server through LAN network, which
limits the system scalability due to the network bandwidth.
• The standard, platform and technology used for the Client program are
heterogeneous, which adds to the development and maintenance cost
• If the central system(server) fails the whole system stops working (Single point of
failure).

Getinet Y. and Rebira G. 10

 Architecture Styles

Browser-Server (B/S) Architecture

Client

Getinet Y. and Rebira G. 11

 Architecture Styles
Pros of B/S Architecture
• The Client is a simple browser (kind of thin client) program, which is easy
to use and maintain
• Based on the standard HTTP protocol ， it is easy to build a cross-
platform s/w system. The Server is totally separated from the Client
• Development focus is on the Server application, i.e. at the backend,
which greatly reduces the development and maintenance cost
• Since Clients are connected to the Server through the Internet (WAN), its
scalability is greatly improved

Getinet Y. and Rebira G. 12

 Architecture Styles

Cons of B/S Architecture

• The majority of work is placed on the Server end, which makes the web
server a single point of failure (SPOF)
• The interaction and data exchange between Client and Server is
completed via Internet, with a limited transmission speed, so it’s not
quite appropriate for the Online Transaction Processing (OLTP) system
• Since the system is exposed to the Internet world, its security is an issue

Getinet Y. and Rebira G. 13

 Architecture Styles

An Improvement to B/S Architecture

Multi-tier architecture

Getinet Y. and Rebira G. 14

 Architecture Styles

Applications
•Web Applications - client is a web browser and the server is a web server that provides data
and services to the client.
•Database Systems - a database client application and the server is a database server that
provides data storage and retrieval services to the client.
•Gaming Systems - the client is a game client application and the server is a game server that
provides game logic and data to the client.
•Messaging Systems - the client is a messaging client application and the server is a
messaging server that provides message storage and delivery services to the client.
•File Sharing Systems - such as FTP and BitTorrent, where the client is a file transfer client
application and the server is a file transfer server that provides file storage and retrieval
services to the client.

Getinet Y. and Rebira G. 15

 Architecture Styles

2. layered architecture – Structural Model

Applications

Domain-Specific
Services
Common
Middleware Services
Distribution
Middleware
Host Infrastructure
Middleware

O/S and Protocols

Hardware Layer

Getinet Y. and Rebira G. 16

 Architecture Styles

layered architecture

Getinet Y. and Rebira G. 17

 Architecture Styles

Layered architecture

Getinet Y. and Rebira G. 18

 Architecture Styles
layered architecture

Getinet Y. and Rebira G. 19

 Architecture Styles
Applications
•Web Applications - Layered architecture is widely used in web applications, where the
presentation layer, business logic layer, and data access layer are separated to improve
maintainability and scalability.
•Operating Systems - Layered architecture is used in operating systems, such as Windows
and Linux, to provide a modular and extensible platform for building complex systems.
•Database Systems - Layered architecture is used in database systems, such as Oracle and
MySQL, to separate the data storage layer from the data access layer, improving
performance and scalability.
•Communication Systems - Layered architecture is used in communication systems, such as
TCP/IP and OSI, to provide a modular and extensible platform for handling network traffic.
•Financial Systems - Layered architecture is used in financial systems, such as banking and
trading systems, to separate the business logic layer from the presentation layer, improving
security and reliability.

Getinet Y. and Rebira G. 20

 Architecture Styles

3. Pipe-Filter
• Every functional unit has a group of input/output interface.
• functional blocks: Filters
• output/input connections: Pipes
• Filter is an independent unit that has no interactions with other filters
• Filter is also an stateless running unit that does not have impact to
other filter’s state.

Getinet Y. and Rebira G. 21

 Architecture Styles
3. Pipe-Filter
• The output of filters are order-free and independent to that of other
filters’
Pipes Filters

Getinet Y. and Rebira G. 22

 Architecture Styles
3. Pipe-Filter
Nested Pipe-Filter Architecture

Getinet Y. and Rebira G. 23

 Architecture Styles
3. Pipe-Filter
• Reuse of functional units in Pipe-Filter
• Any two independent filter units can be connected and used as a composition unit as
long as they support the same pipe interface
• Better maintenance and expandability
• Support data-centric concurrency
• Easy for certain types of performance assessment, such as system throughput or
deadlock examination
• Not appropriate for online processing systems that involve user interactions

Getinet Y. and Rebira G. 24

 Architecture Styles

Application

•Compiler Design - to break down the compilation process into a series of independent
steps, such as lexical analysis, syntax analysis, and code generation.

Getinet Y. and Rebira G. 25

 Architecture Styles

4. Microkernel Architecture Style

• Also referred to as the plug-in architecture)
• Relatively simple monolithic architecture consisting of two architecture components:
• a core system and
• plug-in components.
• Application logic is divided between
independent plug-in components and the
basic core system.
• Providing extensibility, adaptability, and
isolation of application features and
custom processing logic.
Basic components of the microkernel architecture style

Getinet Y. and Rebira G. 26

 Architecture Styles

4. Microkernel Architecture Style

• Core System
• The core system is formally defined as the minimal functionality required to run the
plug-ins components.
• The core system can also be general processing flow through the application, with little
or no custom processing
• Depending on the size and complexity, the core system can be implemented as a
layered architecture or a modular monolith
• Example Payment Processing is a core system, payment methods such as Pay pal, credit
card, store gift are domain specific component plug-ins in Payment Processing Core
system.

Getinet Y. and Rebira G. 27

 Architecture Styles

4. Microkernel Architecture Style

• Core System
• The presentation layer of the core system
• embedded within the core system
• implemented as a separate user interface,
with the core system providing backend
services
• user interface can also be implemented as
a microkernel architecture style.

Getinet Y. and Rebira G. 28

 Architecture Styles

4. Microkernel Architecture Style

Plug-In Components
• Standalone, independent contains specialized processing.
• Should be independent of each other and have no dependencies between them.
• The communication with the core system is generally point-to-point, REST, Messaging.
• can be either compile-based or runtime-based. Run time components are hot pluggable.
without having to redeploy the core system or other plug-ins.
• Plug-ins are managed through frameworks such as Open Service Gateway Initiative
(OSGi) for Java, Prism (.NET).
• Point-to-point plug-in components can be implemented as shared libraries (such as a JAR,
DLL, or Gem), package names in Java, or namespaces in C#.

Getinet Y. and Rebira G. 29

 Architecture Styles

4. Microkernel Architecture Style

Plug-In Components

Shared library plug-in implementation Package or namespace plug-in implementation

Getinet Y. and Rebira G. 30

 Architecture Styles

4. Microkernel Architecture Style

Plug-In Components
• Plug-in components can also be a REST or
messaging as a means to invoke plug-in
functionality.
• This has the benefits of overall Remote plug-in access using REST
component decoupling.
• Allows for better scalability and throughput, and runtime changes without any special
frameworks like OSGi.
• However, with these benefits come with trade-offs.
• Remote plug-in access turns the microkernel architecture into a distributed
architecture rather than a monolithic. Which add complexity on implementation and
deployment.

Getinet Y. and Rebira G. 31

 Architecture Styles

4. Microkernel Architecture Style

Plug-In Components
• A pug-ins registry mainly assists the core system to know/locate about which plug-in
modules are available and how to get to them.
• Registry contains information about each plug-in module, including things like its name,
data contract, and remote access protocol details.
Contracts
•The contracts between the plug-in components and the core system are usually standard
across a domain of plug-in components.
•Contracts include the behavior, input data, and output data returned from the plug-in
component.
•Plug-in contracts can be implemented in XML, JSON, or even objects passed back and forth
between the plug-in and the core system.

Getinet Y. and Rebira G. 32

 Architecture Styles

4. Microkernel Architecture Style

Contracts
• For example Java inter face named AssessmentPlugin defines the overall behavior
assess(), register(), and deregister(), along with the corresponding output data expected
from the plug-in component (AssessmentOutput):

Getinet Y. and Rebira G. 33

 Architecture Styles

4. Microkernel Architecture Style

Contracts
• Some examples include the Eclipse IDE, PMD, Jira, and Jenkins, to name a few). Internet
web browsers such as Chrome and Firefox are another common product example using
the microkernel architecture:

Architecture Characteristics Ratings

One star (*) lowest support and five

start (*****) strongest support
rating

Getinet Y. and Rebira G. 34

 Architecture Styles

Applications
•Embedded Systems - such as automotive systems, medical devices, and industrial control
systems, where reliability, safety, and real-time performance are critical.
•Operating Systems - such as QNX and MINIX, to provide a modular and extensible platform
for building complex systems.
•Cloud Computing - such as OpenStack and Cloud Foundry, to provide a flexible and scalable
infrastructure for deploying and managing applications.
•Mobile Devices - such as Android and iOS, to provide a secure and efficient platform for
running applications.
•Network Infrastructure - such as routers and switches, to provide a modular and scalable
platform for handling network traffic.

Getinet Y. and Rebira G. 35

 Architecture Styles

5. Event driven architecture

• Popular distributed asynchronous architecture
style used to produce highly scalable and high-
performance applications.
• Event driven architecture: synchronous,
decoupled; each component is autonomic.

• It is made up of decoupled event processing components that asynchronously receive and

process events.
• Mainly follow request-based model which
• requests are send to a request orchestrator (a user interface, an API layer or enterprise
service bus).

Getinet Y. and Rebira G. 36

 Architecture Styles

5. Event driven architecture

• The request orchestrator deterministically and synchronously direct requests to various
request processors.
• The request processors handle the request, either retrieving or updating information in a
database.

Request-based model

Getinet Y. and Rebira G. 37

 Architecture Styles

5. Event driven architecture

Topology
• Two primary topologies within event-driven architecture: the mediator topology and the
broker topology.
• The mediator topology is commonly used when you require control over the workflow of
an event process, whereas,
• The broker topology is used when you require a high degree of responsiveness and
dynamic control over the processing of an event.
Broker topology
• Differs from the mediator topology in that there is no central event mediator
• The message flow is distributed across the event processor components
• This topology is useful do not need central event orchestration and coordination

Getinet Y. and Rebira G. 38

 Architecture Styles

5. Event driven architecture

Broker topology
• There are four primary architecture components within the broker topology:
• an initiating event,
• the event broker ,
• an event processor ,
• a processing event.

Broker topology
Trade-off of the broker topology

Getinet Y. and Rebira G. 39

 Architecture Styles

• A jewelry store example, a

breach of any of the security
devices, such as breaking a
window, creates an event that is
sent directly to the broker.

• The broker communicates the event notification directly to the event processors. Since
nothing is asynchronous, no event queue is required. At the end of each process,
notification of completion is issued by the event processors.

Getinet Y. and Rebira G. 40

 Architecture Styles

5. Event driven architecture

Mediator Topology
• Manages and controls the workflow for initiating events that require the coordination
of multiple event processors.
• The architecture components that make up the mediator topology are
• an initiating event starts the whole evening process
• an event queue  store events before sent to the mediator,
• an event mediator  passes events to the event processing,
• event channels  a routing node in the event processing  and
• event processors  process the event, and respond completion back to the
mediator.

Getinet Y. and Rebira G. 41

 Architecture Styles
Mediator Topology
• There are multiple mediators,
associated with a particular
domain or grouping of events.
• This reduces the single point of
failure and increases overall
throughput and performance.

Mediator topology

Getinet Y. and Rebira G. 42

 Architecture Styles
Mediator Topology

• The choice between the broker and mediator topology essentially comes down to a trade-
off between workflow control and error handling capability versus high performance and
scalability.

Getinet Y. and Rebira G. 43

 Architecture Styles
Mediator Topology

• For example at Fort Knox, many things must happen instantly and some
later on. These include a complex series of time-critical events such as
alerts to enforcement personnel, shutting of emergency doors, lights
coming on, and warning siren.
Getinet Y. and Rebira G. 44
 Architecture Styles
Some of the application areas of event-driven software architecture include:
1. Internet of Things (IoT) - used in IoT applications to handle the large volume
of data generated by sensors and devices.
2. Financial Services - used in financial services to handle real-time trading, risk
management, and fraud detection.
3. E-commerce - used in e-commerce applications to handle real-time inventory
management, order processing, and payment processing.
4. Healthcare - used in healthcare applications to handle real-time patient
monitoring, alerting, and diagnosis.
5. Gaming - is used in gaming applications to handle real-time game events, such
as player movements, actions, and interactions.
6. Social Media - used in social media applications to handle real-time user
interactions, such as likes, comments, and shares.
Getinet Y. and Rebira G. 45
 Architecture Styles

Thanks ！

Getinet Y. and Rebira G. 46