Lecture 3

Architectural Styles
MAIN CONTENT

 Architectural Styles vs Architectural Pattern

 Overall system organization
 Individual program structuring
 Model-Driven Architecture
 Middleware Architecture
Architectural Styles vs Architectural Patterns

 Are they similar or different ?

 These terms are not clear
 The key difference is the scope
 They are not mutually exclusive
 They are complementary
Architectural Styles
 How to organize our code ?
 The highest level of granularity
 Specify layers, high-level modules of the application
and how those modules and layers interact with each
other, the relations between them
 Can be implemented in various ways, with a specific
technical environment, specific policies, frameworks
or practices
 Examples: Component-based, Layered, Event-driven,
Client-server, Service-oriented,…
Architectural Patterns

 Solve the problems related to the Architectural Style

 “What classes will we have and how will they interact,
in order to implement a system with a specific set of
layers ? “
 “How many tiers will our client-server architecture
have ?”
 Have an extensive impact on the code base
 Examples: Three-tier, Microkernel, Model-View-
Controller (MVC),…
Architectural Styles vs Architectural Patterns

 Generally, main difference is the scope

 Architectural Style is the application design
at the highest level of abstraction
 Architectural Pattern is a way to implement an
Architectural Style
Architectural styles

 A set of principles which shapes an application

 Define an abstract framework for a family of
system in terms of the pattern of structural
organization
 Describe a particular way to configure a
collection of components and connectors
Architectural styles
An architectural style is defined by

 Type of basic architectural components

(e.g. classes, filters, databases, layers)

 Type of connectors
(e.g. calls, pipes, inheritance, event broadcast)
Common architectural design

Category Architectural design

Message bus
Communication
Service-Oriented Architecture (SOA)
Client/server
Deployment
3-tier or N-tier

Domain Domain Driven Design

Component Based

Structure Layered

Object-oriented
Architecture styles
Overall system organization:
 Hierarchical
 Client-server
 Cloud-based
 Peer-to-peer
Individual program structuring:
 Control-based
• Call-and-return (Subroutine-based)
• Coroutine-based
 Dataflow:
• Pipes and filters
• Blackboard
• Event-driven
 Object-oriented
Hierarchical

Each layer provides services to the layer above it and

acts as a client of the layer below
Each layer collects services at a particular level of
abstraction
A layer depends only on lower layers
 Has no knowledge of higher layers

Example
 Communication protocols
 Operating systems
Hierarchical

Components
 Group of subtasks which implement an abstraction
at some layer in the hierarchy
Connectors
 Protocols that define how the layers interact
Hierarchical: examples
The operating system
The OSI Networking Model
 OSI: Open Systems Interconnection
 Each level supports communication at a level of
abstraction
 Protocol specifies behavior at each level of
abstraction
 Each layer deals with specific level of communication
and uses services of the next lower level

Layers can be exchanged

 Example: Token Ring for Ethernet on Data Link
Layer
OSI model layers

Application The system you are designing

Data transformation services, such as
Presentation
byte swapping and encryption
Session Initializes a connection, including
authentication
Transport Reliably transmits messages

Network Transmits & routes data within network

Data Link Sends & receives frames without error

Physical Sends and receives bits over a channel

Hierarchical: Evaluation
Strengths:
 Separation into levels of abstraction; helps partition
complex problems
 Low coupling: each layer is (in principle) permitted to
interact only with layer immediately above and under
 Extendibility: changes can be limited to one layer
 Reusability: implementation of a layer can be reused

Weaknesses:
 Performance overhead from going through layers
 Strict discipline often bypassed in practice
Client-server

Components
 Subsystems, designed as independent processes
 Each server provides specific services, e.g. printing,
database access
 Clients use these services
Connectors
 Data streams, typically over a communication
network

Client
Client Network Server
Client
Client-server example: databases
Clients: user applications
 Customized user interface
 Front-end processing of data
 Initiation of server remote procedure calls
 Access to database server across the network

