Architectural Styles

1
Introduction

Over the years a lot of experience has been
gained

Certain patterns and structures appear very often

Therefore architectural patterns are discovered,
not invented

Vocabulary is used by designers to think and talk
about the architectural design

An architectural style is a particular pattern that
focuses on the large-scale structure of a system
typically described by the common vocabulary

* Vocabulary – a range of stylistic forms, techniques or movements 2

Patterns and Styles

Architectural pattern – define the

implementation strategies of those
components and connectors (‘how?’)
Architectural styles – define the
components and connectors
(‘what?’)
Those make use of design
patterns

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic,
and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. 3
Architectural Patterns

An architectural pattern is a set of

architectural design decisions that are
applicable to a recurring design problem, and
parameterized to account for different
software development contexts in which that
problem appears.

Architectural patterns applied “at a lower
level” and within a much narrower scope.

4
Architectural Styles

An architectural style is a named collection of
architectural design decisions that
 are applicable in a given development context

 constrain architectural design decisions that are

specific to a particular system within that
context
 elicit beneficial qualities in each resulting
system

Reflect less domain specificity than architectural
patterns

Useful in determining everything from subroutine
structure to top-level application structure
5
Architectural Style

6
Basic Properties of Styles

A vocabulary of design elements
 Component and connector types; data elements

 e.g., pipes, filters, objects, servers

A set of configuration rules
 Topological constraints that determine allowed
compositions of elements
 e.g., a component may be connected to at most
two other components

A semantic interpretation
 Compositions of design elements have well-
defined meanings

Possible analyses of systems built in a style
7
Benefits of Using Styles

Design reuse
 Well-understood solutions applied to new problems

Code reuse
 Shared implementations of invariant aspects of a style

Understandability of system organization
 A phrase such as “client-server” conveys a lot of
information

Interoperability
 Supported by style standardization

Style-specific analyses
 Enabled by the constrained design space

Visualizations
 Style-specific depictions matching engineers’ mental
models
8
Some Common Styles

“Basic” styles
 Pipe and filter (data-flow style)
 Object-oriented (traditional, language-influenced styles)
 Layered
 Blackboard (Shared memory)
 State transition
 Client-server (Layered)
 Peer-to-peer
 Event-based (a.k.a. Implicit invocation)
 Publish-Subscribe
 Mobile-code (interpreter)

“Derived” styles
 Koala
 CORBA
 Pipe and Filter Style
 Components are filters
 Processing units
 Transform input data streams into output data streams
 Possibly incremental production of output
 Connectors are pipes
 Channels for data streams
Input Circular Output
Medium Input Shift Alphabetizer Output Medium

 Style invariants
 Filters are independent (no shared state)
 Filter has no knowledge of up- and down-stream filters
 Example:
 UNIX shell
Pipe and Filter Style

11
 Example: UNIX/LINUX
Linux has a lot of filter commands like awk, grep, sed, spell, and wc. A filter takes
input from one command, does some processing, and gives output.
cat sample
Bat
Goat
Apple
Dog
First
Eat
Hide
Highlight only the lines that do not contain the character ‘a’, and the result should
be in reverse order.
cat sample | grep –v a | sort – r
Hide
First
Dog
Apple
*The grep command - to find strings and values in a text document
https://www.guru99.com/linux-pipe-grep.html 12
 Pipe and Filter Style (cont.)

Advantages
 System behavior is a succession of component behaviors
 Filter addition, replacement, and reuse (possible to hook

any two filters together)

 Easy to analyze (throughput, latency, deadlock)

 Support concurrent/parallel execution

 Helps scalability, maintainability, evolvability

Disadvantages
 Often lead to batch processing
 Poor for interactive applications

 Poor performance for data elements (such as words,

lines, etc) where each filter has to parse/unparse the data

Object-Oriented Style

Components are objects
 Data and associated operations

Connectors are messages and method invocations

14
Object-Oriented Style

Style invariants
 Objects are responsible for their internal representation

integrity
 Internal representation is hidden from other objects

Advantages
 Because an object hides its data representation from its

clients, it is possible to change the implementation

