Architectural Styles I - KTIkti.tugraz.at/staff/rkern/courses/sa/slides_as.pdf · Outline 1...

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


Introduction to Architectural StylesMake use of prior experiences


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


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


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


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


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


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


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


Data-flow ArchitecturesArchitecture style dealing with a stream of data.


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


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


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


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, …


Pipes and filters

Figure: Pipe and filters style


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


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


Pipes and filters

How is the data consumed?I Streaming, orI All data at once (batch sequential), orI Chunks of data


Pipes and filters

Figure: Pipe and filters style


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)


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


Data-centered ArchitecturesArchitectures focused on data integrity.


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


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


Repository

Figure: Repository style


Blackboard

Figure: Blackboard style


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, …



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.



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


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


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


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


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


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.


Layered ArchitecturesArchitectures with clear layers of responsibilities.


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


Abstract layer architectures

Topological constraintsNumber of layers?

Limit access to next lower layer?

Access to layer above?

Sometimes abstraction is not completely opaque


Example

Figure: Layered architecture, with each layer just communicating with its direct neighbours


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


Operating systems

Figure: Operating system - an example of a layered architecture


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


Virtual machines

Figure: Virtual machine - similar to a complete operating system


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


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



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



Figure: TCP/IP protocol stack


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


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


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


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



Figure: 2-tier architecture



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)



Figure: 3-tier architectureRoman Kern (ISDS, TU Graz) Architectural Styles I 2019-12-11 54 / 73


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



Figure: Presentation, application, data - typical for a 3-tier web application system


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


Rich clients

Figure: Rich client architecture


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


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


Thin clients

Figure: Thin client architecture


Notification ArchitecturesArchitectures for loosely coupled components.


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



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



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



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



Figure: Notification architecture - combined registry and active component



Figure: Notification architecture - separate registration and active component



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



Examples of notification style architecturesTriggers in databases

Consistency checks

Spell checking in editorsEvent driven UI

I Separation of presentation from persistence of data


Notification architectures - advantages

Loose couplingFlexibility

Notification receivers can easily be changed and added

Helps evolvability


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


The EndNext: Architectural Styles II


Architectural Styles I - KTIkti.tugraz.at/staff/rkern/courses/sa/slides_as.pdf · Outline 1...

Documents

Transcript of Architectural Styles I - KTIkti.tugraz.at/staff/rkern/courses/sa/slides_as.pdf · Outline 1...