Architectural Styles ISo�ware Architecture VO (706.706)
Roman Kern
Institute for Interactive Systems and Data Science, TU Graz
2019-12-11
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 1 / 73
Outline
1 Introduction to Architectural Styles
2 Data-flow Architectures
3 Data-centered Architectures
4 Layered Architectures
5 Notification Architectures
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 2 / 73
Introduction to Architectural StylesMake use of prior experiences
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 3 / 73
Experience in building so�ware systems
Over the years a lot of experience has been gained
Certain pa�erns and structures appear very o�en
Therefore architectural pa�erns are discovered, not invented
Such pa�erns and structures become a part of the vocabulary
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 4 / 73
Experience in building so�ware systems
Vocabulary is used by designers to think and talk about the architectural design
An architectural style is a particular pa�ern that focuses on the large-scale structure of asystem typically described by the common vocabulary
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 5 / 73
Architectural style definition
Architectural style defines the structural pa�ern, which consists of
the components that are usedthe connections that can be used
set of constraints how they can be used
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 6 / 73
Architectural style
An architectural style is constrained by a particular principle of how to build systemsHow components are organized, how data is manipulated, how components communicate
I E.g., a hierarchy of components, sequential processing of data, asynchronous communication,…
Each principle influences some quality a�ributes in a positive and some other in a negativeway
It is again balancing between advantages and disadvantages
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 7 / 73
Architectural style
Definition[An architectural style] defines a family of systems in terms of a pa�ern of structuralorganisation. More specifically, an architectural style defines a vocabulary of components andconnector types, and a set of constraints on how they can be combined.– Shaw, 1996
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 8 / 73
Architectural style
Architectural styles are also named architectural pa�ern
Definition of Pa�ern[A pa�ern is] a common solution to a common problem in a given context.– UML User Guide
Pa�erns are thereby expected to be good solutions, but there are also common bad solutions
Definition of Antipa�ern[A antipa�ern is] a commonly occurring pa�ern or solution that generates decidedly negativeconsequences. An antipa�ern may be a pa�ern in the wrong context.– Brown, 1998
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 9 / 73
Classification of styles
1 Data-flow architectures2 Data-centered architectures3 Abstraction layer architectures4 N-tier architectures5 Notification architectures6 Remote invocation and service architectures7 Heterogeneous architectures
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 10 / 73
Data-flow ArchitecturesArchitecture style dealing with a stream of data.
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 11 / 73
Data-flow architectures
These architectures have the goal of achieving the quality of reuse and modifiability.The data-flow style is characterized by viewing the system as a series of transformationson successive pieces of input data.
Data enter the system and then flows through the components one at a time
Finally, the data is assigned to some final destination (output or a data store).
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 12 / 73
Data-flow architectures
Data-flow architectures can be classified intoI Batch-sequential architecturesI Pipes and filters
In the batch sequential style each step runs to completion before the next step startsI E.g., UNIX command line pipes
In pipe and filters style steps might run concurrently processing parts of data incrementally
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 13 / 73
Pipes and filters
Data flows through pipes: communication channels between filters
Processing units: filtersDepending on where the filters reside di�erent types of execution architectures mightapply
I E.g. same process: filters run within threadsI E.g. same machine: filters run within own processesI E.g. network: pipes use the networking architecture
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 14 / 73
Pipes and filters
Conceptually filters consume data from input and write data to output
Input and output: communication channels, i.e., pipes
Filters do not know anything about other filters (loose coupling between the components)
Ideally they are completely independent from each other
Data flows in streams: good for processing of images, audio, video, …
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 15 / 73
Pipes and filters
Figure: Pipe and filters style
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 16 / 73
Pipes and filters
Variations: structural and communicationalStructural: more complex topologies might be used
I E.g., loops, branches, more than one input, …
Term pipeline used for linear sequence of filters
Communicational: are filters blocked and wait for data?
Term bounded pipe for limited amount of data in the pipe
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 17 / 73
Pipes and filters
What is the data-structure within the pipe?
All components in the pipe have to agree
Term typed pipe if data is structured
The more specific the data-structures are, the tighter the coupling
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 18 / 73
Pipes and filters
How is the data consumed?I Streaming, orI All data at once (batch sequential), orI Chunks of data
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 19 / 73
Pipes and filters
Figure: Pipe and filters style
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 20 / 73
Pipes and filters - advantages
Pipes are conceptually simple (helps maintainability)
Components can be reused
Easy to add and remove components (helps evolvability)Allow injection of special components to address cross-cu�ing concerns
I E.g., monitor throughput, logging, …
Allow concurrent/parallel execution (helps scalability)
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 21 / 73
Pipes and filters - disadvantages
Pipes o�en lead to batch processingTherefore not well suited for interactive applications
I E.g., hard to implement incremental updates
Lowest common denominator for data structure
Each filter has to parse/unparse the data (bad for performance)
Adds complexity to each component
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 22 / 73
Data-centered ArchitecturesArchitectures focused on data integrity.
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 23 / 73
Data-centered architectures
These architectures have the goal of achieving the quality of integrability of data.The term refers to systems in which the access and update of a widely accessed data storeis their primary goal.
Basically, it is nothing more than a centralized data store that communicates with anumber of clientsImportant for this styles are three protocols:
I Communication, data definition and data manipulation protocol
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 24 / 73
Data-centered architectures
The means of communication distinguishes the two subtypes: repository and blackboardRepository: a client sends a request to the system to perform a necessary action (e.g. insertdata)
Blackboard: the system sends notification and data to subscribers when data of interestchanges, and is thus active
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 25 / 73
Repository
Figure: Repository style
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 26 / 73
Blackboard
Figure: Blackboard style
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 27 / 73
Database architecture
One of the most well-known examples of the data-centered architecture, is a databasearchitectureThere is a common database schema (i.e., meta-structure of the repository) - created withdata definition protocol
I E.g., in RDBMS a set of related tables with fields, data types, keys, …
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 28 / 73
Database architecture
Clients use data manipulation protocol to work with the dataI E.g., SQL for inserting, selecting, deleting data, …
Depending on where clients are located communication protocol might beI An inner-process communicationI Communication between components on the same machineI Communication over network, e.g. LAN, Internet, etc.
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 29 / 73
Database architecture
Pipes with shared data are similar to data-centered architecturesBlackboard architecture traditionally used for complex systems
I E.g., Speech and pa�ern recognition
Allows loosely coupled components
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 30 / 73
Data-centered architectures: advantages
Ensures data integrity
Reliable, secure, testability guaranteed
Clients independent from the system: performance and usability on the client side istypically good
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 31 / 73
Data-centered architectures: disadvantages
Problems with scalability, reliability (single point of failure)
Solutions: shared repositories, replication but this increases complexity
Unclear border which functionality lies in the DB and which in the client
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 32 / 73
Web architecture
Another example of data-centered architectures is the Web architecture
There is a common data schema (i.e., meta-structure of the Web)
Follows hypermedia data model
Pages (nodes) and links between them, as well as addressing mechanism
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 33 / 73
Web architecture
Data manipulation not directly in the system but typically achieved through applications
Although HTTP protocol has methods for data manipulation
Communication protocol is HTTP
Analysis: integrity not guaranteed (404 error) but extremely scalable
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 34 / 73
Resource-Oriented Architecture
Such architectures look onto the Web as a huge distributed database
Data model: nodes addressable by URL and interlinked
Data manipulation: HTTP methods (GET, PUT, POST, DELETE)
Scalable, good performance, usability, etc.
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 35 / 73
Layered ArchitecturesArchitectures with clear layers of responsibilities.
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 36 / 73
Abstract layer architectures
Layering: the structure of the system is organized into set of layersEach layer is on the top of another layerWell-defined interfaces between layers
Reduces complexity, improves modularity, reusability, maintainability
Di�erent criteria for layering: most notably abstraction
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 37 / 73
Abstract layer architectures
Topological constraintsNumber of layers?
Limit access to next lower layer?
Access to layer above?
Sometimes abstraction is not completely opaque
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 38 / 73
Example
Figure: Layered architecture, with each layer just communicating with its direct neighbours
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 39 / 73
Operating systems
Typically organized into layers
Successive layers provide more sophisticated services to the layers above them
Hardware services, kernel services, system services, UI services
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 40 / 73
Operating systems
Figure: Operating system - an example of a layered architecture
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 41 / 73
Virtual machines
A virtual machine implements an instruction set for an imaginary machine
O�en virtual machines are the underlying mechanism by which a programming languageis executed
Specifies an interface between compiler and a real machine
From conceptual point of view very similar to OS
Improves portability
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 42 / 73
Virtual machines
Figure: Virtual machine - similar to a complete operating system
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 43 / 73
Interpreter
Similar to a virtual machine, but only limited to execute codeI E.g., shell script
State might be shared between the system components and the scriptAllows more flexibility
I At the cost of performance and testability
Might help in terms of configurability
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 44 / 73
Peer-to-peer protocol stacks
A common example of layered architecture is a network protocol stackI E.g., TCP/IP protocol stack
Four layers
The lowest layer handles communication between two computers
The internet layer handles routing of packets accross the network
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 45 / 73
Peer-to-peer protocol stacks
The transport layer guarantees that packets are error-free and that they are received in thesame order as they are sentThe application layer supports application-specific protocols
I E.g., HTTP, SMTP, FTP, …
The layers constitute a series of increasingly abstract operations
Higher layers span a virtual connection between computers on the network
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 46 / 73
Peer-to-peer protocol stacks
Figure: TCP/IP protocol stack
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 47 / 73
Layered architecture - advantages
Each layer is only coupled to the adjacent layers
Helps evolvability, as one can exchange a single layer and limit modifications to neighbourlayers
Helps reusability, as layers can by used by multiple systems
Especially, if the communication is standardised
In practice each layer is o�en maintained by dedicated development teams
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 48 / 73
Layered architecture - disadvantages
Not all systems lend themselves to be organised in layersAbstraction might have negative e�ect of performance
I E.g., specific optimisations not possible
Hard to find right level of abstraction
In practice lot of e�ort to implement features which a�ect multiple layers
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 49 / 73
N-tier architectures
The N-tier architecture is the modern client-server architecture
Originated with business applications
Through the popularity of the Web today typically related with Web applications
Conceptually separate architecture into presentation, application and data storagelayers
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 50 / 73
2-tier architectures
Clients are typically rich (ui+applogic+communication)
Servers store data
Each client runs a complete application
Drawbacks: each client has to know how to communicate with all data servers
Scalability is compromised because client are tightly coupled with servers
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 51 / 73
2-tier architectures
Figure: 2-tier architecture
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 52 / 73
3-tier architectures
Evolved from 2-tier architectures to solve their drawbacks
A third tier is inserted between clients and data servers
Application or business logic tier: middle tier
Typically middle tier is on the server side (but recently might be split between the serverand the client)
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 53 / 73
3-tier architectures
Figure: 3-tier architectureRoman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 54 / 73
3-tier architectures
AdvantagesEasier client maintenance because the middle tier can be updated in isolation
Be�er isolation of specifics of the data storage: extensibility, configurability
Be�er network utilization
Possibility of adding additional processing layers in the middle layer
Cleanly separates presentation, application logic and data storage
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 55 / 73
3-tier architectures
Figure: Presentation, application, data - typical for a 3-tier web application system
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 56 / 73
Rich clients
A rich client contains full knowledge of the application
It has access to the full suite of UI mechanisms on the platform
Two types of rich clients
Clients for standard applications using a standard protocol (e.g. e-mail clients)
Clients for custom applications using a custom protocol
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 57 / 73
Rich clients
Figure: Rich client architecture
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 58 / 73
Thin clients
Thin clients have li�le knowledge of the application
The complete application knowledge is on the server
Most notably: Web clients
Even if we use AJAX: it is served by the server, i.e. the application knowledge is on the server
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 59 / 73
Thin clients - Example
Another form: a graphical thin client
Only displays a graphical user interface
In this architecture we have a so-called display server
It resides on the server side but acts as a user-interface screen
It transmits changes in the user-screen to the client
X-server and X-windows on UNIX systems
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 60 / 73
Thin clients
Figure: Thin client architecture
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 61 / 73
Notification ArchitecturesArchitectures for loosely coupled components.
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 62 / 73
Notification architectures
Architectures where information and activity is propagated by a notification mechanism
When there are complex communication pa�erns that are not known at design time
Basically, components interested in events register their interest
When an event occurs the interested components are notified
Well-known example: event handling in GUIs
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 63 / 73
Notification architectures
Also called: publish-and-subscribe
Other terminology: listeners and callbacks
Similar to the observer pa�ern from the field of design pa�ern
Similar to blackboard data-centric architectures
Notification architectures are more general because any kind of events might occur notonly data-related events
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 64 / 73
Notification architectures
At execution level two variantsI Components interested in events register directly with the process that generates these eventsI Components register with a dedicated notification component
The communication style in both variants is callback
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 65 / 73
Notification architectures
Additional variantsWhen an event occurs the notifying component may send the event to all registeredcomponents (broadcast)
Another possibility is to send the event only to interested componentsVariations in communication style
I Notification might include all the relevant data, i.e., push styleI Notification just signals that something happened: the registered component pulls the
relevant data
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 66 / 73
Notification architectures
Figure: Notification architecture - combined registry and active component
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 67 / 73
Notification architectures
Figure: Notification architecture - separate registration and active component
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 68 / 73
Notification architectures
Similar to notification architecture: message queuesI A generator puts an event into the queueI Consumers process the events from the queue
Used to control process flowI And decouple the generators from the consumers
Two types: publish/subscribe and point-to-pointPublish/subscribe scheme is also known as topics-based message queues
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 69 / 73
Notification architectures
Examples of notification style architecturesTriggers in databases
Consistency checks
Spell checking in editorsEvent driven UI
I Separation of presentation from persistence of data
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 70 / 73
Notification architectures - advantages
Loose couplingFlexibility
Notification receivers can easily be changed and added
Helps evolvability
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 71 / 73
Notification architectures - disadvantages
No control over process flow
Due to asynchronous nature, might not be deterministic (bad for testability)Unclear which data should be passed with the notification
I If too li�le data is passed, the receiver might need to fetch it (increases coupling)
Performance issues due to update stormI Even worse, there might be endless loops
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 72 / 73
The EndNext: Architectural Styles II
Roman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 73 / 73
Top Related