without affecting those clients.
 System decomposition into sets of interacting agents

Disadvantages
 Objects must know identities of servers/other objects to

interact
 Inefficient for high performance applications
Object-Oriented Style (cont.)
Object-Oriented Style (cont.)

17
Layered Style

Hierarchical system organization
 “Multi-level client-server”
 Each layer exposes an “API” (interface) to be
used by above layers

Each layer acts as a
 Server: service provider to layers “above”
 Client: service consumer from layers “below”

Connectors are protocols of layer interaction
Layered Style (cont.)
Summary:
An ordered sequence of layers,
each layer offers services
(interfaces) that can be used by
programs (components) residing
with the layer(s) above it.
Design Elements:
- Components: layers
- Connectors: typically method or
procedure calls
- Data: parameters passed
between layers
Topology:
Linear (strict layering), acyclic Example
(non-strict layering)
Layered Style (cont.)

Examples
 Layered Style (cont.)

Advantages
 Increasing abstraction levels

 Evolvability

layers are independent

different implementations of layer are allowed as long as interface
is unchanged
 Reuse – e.g., standardized layer interfaces for libraries and
frameworks

Disadvantages
 Not universally applicable

 Performance is not well served (mostly for strict layering and

have many layers)

Layers may have to be skipped
 Determining the correct abstraction level (if existing systems
cross several layers)
an abstraction layer or abstraction level is a way of hiding the working details of a subsystem, allowing the
separation of concerns to facilitate interoperability and platform independence. Examples of software models that
use layers of abstraction include the OSI model for network protocols, OpenGL and other graphics libraries.
 Client-Server Style

Similar to layered style, but only have two layers
(Client and Server)

Instance of a more general style
 Distributed systems

Components are clients and servers

Servers do not know number or identities of
clients

Clients know server’s identity

Connectors are 1RPC-based interaction
protocols
1remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to
execute in a different address space
Client-Server Style (cont.)
Summary:
Client initiates communication by
sending server a request and
server performs the requested
action and replies.
Design Elements:
- Components: client(s), server
- Connectors: remote procedure
calls, network protocols
- Data: parameters and return
values
Topology:
- Two-level, multiple clients
making requests to server
- No client-client communication Example
Client-Server Style (cont.)

Advantages
 Data centralization, powerful server serving many
clients

Disadvantages
 Single point of failure
 Network bandwith/amount of requests

*bandwidth is the maximum rate of data transfer across a given path 24

Blackboard Style

Two kinds of components
 Central data structure — blackboard
 Components operating on the blackboard

Independent programs access and communicate

exclusively through a global data repository -> blackboard

A blackboard has three basic components
 Knowledge source: independent pieces of application
specific knowledge
 Blackboard: repository of problem-solving state,

organized in an application-dependent hierarchy: level n

(highest) to level 1 (lowest)
 Connector/control: access to blackboard maybe by
direct memory reference or can be through procedure
call or database query
Blackboard Style (cont.)
Summary:
Separate programs communicate
through the shared repository (i.e.
blackboard)
Design Elements:
- Components: shared blackboard,
independent programs (i.e.
knowledge sources)
- Connectors: depends on the
context (e.g., calls, queries, direct
references…)
- Data: stored on the blackboard Example
Topology:
Star, the blackboard as the central
node
 Blackboard Style (cont.)

Blackboard – manages
central data
Knowledge source –
evaluates its own
applicability, computes a
result, update blackboard
Control – monitors
blackboard, schedules
knowledge source activations

Knowledge sources (a set of problem solving modules) share a common global

database (blackboard). Knowledge sources respond to changes on the
blackboard, and interrogate and subsequently directly modify the blackboard.

27
HEARSAY II used a blackboard architecture to recognize human speech.

28
Blackboard Style (cont.)

Example
A distributed computing model for a metaphor describing how people
work together to collaboratively solve a problem around a blackboard

29
Blackboard Style (cont.)

Advantages
 Solution strategies should not preplanned
 Data/problem determine the solutions

Disadvantages
 Overhead when a straight-forward solution
