Architectural Styles
So�ware Architecture VO (706.706)
Roman Kern
Version 2.3.2
Institute for Interactive Systems and Data Science, TU Graz
1
Introduction to Architectural Styles
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
• � Architectural pa�erns are discovered, not invented
• Such pa�erns and structures become a part of the vocabulary
2
# As a so�ware architect you will experience that the designed (successful)architectures have a certain degree of similarity.
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
• Focuses on the large-scale structure of a system• Typically described by the common vocabulary
3
Architectural style definition
• Architectural style defines the structural pa�ern, which consists of• the components that are used• the connections that can be used• set of constraints how they can be used
4
Architectural style
• An architectural style is constrained by a particular principle of how to buildsystems
• How components are organized, how data is manipulated, how componentscommunicate
• e.g., a hierarchy of components, sequential processing of data, asynchronouscommunication, …
• Each principle influences some quality a�ributes in a positive and some other in anegative way
• It is again balancing between advantages and disadvantages ¤
5
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 ofcomponents and connector types, and a set of constraints on how they can becombined.– Shaw, 1996
6
# Shaw, 1996, So�ware Architecture: Perspective on an Emerging Discipline
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 badsolutions
Definition of Antipa�ern[A antipa�ern is] a commonly occurring pa�ern or solution that generates decidedlynegative consequences. An antipa�ern may be a pa�ern in the wrong context.– Brown, 1998
7
# Brown, 1998, AntiPa�erns: Refactoring So�ware, Architecture and Projects in Cri-sis
Classification of styles
1. Data-flow architectures
2. Data-centered architectures
3. Layered architectures
4. Notification architectures
5. Network-centred architectures
6. Remote invocation architectures
7. GUI architectures
8. Heterogeneous architectures
8
Data-flow Architectures
Data-flow architectures
• These architectures have the goal of achieving• � Reuse and modifiability
• The data-flow style is characterized by viewing the system as a series oftransformations on successive pieces of input data
• Data enters 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)
9
Data-flow architectures
• Data-flow architectures can be classified into• Batch-sequential architectures• Pipes and filters
• In the batch sequential style each step runs to completion before the next stepstarts
• e.g., UNIX command line pipes
• In pipe and filters style steps might run concurrently processing parts of dataincrementally
10
Pipes and filters
• Data flows through pipes: communication channels between filters
• Processing units: filters• Depending on where the filters reside di�erent types of execution architecturesmight apply
• e.g., same process: filters run within threads• e.g., same machine: filters run within own processes• e.g., network: pipes use the networking architecture
11
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, …
12
Pipes and filters
Figure 1: Pipe and filters style
13
Pipes and filters
• Variations: structural and communicational• Structural: more complex topologies might be used
• 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
14
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
15
Pipes and filters
• How is the data consumed?• Streaming, or• All data at once (batch sequential), or• Chunks of data
16
Pipes and filters
Figure 2: Pipe and filters style
17
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• e.g., monitor throughput, logging, …
• Allow concurrent/parallel execution• � Helps scalability
18
Pipes and filters - disadvantages
• Pipes o�en lead to batch processing• Therefore not well suited for interactive applications
• e.g., hard to implement incremental updates• � Bad for usability
• Lowest common denominator for data structure• Each filter has to parse/unparse the data
• � Bad for performance
• Adds complexity to each component
19
# Performance: good for throughput, bad for latency!
Data-Centred Architectures
Data-centred 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 accesseddata store is their primary goal
• Typically realised as a centralised data store that communicates with a number ofclients
• Important for this styles are three protocols• (i) Communication, (ii) data definition and (iii) data manipulation protocol
20
Data-centred architectures
• The means of communication distinguishes the two subtypes: repository andblackboard
• Repository• Clients send requests to the system to perform a necessary action (e.g., insert data)
• Blackboard• The system sends notification and data to subscribers when data of interest changes,and is thus active
21
Repository
Figure 3: Repository style
22
Blackboard
Figure 4: Blackboard style
23
Database architecture
• One of the most well-known examples of the data-centred architecture• Database architecture
• There is a common database schema• Meta-structure of the repository• Created with data definition protocol• e.g., in RDBMS a set of related tables with fields, data types, keys, …
24
Database architecture
• Clients use data manipulation protocol to work with the data• e.g., SQL for inserting, selecting, deleting data, …
• Depending on where clients are located communication protocol might be• An inner-process communication• Communication between components on the same machine• Communication over network, e.g., LAN, Internet, etc.
25
Database architecture
• Pipes with shared data are similar to data-centred architectures
• Blackboard architecture traditionally used for complex systems• e.g., Speech and pa�ern recognition
• � Allows loosely coupled components
26
Data-centred architectures: advantages
• Ensures data integrity• � Consistent data
• Typically core components are mature• � Reliable, secure, testability guaranteed
• Clients independent from the system• � Performance and usability on the client side is typically good
27
# Core components are typically of-the-shelf database systems (of high ma-turity and quality).
Data-centered architectures: disadvantages
• O�en single point of failure• � Problems with scalability, reliability• Solutions: shared repositories and replication
• � Increases complexity
• Unclear border which functionality lies in the DB and which in the client• � Bad for maintainability
28
Web architecture
• Another example of data-centred architectures• 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
29
Web architecture
• Data manipulation not directly in the system but typically achieved throughapplications
• Although HTTP protocol has methods for data manipulation
• Communication protocol is HTTP
• Analysis• � Integrity not guaranteed (404 error)• � Extremely scalable
30
Resource-oriented architectures
• 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
31
# Limited by the semantics of the protocol, thus in practice not implementedin its purest form.
Layered Architectures
Abstract layer architectures
• Layering: the structure of the system is organized into set of layers
• Each layer is on the top of another layer
• Well-defined interfaces between layers
• � Reduces complexity, improves modularity, reusability, maintainability
• Di�erent criteria for layering: most notably abstraction
32
Abstract layer architectures
Topological constraints
• Number of layers?
• Limit access to next lower layer?
• Access to layer above?
• Sometimes abstraction is not completely opaque
33
Example
Figure 5: Layered architecture, with each layer just communicating with its direct neighbours
34
Operating systems
• Operating systems are typically organized into layers
• Successive layers provide more sophisticated services to the layers above them
• e.g., hardware services, kernel services, system services, UI services
35
Operating systems
Figure 6: Operating system - an example of a layered architecture
36
Virtual machines
• A virtual machine implements an instruction set for an imaginary machine
• O�en virtual machines are the underlying mechanism by which a programminglanguage is executed
• Specifies an interface between compiler and a real machine
• From conceptual point of view very similar to OS
• � Improves portability
37
Virtual machines
Figure 7: Virtual machine - similar to a complete operating system
38
Interpreter
• Similar to a virtual machine, but only limited to execute code• e.g., shell script
• State might be shared between the system components and the script
• � Allows more flexibility• Might help in terms of configurability• � At the cost of performance and testability
39
Peer-to-peer protocol stacks
• A common example of layered architecture is a network protocol stack• e.g., TCP/IP protocol stack• Four layers• The lowest layer handles communication between two computers• The internet layer handles routing of packets across the network
40
Peer-to-peer protocol stacks
• The transport layer guarantees that packets are error-free and that they arereceived in the same order as they are sent
• The application layer supports application-specific protocols• 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
41
Peer-to-peer protocol stacks
Figure 8: TCP/IP protocol stack
42
Layered architecture - advantages
• Each layer is only coupled to the adjacent layers
• � Helps evolvability, as one can exchange a single layer and limit modificationsto neighbour layers
• � 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
43
Layered architecture - disadvantages
• Not all systems lend themselves to be organised in layers
• Abstraction might have negative e�ect on• � Performance
• e.g., specific optimisations not possible
• Hard to find right level of abstraction
• In practice lot of e�ort to implement features across multiple layers
44
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• (i) presentation, (ii) application, and (iii) data storage layers
45
2-tier architectures
• Clients are typically rich (ui+applogic+communication)
• Servers “only” 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
46
2-tier architectures
Figure 9: 2-tier architecture
47
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• Or split between the server and the client
48
3-tier architectures
Figure 10: 3-tier architecture49
3-tier architectures
Advantages
• Easier 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• �Maintainability
50
3-tier architectures
Figure 11: Presentation, application, data - typical for a 3-tier web application system
51
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
52
Rich clients
Figure 12: Rich client architecture
53
Thin clients
• Thin clients have li�le knowledge of the application
• The complete application knowledge is on the server
• Most notably: Web clients
54
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
• e.g., X-server and X-windows on UNIX systems
55
Thin clients
Figure 13: Thin client architecture
56
Notification Architectures
Notification architectures
• Architectures where information and activity is propagated by a notificationmechanism
• When there are complex communication pa�erns that are not known at designtime
• Basically, components interested in events register their interest
• When an event occurs the interested components are notified
• Well-known example: event handling in GUIs
57
Notification architectures
• Also called: publish-and-subscribe• Similar to listeners and callbacks• Similar to the observer pa�ern from the field of design pa�ern• Similar to blackboard data-centric architectures
• Notification architectures aremore general• Any kind of events might occur (not only data-related events)
58
Notification architectures
• At execution level two variants• Components interested in events register directly with the process that generatesthese events
• Components register with a dedicated notification component
• The communication style in both variants is callback
59
Notification architectures
Additional variants
• Broadcast (multicast)• When an event occurs the notifying component may send the event to all registeredcomponents
• Another possibility is to send the event only to interested components
• Variations in communication style• Notification might include all the relevant data, i.e., push style• Notification just signals that something happened: the registered component pullsthe relevant data
60
Notification architectures
Figure 14: Notification architecture - combined registry and active component
61
Notification architectures
Figure 15: Notification architecture - separate registration and active component
62
Notification architectures
• Similar to notification architecture: message queues• A generator puts an event into the queue• Consumers process the events from the queue
• Used to control process flow• � Decouple the generators from the consumers
• Two types• Publish/subscribe
• Also known as topics-based message queues
• Point-to-point
63
Notification architectures
Examples of notification style architectures
• Triggers in databases
• Consistency checks
• Spell checking in editors
• Event driven UI• � Separation of presentation from persistence of data
64
Notification architectures - advantages
• Loose coupling of components• � Helps flexibility
• Notification receivers can easily be changed and added• � Helps evolvability
65
Notification architectures - disadvantages
• No control over process flowF
• Due to asynchronous nature, might not be deterministic• � Bad for testability
• Unclear which data should be passed with the notification• If too much data is passed
• � Bad for performance
• If too li�le data is passed, the receiver might need to fetch it
• � Increases coupling
• Performance issues due to update storm• Even worse, there might be endless loops �
66
Network-Centred Style
Client-Server
• Basic concept• The client uses a service• The server provides a service
• The service can be any resource• e.g., data, file, CPU, display device
• Typically connected via a network
• � Clients are independent from each other
67
Client-Server
68
Client-Server
• The server provides an abstract service
• The implementation of the server decides how to fulfil the request
• Abstraction of programming language, operating system
• � loose coupling between client and server
• The location of the server is transparent
• Sometimes the client also might become the server (and vice versa)
• � increases the coupling
69
Client-Server
Separation of concerns (SoC)
• Functionality is clearly split into separate components• Also a motivation for the layered architecture style, where each layer is responsible forits own abstraction
• If the communication between client and server is well designed• � Supports independent evolvability
70
# Aspect oriented programming tries to separate cross-cu�ing concerns intoseparate modules.
Client-Server
• Client-server pa�ern is used by other architectural styles
• It can be used to realise a shared repository• e.g., for the data-centric repository pa�ern• e.g., for filters which operate on a single shared data structure
71
Client-Server - Shared Repository
72
Client-Server
• Two basic types of topology of the server• Single, centralised server or• Multiple, distributed servers
• Centralised servers• � Easier to administer (install, deploy updates, maintain, monitor, …)
• Distributed servers• � Scale be�er,• � But could introduce complexity (e.g., require two-phase commits)
73
Client-Server - Centralised
74
Client-Server - Distributed
75
Client-Server - Scalability
Two basic types of scaling
• Vertically, by increasing the computing power of a single machine (scale up)
• Horizontally, by adding more machines (scale out)
76
Scaling strategies are not specific to client-server architectures
Client-Server - Scalability
• Scaling vertically is o�en the only option
• Especially if the system has not been designed from the ground up to allowdistributed processing
• Scaling vertically is made easier in a virtual environment (virtual machines insteadof physical)
• The system could be transferred to a more powerful machine, without the systemknowing
77
Client-Server - Scalability
• Scaling horizontally should provide a high upper limit for scalability
• Needs support from the system, not every system allows being distributed
• �Might lead to a high communication overhead• Due to synchronisation between the nodes
78
# The system need to be design from the beginning to allow for horizontalscaling.
Client-Server - Scalability
• Distributed servers need to be specifically designed to allow scaling horizontally• �Will be typically more e�ort to develop
• Upgrading to a bigger machine might be cheaper
• Which strategy (scale up or scale out) is more suitable, depends on the actualsystem¤
79
Client-Server
Stateful vs. stateless
• If the client-server communication is stateful, the server keeps track of theapplication state
• Typically provides a handle or a session id
• The client then may manipulate the state on the server, for example• Open file (returns file handle)• Append line• Close file
• � Easier for the clients, as they not need to manage the state• Needed if coupled with thin clients
80
Client-Server
• If the client-server communication is stateless• The client is responsible to keep track of the application state
• The server does not need to store or manage session specific data• Typically coupled with rich clients
• � Scalability of stateless servers are generally be�er than stateful
81
Client-Server
Cloud Computing
• The server is no longer in the organisations network, but somewhere in the Internet• Example: cloud services by Salesforce, Amazon, Google, Microso�
• Scalability, security, reliability is expected to be handled by a specialised team
• Loss of control, legal issues (data is exported to another country)
• Needs a working Internet connection
82
Client-Server - Advantages
• Conceptually simple• Clear separation of responsibilities,
• � Eases evolvability, helps testability
• Good scalability (especially, if stateless)• � Excellent scalability (if server can be scaled out)
• Data can be held at the server with restricted access• � Good for security
83
Client-Server - Disadvantages
• If the communication between client and server is slow, or has a high latency• � Risk of bad usability/performance
• Need to develop/agree on a protocol between client and server
• For stateful, centralised servers scalability is limited and single point of failure
• Integrability into existing systems might not be possible (e.g. if thecommunication is not possible, or not allowed)
84
Peer to peer
• Separation between client and server is removed
• Each client is a server at the same time, called peer• The goal is to distribute the processing or data among many peers
• � No central administration or coordination
85
# No central control (harder to be a�acked).# No bo�leneck, good for scalability.
Peer to peer
86
Peer to peer
• Each peer provides services and consumes services
• Communication might occurs between all peers
• Number of peers is dynamic
• Each peer has to know how to access other peers• Discover, search, join
87
Peer to peer
• Once a peer is initialised, it needs to be come part of the network
• A bootstrapping mechanism is needed• For example via a broadcast message• For example a public list of network addresses
88
Peer to peer - centralised P2P
Centralised peer to peer
• Some aspects are centralised
• For example, a central component keeps track of the available peers
89
Peer to peer - hybrid P2P
Hybrid peer to peer
• Not all peers are equal, some have additional responsibilities• They are called supernodes
• Example• Skype uses a peer-to-peer protocol, but also uses supernodes and a central loginservers
90
Peer to peer - Advantages
• Computation can be distributed• � Excellent scalability
• Data can be replicated over multiple peers• � Good for reliability
• No single point of failure• � Good for reliability
91
Peer to peer - Disadvantages
• �ality of service is not deterministic, cannot be guaranteed• � Bad usability via e.g., high latency
• Very complex• � Hard to maintain and to test
92
Remote Invocation Architectures
Remote invocation and service architectures
• Remote invocation architectures involve distributed processing components
• Typically, a client component• invokes a method (function)• on a remote component
93
Remote invocation and service architectures
• Advantages• � Increased performance through distributed computation• Only if network is reliable and fast and the communication overhead is manageable
• Disadvantages• � O�en, tightly coupling of components (in comparison with a client-serverarchitecture)
• �Managing of addressability (recollect unique identity of objects) increasescommunication overhead
94
Remote invocation and service architectures
• Service architectures introduce a special component where services are registered
• Any component interested in a service asks that component for the address of theservice
• It tries to solve the addressability problem
• If communication protocols are standardized• Services can be integrated on-the-fly
95
Remote invocation and service architectures
Web services
• Use Web protocols for communication
• However, the addressability is still not managed• Have to know how to address objects in a remote service
• Web services can be seen as remote procedure calls using Web protocols
• � Same advantages and disadvantages apply
96
Broker
• Separate communication from the application functionality• Support for distributed systems• The broker hides the communication from the components of the system• The broker coordinates the communication
• A broker can be used to transparently change a non-distributed system into adistributed one
• For example: The client interacts with a remote object via a broker
97
# Similar to the proxy design pa�ern.
Broker
98
Broker - Tasks of a broker
The task of the broker
• Find the appropriate server/service
• Forward request to the servers, and
• Report the result (or error message/exception) back to the client
• � The communication is abstracted away from the client
99
Broker - Relationship to other pa�erns
• The broker pa�ern has relationships with other pa�erns• e.g., the broker can be implemented as separate layer• e.g., the broker uses a client/server infrastructure
100
Broker - Advantages
• Decoupling of components (the networking aspect)• � Helps flexibility, maintainability and evolvability
• Allows a system to be distributed, even if it has not been designed for this in thefirst place
101
Broker - Disadvantages
• Network communication might introduce new types of errors
• Due to network latencies and limited bandwidth the behaviour might change
102
Interceptor - Overview
• Motivation• Separate functionality into a multiple components
• Allow integration of additional services without changing the core components
• Interface provided by a component, which allows another component to registeritself
• And be invoked at specific events
• Open-closed design principle (open for extension, but closed for modifications)
• Can be used to address cross-cu�ing concerns
• Similar to the notification architecture style
103
Interceptor - Example
• Example: Logging
• System consists of two components: a client and a server
• Each component provides a callback interface when some event occurs
• A logging components registers itself at every component
• The logging components store the log into a shared repository
104
Interceptor - Example
105
Interceptor - Advantages
• Interceptor components can be reused• � Helps reusability
• Excellent flexibility
• Clear separation of concerns, loose coupling• � Helps maintainability, evolvability
106
Interceptor - disadvantages
• Can get quite complex quickly
• Potential cascading callbacks, endless loops• � Bad testability
• Sometimes events are non-deterministic
• Core components need to provide the callback interface
107
GUI Architectures
Model View Controller (MVC)
• Motivation• � Reusability and separation of concerns
• Three roles: model, view & controller• Model: encapsulates the behaviour and data of the application domain• View: renders the model for presentation• Controller: Reacts on user input, modifies the model and dispatches to the view
• Both, controller and view, depend on the model
• Controller and view are part of the UI
• O�en used for web applications (but not exclusively)
108
Model View Controller (MVC)
109
MVC - Model
Model
• Encapsulates the application state
• Response to state queries
• Exposes application functionality
• Notify view of changes (optionally)
110
# Also responsible for the resource state.# Notification only necessary, if the model and view realise an observer pat-tern.
MVC - View
View
• Renders the model
• Requests updates from model
• Prepares the user interface for the controller
• Usually multiple views
111
MVC - Controller
Controller
• Reacts to user input
• Manipulates the model
• Triggers application behaviour
• Selects view for response (optionally)
112
MVC - Relationships
• The model-view-controller pa�ern does not replace a n-tier architecture
• Model is part of the n-tier pa�ern and the MVC pa�ern
• The model communicates with lower abstraction layers (e.g., data access layer)
• The model might use a notification pa�ern to inform the view of changes
113
# The lesser known presentation-abstraction-control pa�ern is similar toMVC.
MVC - Advantages
• Separation of concerns• � Helps reusability
• Multiple user interfaces without changes to the model, e.g., mobile and web
• As interface changes are easier, with less expected side e�ects than changes to theapplication logic
• � Helps configurability
114
MVC - Disadvantages
• Increases the complexity by additional components
• Not all systems are applicable to MVC pa�ern
• If updates to the view are based on notifications• � It might be hard to find errors
• In these cases, it is hard to ensure a good usability (no control when an updatehappens)
115
Heterogeneous Architectures
Heterogeneous architectures
• No real system follows strictly only a single style
• Styles themselves are not that strictly separated but they are blurred
• Architectures might be conceptually heterogeneous• N-tier architectures are layered architectures• N-tier architectures are typically data-centric architectures• Thin clients involve some sort of notification architecture
116
Heterogeneous architectures
• Architectures might be structurally heterogeneous• Overall architecture follows one style• Single components follow other styles
• The Web has a 2-tier architecture: browser and server• The browser itself has a notification architecture to handle user events
117
Heterogeneous architectures
• Architectures might be heterogeneous at execution level• At execution level components follow di�erent styles
• e.g., notification architectures might include remote procedure calls if components aredistributed
• Service architectures require networking architecture which is a layeredarchitecture, etc..
• In real systems architectures are heterogeneous at all levels!
118
Heterogeneous architectures
• Web-based search engine
• Conceptually• data-centric, layered, 3-tier
• Structurally• layered (network), 3-tier, notification
• Execution• distributed, service-oriented, notification with callbacks, …
119
Conclusion
• Architectural styles provide pa�erns (components, connections, & constrains)
• Why one should know these styles?• � They provide a common vocabulary• � They provide blueprints on how a system can be designed• � They provide a well known structure and behaviour
120
The EndThank You For Your A�ention!
121
Top Related