2.

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 …
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
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
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)
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
Architectural Styles
1. Client/Server Architecture Style 8. Micro services Architecture
2. Layered Architecture Style 10. Architecture in the Edge/ cloud
3. Pipeline Architecture Style
4. Microkernel Architecture Style
5. Event-Driven Architecture Style
6. Space-Based Architecture Style
7. Orchestration-Driven Service-Oriented Architecture
1. Client Server
-- scalability is an issue at the server
Three tier architecture
-- Split the server
-- server-> web server-> application server
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 to and geographically separate from Server
application, which makes the deployment of system is considerably flexible
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
Browser-Server (B/S) Architecture
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
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
An Improvement to B/S Architecture

Multi-tier architecture
2. layered architecture – Structural Model

Applications

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

O/S and Protocols

Hardware Layer
layered architecture
Layered architecture
layered architecture
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
3. Pipe-Filter
■ The output of filters are order-free and independent to that of other
filters’
3. Pipe-Filter
Nested Pipe-Filter Architecture
 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
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.
• The core system is formally defined as the Basic components of the
microkernel architecture
minimal functionality required to run the style
plug-in components.
4. Microkernel Architecture Style
• Core System
• The core system is formally defined as the minimal functionality required to run the
system.
• 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.
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.
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#.
4. Microkernel Architecture Style
Plug-In Components

Shared library plug-in Package or namespace

implementation plug-in implementation
 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
component decoupling. using REST
• Allows for better scalability and throughput, and runtime changes without any special
frameworks like OSGi.
• However, with these benefits comes 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.
 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.
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):
 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
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).
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
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
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.

Trade-off of the broker Broker topology

topology
• 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.
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.
 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
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.
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.
Thanks！