strategy is available
 Interaction between “independent” programs need
a complex regulation
 Data on the blackboard is a subject to frequent
change (and requires propagation to all other
components)
30
 Implicit Invocation Style

Event announcement instead of method invocation
 “Listeners” register interest in & associate methods with
events
 System invokes all registered methods implicitly

Component interfaces are methods and events

Two types of connectors
 Invocation is either explicit or implicit in response to events

Style invariants
 “Announcers” are unaware of their events’ effects, if any

 No assumption about processing in response to events

 Next, the system determines the
listeners for LoginEvent; in this
case there is only one—the
AuthenticationListener.
Determined by a configuration file,
the system invokes the
AuthenticationListener’s tryLogin()
method, passing to it the event.
Based on information in the event,
the tryLogin() method will seek to
authenticate the user. If the
authentication succeeds, a new
LoginAcceptedEvent is triggered.
If authentication fails, a new
In this example, a login form is filled LoginFailedEvent is triggered. The
out by a user and the form submitted. cycle then continues, with any
The incoming HTTP request triggers listeners of the new event being
the creation of a LoginEvent, and the notified.
system populates the event with
information in the request.

Components that wish to act as listeners are registered to listen for certain events at configuration time (by
specification in an XML file, for instance). When an event is triggered, all registered listeners of that event are
passed the event by means of a dynamically determined method call. In this way, functions are implicitly 32
invoked. This process of notifying listeners of an event is called event announcement.
Publish-Subscribe Style
 Distinguished from pull-based (e.g., the Web)
 Subscribers register/deregister to receive specific
messages or specific content. Publishers broadcast
messages to subscribers either synchronously or
asynchronously.
 Publish-Subscribe Style (cont.)

Summary:
Subscribers register/deregister to receive specific messages or
specific content. Publishers broadcast messages to subscribers
synchronously or asynchronously.

Design Elements:
 Components: publishers, subscribers, proxies for managing

distribution
 Connectors: typically a network protocol is required.

Content-based subscription requires sophisticated

connectors.
 Data: subscriptions, notifications, published information

Topology:
Subscribers connect to publishers either directly or may receive
notifications via a network protocol from intermediaries
Publish-Subscribe Style (cont.)

Advantages
 Subscribers are independent from
each other
 Very efficient one-way
information dissemination

Disadvantages
 When a number of
subscribers is very high,
special protocols are needed
Example
Peer-to-Peer Style

Summary:
State and behavior are distributed among peers which can
act as either clients or servers.

Design elements:

 Components: Peers (independent components, having

their own state and control thread).

 Connectors: Network protocols, often custom.

 Data : Network messages

Topology:

 Network (may have redundant connections between

peers); can vary arbitrarily and dynamically

Peer-to-Peer Style (cont.)
Every component can act as publisher and/or subscriber,
clients and/or servers

Supports decentralized computing

with flow of control and resources
distributed among peers. Highly
robust in the face of failure of any
given node. Scalable in terms of
access to resources and computing
power. But caution on the protocol!

Example
Peer-to-Peer Style (cont.)

Advantages
 Robustness (if a node is not available the
functionality is taken over)
 Scalability
 Decentralization

Disadvantages
 Security (peers might be malicious)
 Latency (when information retrieval time is
crucial)
Mobile-Code Style
Sometimes interpretation/computation cannot be
performed locally, variants:

code-on-demand
 Client has resources & processing power; server has code
to be executed. Client requests the code from server and
runs it locally
 An example - a web server sending the html & javascript
code to a home computer, which have access to resources
like cookies and the users screen.

remote evaluation -
 Client has code but don’t have resources to execute

mobile agent
 Initiator has code and some resources
 Can autonomously decide to migrate to a different node to
obtain additional resources
Mobile-Code Style

Summary:
Enable code to be transmitted to a remote host for computation.
Reason: lack of local computing power, lack of resources, or data
sets remotely located.

Design elements:
 Components: “Execution dock” (which handles receipt and
deployment of code and state), code compiler/interpreter
 Connectors: Network protocols and elements for packaging
code and data for transmission.
 Data : representations of code as data; program state; data

