1

>

Architectural Styles

Dr. Anıl Koyuncu

>Which style?

“The set of principal design decisions about the

system”

Architecture = {Principal Design

Decision}

One of the first decision: which architectural style(s)?

>Architectural Styles
Idiomatic Patterns of System Organization

Set of Recurring Useful Design Decisions

Set of Constraints

3
>Architectural Style
A named collection of architectural
decisions that:
• are applicable in a development context
• constrain architectural design decisions
specific to the system within that context
• elicit beneficial qualities in each system
(more elegant, effective, dependable,
evolvable, scalable, etc.)

4
>Why Styles?
Guide the architecture with a predefined set of constraints with
know benefits and limitations
Consistency: enforcing constraints help to keep the design “clean”
Improved Communication by shared understanding (like patterns,
styles provide a vocabulary to concisely explain an architecture)
Access and reuse expert’s design knowledge
Ensure quality attributes if constraints are followed

5
>Architectural Style Catalog

6
>Monolithic (a.k.a. Blob, Big Ball of Mud)
System organized as a single element
• Lack of structure
• No constraints

Initial State of formless architectures

Final States of completely eroded architectures
Qualities:
• Poor Extensibility, Poor Maintainability, (Maybe)
Good Performance

7
>Layered
Elements of each layer
communicate only with the
ones in the layers above and
below
• Information Hiding: Layers hide
the ones below them
• Incremental Construction: Avoid
circular dependencies

8
>Layered
Benefits
• Reuse of layers
• Each layer embodies a well-
defined abstraction with a
documented interface
• Incremental Development
• A lower layer does not depend on
upper layers
• Exchangeability
• A layer can be replaced by
a semantically-equivalent one

9
>Layered
Liabilities
• Lower efficiency
• Data have to be transferred
through several layers
(communication overhead)
• Difficulty of establishing the
correct granularity of layers
• Which services should go to each
layer?
• Cascades of changing
behavior
• Changes in one layer may require
updates to the others

10
>Layered
Examples:
• Hardware/OS/Apps, Network
Protocol Stacks,
Web/App/Database

11
>Blackboard
Elements share, post, update
data written on the blackboard
in order to collectively solve a
problem.

Asynchronous interactions
between processing units
mediated by the blackboard

12
>Blackboard
Benefits
• Easy way to share data
• Centralized backup and data protection
• Support for changeability and maintainability
• A subsystem does not need to know the other
subsystems
• It is easy to aggregate additional subsystems
• Support for fault tolerance and robustness

13
>Blackboard
Liabilities
• Difficulty of testing
• The solution may follow a non-deterministic
algorithm. Several specialized components
assemble their knowledge to build a partial solution

• All subsystems must understand the same

format of data
• They can have different requirements
• It may be hard to maintain a large dataset

14
>Blackboard
Central repository managing concurrent
access to the state of a computation
Qualities:
• Loose Coupling, Implicit Data Flow,
Opportunistic Control Flow, Reliability
Examples:
• Databases, Tuple Space, Expert System

15
>Pipe and Filter
Filters process data streaming though a
pipeline
Pipes connect pairs of filters, one writing into
it and the other reading from it
Pipes may buffer data and transport it across
the network
Pipelines do not have to be linear

16
>Pipe and Filter
Benefits
• Flexibility by filter exchange
• Filters have a simple interface and a well-defined
responsibility
• Flexibility to recombine and reuse
• Efficiency by parallel processing
• Not only for sequential pipelines
• The workflow style is similar to several business
models

17
>Pipe and Filter
Liabilities
• Filters require a common format of data
• In case of extensive data transformation, performance
becomes a major concern
• Error handling is complex
• Pipeline components do not share any global state
• It is hard to define a general strategy for error handling

18
>Pipe and Filter
Pipes may transport raw bits, structured
data, audio/video.
Filters may be stateless or stateful (but never
share state)
Qualities:
• Composability, Reconfigurability, Reusability
Examples:
• Unix Shell, Compilers, Graphics Rendering

19
>

20
>Component Based
Components have well
defined interfaces that hide
their implementation
Components communicate
via connectors linking their
matched interfaces

21
>Component Based
Components need to be
compatible
Qualities:
• Independent Component
Development, Promote
Reusability, Trusted
Components

22
>Service Oriented
Distributed components have
well defined (standard)
interfaces and communicate
via specific connector linking
their interfaces.

Components may belong to

and are operated by different
organizations

23
>Service Oriented
Multiple providers compete to deliver
”Software as a Service” in “Service-
Oriented Architecture”
Qualities:
• Loose Coupling, Reusability, Availability,
Security/Trust
Examples:
• Web Services APIs, Cloud Computing

24