Server: DBMS, provides:

 Centralized data management
 Data integrity and database consistency
 Data security
 Concurrent access
 Centralized processing
Client-server variants

Thick / fat client

 Does as much processing as possible
 Passes only data required for communications and
archival storage to the server
 Advantage: less network bandwidth, fewer server
requirements
Thin client
 Has little or no application logic
 Depends primarily on server for processing
 Advantage: lower IT admin costs, easier to secure,
lower hardware costs.
Client-server: Evaluation
Strengths:
 Makes effective use of networked systems
 May allow for cheaper hardware
 Easy to add new servers or upgrade existing servers
 Availability (redundancy) may be straightforward

Weaknesses:
 Data interchange can be hampered by different data
layouts
 Communication may be expensive
 Data integrity functionality must be implemented for
each server
 Single point of failure
Client-server variant: cloud computing

The server is no longer on a company’s network, but hosted

on the Internet, typically by a providing company

Example: cloud services by Google, Amazon, Microsoft

Advantages:
 Scalability
 Many issues such as security, availability, reliability
are handled centrally
Disadvantages:
 Loss of control
 Dependency on Internet
Peer-to-peer
Similar to client-server style, but each component is both
client and server

Pure peer-to-peer style

 No central server, no central router
Hybrid peer-to-peer style
 Central server keeps information on peers and
responds to requests for that information

Examples
 File sharing applications, e.g., Napster
 Communication and collaboration, e.g., Skype
Peer-to-peer: Evaluation
Strengths:
 Efficiency: all clients provide resources
 Scalability: system capacity grows with number of clients
 Robustness
• Data is replicated over peers
• No single point of failure (in pure peer-to-peer
style)

Weaknesses:
 Architectural complexity
 Resources are distributed and not always available
 More demanding of peers (compared to client-server)
 New technology not fully understood
Call-and-return

Components: Objects
Connectors: Messages (routine invocations)

Key aspects
 Object preserves integrity of representation
(encapsulation)
 Representation is hidden from client objects

Variations
 Objects as concurrent tasks
Call-and-return: Evaluation
Strengths:
 Change implementation without affecting clients
 Can break problems into interacting agents
 Can distribute across multiple machines or networks

Weaknesses:
 Objects must know their interaction partners; when partner
changes, clients must change
 Side effects: if A uses B and C uses B, then C’s effects on B
can be unexpected to A
Subroutines

Similar to hierarchical structuring at the program level

Functional decomposition
Topmost functional abstraction

B C D

E1 I I1 C2 I2
Subroutines: Evaluation

Strengths:
 Clear, well-understood decomposition
 Based on analysis of system’s function
 Supports top-down development

Weaknesses:
 Tends to focus on just one function
 Downplays the role of data
 Strict master-slave relationship; subroutine loses
context each time it terminates
 Adapted to the design of individual functional
pieces, not entire system
Coroutines

A more symmetric relationship than subroutines

Particularly applicable to simulation applications

A simulated form of concurrency

Dataflow systems

Availability of data controls the computation

The structure is determined by the orderly motion of data
from component to component

Variations:
 Control: push versus pull
 Degree of concurrency
 Topology
Dataflow: batch-sequential

Frequent architecture in scientific computing and business

data processing

Components are independent programs

Connectors are media, typically files
Each step runs to completion before next step begins
File

Program Program Program

Component
Batch-sequential

History: mainframes and magnetic tape

Business data processing

 Discrete transactions of predetermined type and
occurring at periodic intervals
 Creation of periodic reports based on periodic data
updates

Examples
 Payroll computations
 Tax reports
Dataflow: pipe-and-filter

Component: filter
 Reads input stream (or streams)
 Locally transforms data
 Produces output stream (s)
Connector: pipe
 stream, e.g., FIFO buffer Pipe

Filter
Filter Filter Filter
Filter
Pipe-and-filter
Data processed incrementally as it arrives
Output can begin before input fully consumed