Topology:
network
Mobile-Code Style (cont.)

Advantages
 Dynamic adaptability
 Performance (resources)

Disadvantages
 Security  Code being executed might be
malicious
 Network/transmission costs

41
Mobile-Code Style (cont.)
 Heterogeneous Styles
The architecture of a software system is almost never limited to a
single architectural style but is often a combination of architectural
styles that form the complete system.

Example
 Main program and Object-oriented
subroutines

Virtual
Traditional machines
Language-
Influenced Styles
Peer-to-
Peer Layered Client-
server
Event-based
Architectural
Styles Batch-
Implicit sequential
Invocation
Dataflow
Styles

Publish-subscribe Interpreter
Shared Pipe-and-filter
Memory

Mobile
Basic Rule- Blackboard
Code
Interpreter based 44
Reference:

45
MVC architecture pattern

Widely used for the UI of an application, well
suited to web applications and other types of
application executes application logic to
select the appropriate view and
sends it the information that it
needs to render the UI

manages data – processing of data

to & from a data store (database)

displays data to the user in an

appropriate interface based on
information received from the
controller

46
MVC in action – Spring MVC

DispatcherServlet – acts as a front controller

Controller class- Java class that contains
handler methods (handles incoming HTTP
requests)

Handler Mapping

View Resolver

View Engine

47
 Spring MVC

Web Browser sends request to Dispatcher Servlet  ask Handler Mapping to identify which Controller to process
the request. Handler Mapping inform and Dispatcher Servlet sent request to corresponding Controller. Controller
process the request and create a model & view (e.g., employeelist) and sent to Dispatcher Servlet. Dispatcher
Servlet gives view name to View Resolver to get actual view location. View resolver identify location and sends
the extension to Dispatcher Servlet. Dispatcher Servlet sends the model & view to View Engine. The View Engine
merge the model and view template and produce HTML and sent back to Dispatcher Servlet to be sent back to
Web Browser
Source: https://www.youtube.com/watch?v=Cu3mHxv8-To
48
Example: N-Tier Client Server Style

Separation of concerns:
Presentation, business and data
handling logic are clearly Client Web Web Web
partitioned in different tiers. Tier Client Client Client

Synchronous
communications: Web Server
Communications between tiers Web Server
Tier
is synchronous request-reply.
Each tier waits for a response
from the other tier before Business
Application Server
Logic Tier
proceeding.

Flexible deployment: There
are no restrictions on how a Data
Management Databases
multi-tier application is deployed. Tier
All tiers could run on the same
machine, or each tier may be
deployed on its own machine.

49
Example

50
N-Tier Client Server – Quality Attribute Analysis
Quality Issues
Attribute
Availability Servers in each tier can be replicated, so that if one fails, others remain available.
Overall the application will provide a lower quality of service until the failed
server is restored.
Failure handling If a client is communicating with a server that fails, most web and application
servers implement transparent failover. This means a client request is, without its
knowledge, redirected to a live replica server that can satisfy the request.
Modifiability Separation of concerns enhances modifiability, as the presentation, business and
data management logic are all clearly encapsulated. Each can have its internal
logic modified in many cases without changes rippling into other tiers.
Performance This architecture has proven high performance. Key issues to consider are the
amount of concurrent threads supported in each server, the speed of connections
between tiers and the amount of data that is transferred. As always with
distributed systems, it makes sense to minimize the calls needed between tiers to
fulfill each request.
Scalability As servers in each tier can be replicated, and multiple server instances run on the
same or different servers, the architecture scales out and up well. In practice, the
data management tier often becomes a bottleneck on the capacity of a system.
51
Architecting Modern Applications

Cyber-Physical Systems (CPS)

Cloud-based Applications

Mobile Applications – e.g., Fitness app, Grab, Food
Panda, FlexiParking,..etc.

Social Media – e.g., IG, FB, Twitter..

Internet-of-Things (IoT) – e.g., smart home, smart office,
etc.

Big Data application – e.g., fraud detection, market
analysis

…..

Microservice Architecture

Serverless Architecture

…
52