architectural styles i - ktikti.tugraz.at/staff/rkern/courses/sa/2012/slides_as_i.pdf ·...

Architectural Styles ISoftware Architecture VO/KU (707.023/707.024)

Denis Helic, Roman Kern

KMI, TU Graz

Nov 14, 2012

Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 1 / 80

Recap

Software architecture defines the components and theirrelationships in a (complex) system

Software architecture tries to solve the non-functional requirements

... and focus on the non-runtime quality attributes - X-ability

e.g. maintainability, evolvability, testability, reusability, integrability,configurability, scalability

Some of them can be measured, some only estimated


Recap

Software architecture is also influenced by infrastructure

e.g. organizational issues (team), implementation issues(programming language), contextual issues (open source)

⇒ the job is to find the best compromise


Outline

1 Non-Functional Concepts

2 Introduction to Architectural Syles

3 Data-flow Architectures

4 Data-centered Architectures

5 Layered Architectures

6 Notification Architectures


Non-Functional Concepts

Functionality Shared between Software Components

Requirements not covered by individual components

Instead requirements needed to be addressed by each component

Or constraints imposed on each component

⇒ Cross-cutting concerns



Examples for Cross-Cutting Concerns

Logging

Auditing

Monitoring

Exception/error handling

Security (e.g. authentication, authorisation)

Caching

Localisation

Configuration management



Cross-Cutting Functionality Implications

Why are cross-cutting aspects a problem?

They do need to be consistently used/implemented by all components

Some components might not allow this

If the cross-cutting functionality need to be adapted, all componentsneed to be modified



Cross-Cutting Concerns on the Implementation Level

Cross-cutting concerns also exist on the implementation level

Addressed by aspect oriented programming

Aspects are factored out and moved away from the functionality

E.g. logging is done in a separate module and at runtime injectedinto the method calls



Cross-Cutting Concerns on the SA Level

Keep cross-cutting functionality in separate components (is possible)

E.g. dedicated component for authentication/authorisation

Use components that utilise for example aspect oriented programming

Interceptor architectural pattern



Communication between Software Components

Software components communicate with each other

They need to agree on a protocol, API, ...

Thus components share common information (e.g. protocolspecification, contract, ...)

E.g. The receiver implements the API, the sender uses the API

This relationship is therefore directed



Coupling

Coupling: degree to which software components depend on eachother

The degree is influenced on a couple of aspects (more than in OOlanguages)

E.g. how generic is the protocol?



Degree of Coupling

Loose coupling vs. tight coupling

These are the both extremes

In existing systems this is often a continuum

Components might be tightly in one aspect and loosely coupled inanother



Aspects of Coupling

Level Loose Coupling Tight CouplingPhysical coupling Physic intermediary Direct physical link re-

quiredCommunicationstyle

Asynchronous Synchronous

Type system Data-centric, self-contained messages

OO-Style, complex ob-ject trees

Control of processlogic

Distributed logic compo-nents

Central control

Platform depen-dencies

OS- and programminglanguage independent

Strong OS and program-ming language depen-dencies

Source: Enterprise SOA



Consequences of Tight Coupling

If one software component changes, the other (dependant)components need to be changed as well

API/protocol specific to the needed requirements

Often enforced by cross-cutting concerns

Typically it is easier (less effort) to create tightly coupled components



Consequences of Loose Coupling

Components can be easily exchanged

Components are required to be more generic

E.g. use standard protocols instead of custom ones

Will typically require more effort and better design/planning



Type of Coupling in Regard to Quality Attributes

Coupling has an impact on quality attributes

Loose coupling will typically improve maintainability, evolvability,reusability

Tight coupling will typically improve the achievable performance (andtraceability)

For some attributes it is not clear, e.g. testability

⇒ Therefore slight preference to loose coupling



Examples of Coupling

External System

HTTP

CalcViewerAppControl

AppControl

GUI

Controller

NetAnalyzerData

NetAnalysis NotifServ

Calcs Datasets Users



Examples of Coupling

Tight coupling between Controller and the NetAnalyzer

Due to callback (both need to know each other, there might even bea temporal coupling here)

Loose coupling between NetAnalyzer and External System

The external system does not need to know the NetAnalyzer

The external system uses a standard protocol (e.g. SMTP)

⇒ Easy to exchange the external system


Introduction to Architectural Syles

Experience in building software systems

Over the years a lot of experience has been gained

Certain patterns and structures appear very often

Such patterns and structures become a part of the vocabulary

Vocabulary is used by designers to think and talk about thearchitectural design

An architectural style is a particular pattern that focuses on thelarge-scale structure of a system typically described by the commonvocabulary



Architectural style definition

Architectural style defines the structural pattern, which consists of

the components that are used

the 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 tobuild systems

How components are organized, how data is manipulated, howcomponents communicate, ...?

E.g. a hierarchy of components, sequential processing of data,asynchronous communication, ...

Each principle influences some quality attributes in a positive andsome other in a negative way

It is again balancing between advantages and disadvantages



Classification of styles

1 Data-flow architectures

2 Data-centered architectures

3 Abstraction layer architectures

4 N-tier architectures

5 Notification architectures

6 Remote invocation and service architectures

7 Heterogeneous architectures


Data-flow Architectures

Data-flow architectures

These architectures have the goal of achieving the quality of reuseand modifiability.

The data-flow style is characterized by viewing the system as a seriesof transformations on successive pieces of input data.

Data enter the system and then flows through the components one ata time until

Finally, the data is assigned to some final destination (output or adata store).



Data-flow architectures

Data-flow architectures can be classified into batch-sequentialarchitectures and pipe and filters