Filters must be independent: no shared state

Filters don’t know upstream or downstream filters

Examples
 lex/yacc-based compiler (scan, parse, generate…)
 Unix pipes
 Image / signal processing
Pipe-and-filter: Evaluation
Strengths:
 Reuse: any two filters can be connected if they agree on
data format
 Ease of maintenance: filters can be added or replaced
 Potential for parallelism: filters implemented as separate
tasks, consuming and producing data incrementally

Weaknesses:
 Sharing global data expensive or limiting
 Scheme is highly dependent on order of filters
 Can be difficult to design incremental filters
 Not appropriate for interactive applications
 Error handling difficult: what if an intermediate filter
crashes?
 Data type must be greatest common denominator, e.g. ASCII
Dataflow: event-based (publish-subscribe)
A component may:
 Announce events
Routine
 Register a callback
for events of other
Routine
components

Connectors are the

bindings between event Routine
announcements and
routine calls (callbacks) Routine
Event-based style: properties

Publishers of events do not know which components

(subscribers) will be affected by those events
Components cannot make assumptions about ordering of
processing, or what processing will occur as a result of
their events

Examples
 Programming environment tool integration
 User interfaces (Model-View-Controller)
 Syntax-directed editors to support incremental
semantic checking
Event-based style: example

Integrating tools in a shared environment

Editor announces it has finished editing a module

 Compiler registers for such announcements and
automatically re-compiles module
 Editor shows syntax errors reported by compiler

Debugger announces it has reached a breakpoint

 Editor registers for such announcements and
automatically scrolls to relevant source line
Event-based: Evaluation
Strengths:
 Strong support for reuse: plug in new components by
registering it for events
 Maintenance: add and replace components with minimum
effect on other components in the system

Weaknesses:
 Loss of control:
 What components will respond to an event?
 In which order will components be invoked?
 Are invoked components finished?
 Correctness hard to ensure: depends on context and
order of invocation
Data-centered (repository)

Components
 Central data store component represents state
 Independent components operate on data store

Knowledge Direct
Source access

Repository Knowledge
Source

Knowledge
Source Computation
Data-centered: Evaluation
Strengths:
 Efficient way to share large amounts of data
 Data integrity localized to repository module

Weaknesses:
 Subsystems must agree (i.e., compromise) on a
repository data model
 Schema evolution is difficult and expensive
 Distribution can be a problem
Blackboard architecture

Interactions among knowledge sources solely through

repository
Knowledge sources make changes to the shared data that
lead incrementally to solution
Control is driven entirely by the state of the blackboard

Example
 Repository: modern compilers act on shared data:
symbol table, abstract syntax tree
 Blackboard: signal and speech processing
Interpreters

Architecture is based on a virtual machine produced in

software
Special kind of a layered architecture where a layer is
implemented as a true language interpreter
Components
 “Program” being executed and its data
 Interpretation engine and its state
Example: Java Virtual Machine
 Java code translated to platform independent
bytecode
 JVM is platform specific and interprets the
bytecode
Object-oriented

Based on analyzing the types of objects in the system and

deriving the architecture from them

Compendium of techniques meant to enhance extendibility

and reusability: contracts, genericity, inheritance,
polymorphism, dynamic binding…

Thanks to broad notion of what an “object” is (e.g. a

command, an event producer, an interpreter…), allows many
of the previously discussed styles
MODEL-DRIVEN
ARCHITECTURE
Four principles of MDA

• Models must be expressed in a well-defined notation,

so as to enable effective communication and

understanding

• Systems specifications must be organized around a set of

models and associated transformations

• implementing mappings and relations between the models.

• multi-layered and multi-perspective architectural framework.

• Models must be compliant with metamodels

• Increase acceptance, broad adoption and tool competition

for MDE
Definitions according toMDA
• System: The subject of any MDA specification (program, computer system,

federation of systems)

