architectural styles - tu graz

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


• 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


• 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


• 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


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


Figure 9: 2-tier architecture

47


• 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


Figure 10: 3-tier architecture49


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


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


• 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


• 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


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


Figure 14: Notification architecture - combined registry and active component

61


Figure 15: Notification architecture - separate registration and active component

62


• 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


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


• 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


• 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.


• 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


• 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


• 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


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


• 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


• 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


• 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

architectural styles - tu graz

Documents