In the batch sequential style each step runs to completion before thenext step starts

E.g. UNIX command line pipes

In pipe and filters style steps might run concurrently processing partsof data incrementally



Pipes and filters

Data flows through pipes: communication channels between filters

Processing units: filters

Depending on where the filters reside different execution architectures

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



Pipes and filters

Conceptually filters consume data from input and write data to output

Input and output: communication channels, i.e. pipes

Depending on where the filters reside different execution architectures

Filters do not know anything about other filters

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



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?

Streaming, or

All data at once (batch sequential), or

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-cuttingconcerns

E.g. monitor throughput, logging, ...

Allow concurrent/parallel execution (helps scalability)



Pipes and filters - disadvantages

Pipes often lead to batch processing

Therefore not well suited for interactive applications

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 Architectures

Data-centered architectures

These architectures have the goal of achieving the quality ofintegrability of data.

The term refers to systems in which the access and update of awidely accessed data store is their primary goal.

Basically, it is nothing more than a centralized data store thatcommunicates with a number of clients

Important for this styles are three protocols: communication, datadefinition and data manipulation protocol



Data-centered architectures

The means of communication distinguishes the two subtypes:repository and blackboard

Repository: a client sends a request to the system to perform anecessary action (e.g. insert data)

Blackboard: the system sends notification and data to subscriberswhen data of interest changes, and is thus active



Repository

Figure: Repository style



Blackboard

Figure: Blackboard style



Database architecture

One of the most well-known examples of the data-centeredarchitecture, is a database architecture

There is a common database schema (i.e. meta-structure of therepository) - created with data definition protocol

E.g. in RDBMS a set of related tables with fields, data types, keys, ...




Clients use data manipulation protocol to work with the data

E.g. SQL for inserting, selecting, deleting data, ...

Depending on where clients are situated communication protocolmight be

An inner-process communicationCommunication between components on the same machineCommunication over network, e.g. LAN, Internet, etc.




Pipes with shared data are similar to data-centered architectures

Blackboard architecture traditionally used for complex systems

E.g. Speech and pattern recognition

Allows loosely coupled components



Data-centered architectures: advantages

Ensures data integrity

Reliable, secure, testability guaranteed

Clients independent from the system: performance and usability onthe client side is typically 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 theclient



Web architecture

Another example of data-centered architectures is the Webarchitecture

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 addressingmechanism



Web architecture

Data manipulation not directly in the system but typically achievedthrough 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 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

Different criteria for layering: most notably abstraction



Abstract layer architectures

Topological constraints:

Number of layers?

Limit access to next lower layer?

Access to layer above?

Sometimes abstraction is not completely opaque



Example

Figure: Layered architecture



Operating systems

Typically organized into layers

Successive layers provide more sophisticated services to the layersabove them

Hardware services, kernel services, system services, UI services



Operating systems

Figure: Operating system



Virtual machines

A virtual machine implements an instruction set for an imaginerymachine

Often virtual machines are the underlaying mechanism by which aprogramming language is executed

E.g. Java virtual machine, different interpreters

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



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

At the cost of performance

Might help in terms of configurability



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 accross the network




The transport layer guarantees that packets are error-free and thatthey are received 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 thenetwork




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 limitmodifications to neighbour layers

Helps reusability, as layers can by used by multiple systems

Especially, if the communication is standardised

In practice each layer is often maintained by dedicated developmentteams



Layered architecture - disadvantages

Not all systems lend themselves to be organised in layers

Abstraction might have negative effect of performance

E.g. specific optimisations not possible

Hard to find right level of abstraction

In practice lot of effort to implement features which affect multiplelayers



N-tier architectures

Thr N-tier architecture is the modern client-server architecture

Originated with business applications

Through the popularity of the Web today typically related with Webapplications

Conceptually separate architecture into presentation, application anddata storage layers



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 alldata servers

Scalability is compromised because client are tightly coupled withservers




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 splitbetween the server and the client)

Scalability improved because clients are thiner




Figure: 3-tier architecture




Another advantages

Easier client maintenance because the middle tier can be updated inisolation

Better isolation of specifics of the data storage: extensibility,configurability

Better network utilization

Possibility of adding additional processing layers in the middle layer

Cleanly seprates presentation, application logic and data storage




Figure: Presentation, application, data



Rich clients

A rich client contains full knowledge of 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 no knowledge on application

The complete application knowledge is on the server

Most notably: Web clients

Even if we use AJAX: it is served by server, i.e. the applicationknowledge is on the server



Thin clients

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 Architectures

Notification architectures

Architectures where information and activity is propagated by anotification mechanism

When there are complex communication patterns that are not knownat 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

Observer pattern

Similar to blackboard data-centric architectures

Notification architectures are more general because any kind of eventsmight occur not only data-related events




At execution level two variants

Components interested in events register directly with the processthat generates these events

Components register with a dedicated notification component

The communication style in both variants is callback




Additional variants

When an event occurs the notifying component may send the eventto all registered components (broadcast)

Another possibility is to send the event only to interested components

Variations in communication style

Notification might include all the relevant data (push style)

Notification just signals that something happened: the registeredcomponent pulls the relevant data




Figure: Notification architecture




Similar to notification architecture: message queues

Used to control process flow

Two types: publish/subscribe and point-to-point

Publish/subscribe also known as topics




Examples of notification style architectures

Triggers in databases, consistency check

Spell checking in editors

Separation of presentation from persistence of data



Notification architectures - advantages

Loose coupling

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

Unclear which data should be passed with the notification

If too little 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


architectural styles i - ktikti.tugraz.at/staff/rkern/courses/sa/2012/slides_as_i.pdf ·...

Documents