• Problem Space (or Domain): The context or environment of the system

• Solution Space: The spectrum of possible solutions that satisfy the reqs.

• Model: Any representation of the system and/or its environment

• Architecture: The specification of the parts and connectors of the system

and the rules for the interactions of the parts using the connectors

• Platform: Set of subsystems and technologies that provide a coherent

set of functionalities for a specified goal

• Viewpoint: A description of a system that focuses on one or more particular

concerns
• View: A model of a system seen under a specific viewpoint

• Transformation: The conversion of a model into another model

 Modeling Levels
 Computation independent (CIM): describe requirements
and needs at a very abstract level, without any reference
to implementation aspects (e.g., description of user
requirements or business objectives);

 Platform independent (PIM): define the behavior of the

systems in terms of stored data and performed
algorithms, without any technical or technological
details;

 Platform-specific (PSM): define all the

technological aspects in detail.
CIM, PIM andPSM
CIM

Ex: business process

PIM

 Specification of
structure and
behavior of a
system, abstracted
from technological
details

 Using the UML(optional)

 Abstraction of structure and behavior of a system with

the PIM simplifies the following:
o Validation for correctness of the model
o Create implementations on different platforms
o Tool support during implementation
PSM

 Specifies how the functionality described in the

PIM is realized on a certain platform
 Using a UML-Profile for the selected platform, e.g.,
EJB
CIM – PIM – PSM mappings
Modeling languagespecification
• MDA’s core is UML, a standard general-purpose software
modeling language

Two options for specifying your languages:

• (Domain-specific) UML Extensions can be defined through
UML Profiles
• Full-fledged domain-specific languages (DSMLs) can be
defined by MOF
 ADM
ADM (Architecture-Driven Modernization) is addressing
the problem of system reverse engineering
It includes several standards that help on this matter
• The Knowledge Discovery Metamodel (KDM): An
intermediate representation for existing software systems
that defines common metadata required for deep semantic
integration of lifecycle management tools. Based on MOF and
XMI
• The Software Measurement Metamodel (SMM): A meta-
model for representing measurement information related
to software, its operation, and its design.
• The Abstract Syntax Tree Metamodel (ASTM): A
complementary modeling specification with respect to
KDM, ASTM supports a direct mapping of all code-level
software language statements into low-level software
models.
MDA vs ADM – the MDRE process
 MIDDLEWARE
ARCHITECTURE
What is middleware ?

• Software that functions as a

conversion or translation layer

• Middleware is also a

consolidator and integrator

• Enables one application to

interface with another, which

either runs on a different
platform or comes from a
different vendor
Key features of middleware

• Distribute and coordinate processing across many

hardware and application platforms

• Provide a centralized location for ‘business logic’

• Provide a framework for the forwarding and queuing of

transactions
Some typical examples of middleware

• Transaction-processing monitors

• Database middleware

• Application server middleware

• Web middleware
Transaction-processing monitors

• Sitting between the

requesting client
program and the
databases, it ensures
that all databases are
updated properly
Database middleware

• Provides a common interface

between a query and multiple,

distributed databases.
• It enables data to be

consolidated from a variety of

disparate data sources

• EDA (Enterprise data access)

• IMS (a hierarchical database)

Application server middleware

• A Web-based application server

that provides interfaces to a

wide variety of applications
• Used as middleware between

the browser and legacy

systems.
• The browser can be used at

desktops or on laptops when

traveling
Web middleware

 Acts as service between a browser and an application

o Handling security – authentication

o Verification – credit card authorization

 Links a database system to a web server

o Allows users to request data from

the database using forms displayed on a web browser

o Enables the web server to return dynamic web

pages based on the user's requests and profile

Middleware framework

• Tools that support application development and delivery

• Application frameworks that developers incorporate into

their applications (eg: Bootstrap)

• A standard framework can be used to create automatic

GUI creation tools

 THANK YOU
FOR LISTENING !