l5 architectural styles & interaction styles 2013 v1.8.ppt presented part1

7/28/2019 L5 Architectural Styles & Interaction Styles 2013 v1.8.Ppt Presented Part1

1/30

Architectural StylesM.R.V. Chaudron

[email protected]

1

MRV Chaudron

Time

Risk resolution Controlled risk management

IterativeWaterfall

Risk

Architecture first


2/30

Theme/Objective

of this lecture

3

Build vocabulary of architectural styles

a set of archetypes that are often used

know their relative strengths and weaknesses

Know when to apply or notto apply a particular style

The task of the architect is to come upwith a good metaphor for the system

Alexander Ran (Nokia)

MRV Chaudron

Lecture Planning

updated!

1 Mon 21 Jan Introduction Chaudron

2 Thu 24 Jan No lecture - Ch. 1 & 2

3 Mon 28 Jan Definitions and Views Chaudron Ch. 18

4 Thu 31 Jan Requirements Chaudron Ch. 16

5 Mon 4 Feb Arch. Descr. Languages Chaudron handout

6 Thu 7 Feb Architectural Styles 1 Chaudron Shaw & Garlan

7 Mon 11 Feb Architectural Styles 2 Chaudron Ch. 13

8 Thu 14 Feb Architecting at Volvo Ulrik Eklund Guest lecture9 Mon 18 Feb Design Principles Chaudron Ch. 6, 7

10 Thu 21 Feb Architecture Tactics Chaudron Ch. 5, 8

11 Mon 25 Feb Architecture Evaluation

Scenario-based

Chaudron Ch. 21

12 Thu 28 Feb Architecture

Conformance

Chaudron Ch. 20

13 Mon 4th March Guest lecture Guest

14 Thu 7th March


3/30

5

CONTENTS1. Introduction2. Architectural styles

2.1 Client/Server2.2 Pipe and Filter style2.3 Blackboard style2.4 Publish Subscribe2.5 Peer-to-Peer

2.6 Layered style3. Interaction style4. Conclusions

6

Architectural styleNomenclature inspired by building architecture;

bridges: suspension, arc, (check your Euro-notes)

Cathedral Amiens

http://en.wikipedia.org/wiki/Architectural_style

Hagia Sofia, Istanbul

Buildings: Gothic, Byzantian, .
http://en.wikipedia.org/wiki/Architectural_stylehttp://en.wikipedia.org/wiki/Architectural_style


4/30

Cordoba, Spain

7

8

Conceptual integritycounter example!


5/30

9

Architectural style 1/2

An architectural styleis defined by:

a set of rules and constraints that prescribe

- vocabulary/metaphor: which types of components,interfaces & connectors must/may be used

in a system.

Possibly introducing domain-specific types

- structure: how components and connectors may becombined

- behaviour: how the system behaves- guidelines: these support the application of the style

(how to achieve certain system properties)

Architectural style 2/2

An architecture style defines a family of systemsin terms of a pattern of structural organization.

An architectural style defines

a vocabulary of components and connector types

a set of constraints on how they can be combined

one or more semantic models that specify how asystems overall properties can be determined fromthe properties of its parts

10


6/30

11

Architectural style

Architectural styles are design paradigms fora set of design dimensions

Some architectural styles emphasize different aspectssuch as: Subdivision of functionality, Topology orInteraction style

Styles are open-ended; new styles will emerge

An architecture can use several architectural styles

Architectural styles are not disjoint

Maturing Discipline

12

Architectural styles are the codification ofcommon recurring patterns of software design

Codification enablescommunication, reuse, comparison

generally useful (generic)generally easy to get rightgenerally as good as the alternatives


7/30

On Codification of Engineering Knowledge

Engineering is an art/craft, not anengineering discipline.

An engineering discipline encodesknowledge about successful solutionsinto rules such that normal engineerscan produce great systems.

Patrick Lardieri, Lockheed MartinMODELS 2007

(based on Shaw & Garlan)

13

14

CONTENTS1. Introduction

2. Architectural styles2.1 Client/Server2.2 Pipe and Filter style2.3 Blackboard style

2.4 Publish Subscribe2.5 Peer-to-Peer2.6 Layered style

3. Interaction style4. Conclusions


8/30

15

Client-Server Architectures

Nice source:IT Architectures and Middleware:Strategies for building Large Integrated Systems,Chris Britton and Peter Bye, Addison Wesley, 2004

What is Client / Server?

16

Typical application area:distributed multi-user (business) information systems

Client: an application that makes requests (to the servers)and handles input/output with the system environment

Server: an application that services requests from clientsClient/Server System:

an application that is built from clients and servers

In real-life: client instructs/commandsthe server.Pitfall: keep an eye on (hidden) dependencies


9/30

Why Client / Server?

17

- multiple users want to share and exchange data

File server

Applications- first: attempt: shared file-server

- problem:

scalability to 10 due tocontention for files andvolume of data-transfer

- solution:perform processing on(file) server

1980s

files

3-tier Reference Model

18

presentationlogic

applicationlogic

datamanagement

presentation logic ([G]UI):anything that involves system/user interactione.g. dialogs (management), forms, reports

application logic (data processing):

where the functionality of the applicationresides / where the actual computation of thesystem takes place

data management:storing, retrieving and updating data

interfacesto OS andnetwork


10/30 1

19

Client / Server Style

Concept: Separation of application in units of changeComponents: presentation,

application logic,business logic,data management

Connector: uses lower layerInteraction style: request/response

presentationlogic

businesslogic

datamanagement

applicationlogic

client

server

Deployment of C/S Model

20

Rather than having the client do the processing

Move processing power to server such that the server sends a

(condensed) response to request rather than a whole file

presentationlogic

applicationlogic

datamanagement

2-tier

shared

data

presentationlogic

applicationlogic

datamanagement

presentationlogic

applicationlogic

datamanagement1

-tier

client

server


11/30 1

C/S Example: Thin Client

21

presentationlogic

applicationlogic

data

management

WWW Browser

database storage

and access

functionalprocessing

Thin Client C/S:largest part of processing at the server-side

Network load: lowConfig. Mngmnt: simple (only server)Security: concentrated at serverRobustness: stateless clients => easy fault recovery

C/S Example: Thick Client

22

Thick Client:significant processingat the client-side

WWW Browser

database

application(specific)

presentationlogic

applicationlogic

datamanagement

applicationlogic

application(generic)

Network load: highConfig. Mngmnt: complex (both client & server)Security: complex (both client & server)Robustness: clients have state => complex fault recovery


12/30 1

23

Client/Server in terms of Characteristics

Dependencies: client depends on the server

Topology: one or more clients may be connected to a

server there are no connections between clients

Multiplicity: 1-to-1, directed

Synchronicity: synchronous or asynchronous

Mobility: easily supports client mobiliy

Binding: from compile to invocation time

Initiative: request (by client) / response (by server)

Periodicity: typically a-periodic (periodic possible)

Security: typically controlled at server,

also possible at application/business layer

Exa

mple3-tier

System

24Diagram from

Wikipedia, 2007

(application)
http://upload.wikimedia.org/wikipedia/en/6/66/Overview_of_a_three-tier_application.pnghttp://upload.wikimedia.org/wikipedia/en/6/66/Overview_of_a_three-tier_application.pnghttp://upload.wikimedia.org/wikipedia/en/6/66/Overview_of_a_three-tier_application.png


13/30 1

Deployment: Many physical clients andservers

25

Business Logic Layer

26

Advantage of business logic-tier:

changes to business are localized

(compared to intertwining with application logic)

The complexity of the middle tier ranges from

reactive with little intelligence(e.g. resource management and interconnection services)

to active with much intelligence

(active enforcement of global constraints and coordination of

activities across applications e.g. workflow)

presentationlogic

applicationlogic

datamanagement

businesslogic

An even broader organizational scope of sharing and

exchanging data requires

coordination across multiple applicationsand databases


14/30 1

Types of business logic

Transaction Processing Manager/Monitor Handling of transactions

queuing, coordination across multiple DBs

TP Monitor decouples client-thread from server-thread

=> Increases scalability

Coordination of workflow

Message Queues

27

Advantages of Business Logic Layer- better scalability of application

- security measures can be centrally allocated

- separate maintenance of application and business logic

Client / Server SummaryTask are mapped on platform where they are most

efficiently handled

presentation layer on client

data management and storage on a server

possible intermediate platforms for transaction multiplexingand global coordination

With the aim of obtaining

scalability: changing number of clients

interoperability: client may use data from multiple sources

28


15/30 1

Emergent Interface

Technologies

29

presentationlogic

businesslogic

data

management

applicationlogic

HTML, XML

.Net, Corba, EJBXML, SOAP, RDF

ODBC

presentationlogic

businesslogic

data

management

applicationlogic

WWW Sources for C/S

C/S-FAQ:

http://www.faqs.org/faqs/client-server-faq/

C/S info @ Software engineering institute Carnegie Mellon Univ.

http://www.sei.cmu.edu/str/descriptions/clientserver_body.html

Sectie over C/S bij een cursus @ TU Delft

http://www.sepa.tudelft.nl/modulemateriaal/tb141/Comms/inhoud.htm

Middleware (TP, MO-Mw, DB-Mw, Message-brokers and OBJ-brokers)http://www.sdmagazine.com/breakrm/features/s994f2.shtml

30
http://www.w3.org/TR/SOAP/http://www.faqs.org/faqs/client-server-faq/http://www.sei.cmu.edu/str/descriptions/clientserver_body.htmlhttp://www.sepa.tudelft.nl/modulemateriaal/tb141/Comms/inhoud.htmhttp://www.sdmagazine.com/breakrm/features/s994f2.shtmlhttp://www.sdmagazine.com/breakrm/features/s994f2.shtmlhttp://www.sepa.tudelft.nl/modulemateriaal/tb141/Comms/inhoud.htmhttp://www.sei.cmu.edu/str/descriptions/clientserver_body.htmlhttp://www.faqs.org/faqs/client-server-faq/http://www.faqs.org/faqs/client-server-faq/http://www.faqs.org/faqs/client-server-faq/http://www.faqs.org/faqs/client-server-faq/http://www.faqs.org/faqs/client-server-faq/http://www.w3.org/TR/SOAP/


16/30 1

31

CONTENTS1. Introduction2. Architectural styles

2.1 Client/Server2.2 Pipe and Filter style2.3 Blackboard style2.4 Publish Subscribe2.5 Peer-to-Peer2.6 Layered style


32

Pipe and Filter Style (1)Concept: Series of filters / transformation

where each component is consumer and producer

Components: filters / transformationspossibly also: sources and sinksConnectors: pipes;interaction style: streaming of data

Topology: linear; possible variations:feedback-loops, splitting pipes

Filter 1 Filter 2 Filter 3 Filter 4

computationalcomponent

data flow


17/30 1

Special types of filters (?)

Pump (Producer)Produces data and puts it to an outputport that is connected to the input end ofa pipe.

Sink (Consumer)Gets data from the input port that is

connected to the output end of a pipeand consumes the data.

33

34

Pipe and Filter Style (2)

Constraints about the way filters and pipes can be joined: Unidirectional flow

Control flow derived from data flow

Behaviour Types:a. Batch sequential

Run to completion per transformation

b. ContinuousIncremental transformation

variants: push, pull, asynchronous



18/30 1

35

Pipe and Filter Style (3)

Semantic ConstraintsFilters are independent entities

- they do not share state

- they do not know their predecessor/successor


What are the dependencies between filters?Compare this with Client Server?

36


19/30 1

37

Example P&F Architecture

38

Pipe and Filter Style (4a)Advantages: Simplicity:

no complex component interactions

easy to analyze (deadlock, throughput, )

Easy to maintain and to reuse

Filters are easy to compose (also hierarchically?)

Can be easily made parallel or distributed


20/30 2

39

Pipe and Filter Style (4b)Disadvantages: Interactive applications are difficult to create

Filter ordering can be difficult

Performance:

- Enforcement of lowest common data representation,

ASCII stream, may lead to (un)parse overhead

- If output can only be produced after all input is

received,an infinite input buffer is required

(e.g. sort filter)

If bounded buffers are used, deadlocks may occur

40

Pipe and Filter Style (5) QualityFactorsExtendibility: extends easily with new filters

Flexibility: - functionality of filters can be easily

redefined,

- control can be re-routed

(both at design-time, run-time is difficult)

Robustness: weakest link is limitation

Security: -

Performance: allows straightforward parallelisation


21/30 2

41

Pipe and Filter Style (6)Application Context

Rules of thumb for choosing pipe-and-filter (o.a. from Shaw/Buschman):

- if a system can be described by a regular interaction pattern of acollection of processing units at the same level of abstraction;

e.g. a series of incremental stages

(horizontal composition of functionality);

- if the computation involves the transformation of streams of data(processes with limited fan-in/fan-out)

Hint: use a looped-pipe-and-filter if the system does continuouscontrolling of a physical system

Typical application domain: signal processing

42

CONTENTS1. Introduction

2. Architectural styles2.1 Client/Server2.2 Pipe and Filter style2.3 Blackboard style2.4 Publish Subscribe2.5 Peer-to-Peer2.6 Layered style



22/30 2

43

Blackboard Style (1)Concept: Concurrent transformations on

shared data

Components: processing units (typically knowledge source)Connectors: blackboard

interaction style: asynchronousTopology: one or more transformation-components maybe connected to a data-space,there are typically no connections betweenprocessing units (bus-topology)

data

Component Component Component

44

Blackboard Style (2)Behaviour Types:

a. Passive repositoryAccessed by a set of components; e.g. database or server

b. Active repositorySends notification to components when data of interest

changes; e.g. blackboard or active database

Constraints:Consistency of repository: Various types of (transaction) consistency

Component

data

ComponentComponent


23/30 2

JavaSpaces Blackboard in

Java

45

Layering & Blackboard

46

BB

A B CUI


24/30 2

47

Blackboard Style (3)

Advantages: Allows different control heuristics Reusable & heterogeneous knowledge sources Support for fault tolerance and robustness

by adding redundant components

+/- Dataflow is not directly visible

Disadvantages

Distributed implementation is complex

distribution and consistency issues

Blackboard Characteristics

48

- Data may be structured (DB) or unstructured

- Data may be selected based on content

- Applications may insert/retrieve different data-type

per access.

This in contrast to pub-sub where data of the same typeis retrieved repeatedly


25/30 2

Example of Blackboard

Architecture Hearsay, speech understanding

Hearsay was developed in the 1970s by RajReddy et al. at Carnegie Mellon University.

Randy Davis, Speech Understanding UsingHearsay, MIT videotape, 1984.

49Slides adapted from Terry Bahill, Univ. Arizona, 2007

Hearsay: knowledge sources

Acoustics

Spectrographs

Phonetics

Pronunciation

Coarticulation

Syntax

Semantics

Pragmatics

50

Pronunciation

data

Spectrogr. Phonetics

Semantics

Syntax

Pragmatics

Acoustics


26/30 2

Hearsay: levels of abstraction*

Sentences

Phonemes

Syllables

Words

Phrases

Acousticwaveform

Time51

A blackboard architecture for counteringterrorismRubin, S.H.; Smith, M.H.; Trajkovic, L.Systems, Man and Cybernetics, 2003.IEEE International Conference on

Volume 2, Issue , 5-8 Oct. 2003 Page(s):1550 - 1553 vol.2

52


27/30 2

L.D. Erman, F. Hayes-Roth, V.R. Lesser and D. R. Reddy, The Hearsay-II speech understanding system: integrating knowledge to resolveuncertainty, ACM Computing Surveys 12(2), pp213-253, 1980.

L.D. Erman, P.E. London and S. F. Fickas, The Design and an ExampleUse of Hearsay-II, Proc. IJCAI-81, pp 409-415, 1981.

53

Hearsay: control

Data driven

Asynchronous

Opportunistic

Islands of reliability

Combined top-down and bottom-up

54


28/30 2

From http://www.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1997/lectures/19.Blkbd/base.020.html

55

56

Blackboard Style (4) Quality FactorsExtensibility: components can be easily added

Flexibility: functionality of components can be easily

changed

Robustness: + components can be replicated,

- blackboard is single point of failureSecurity: - all process share the same data

+ security measures can be centralized

around blackboard

Performance: easy to execute in parallel fashion

consistency may incur synchroniz.-penalty
http://www.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1997/lectures/19.Blkbd/base.020.htmlhttp://www.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1997/lectures/19.Blkbd/base.020.htmlhttp://www.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1997/lectures/19.Blkbd/base.020.htmlhttp://www.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1997/lectures/19.Blkbd/base.020.htmlhttp://www.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/1997/lectures/19.Blkbd/base.020.html


29/30 2

57

Blackboard Style (5) Application ContextRules of thumb for choosing blackboard (o.a. from Shaw):

- if representation & management of data is a central issue

- if data is long-lived

- if order of computation

- can not be determined a-priori

- is highly irregular

- changes dynamically

- if units of different functionality (typically containinghighly specialized knowledge) concurrently act on shared

data (horizontal composition of functionality)

Example application domain: expert systems

Interaction Style

58


30/30

59

Interaction Styles and Dependencies

Referential coupling : sender has reference to receiver name/address

Temporal coupling: sender and receiver synchronize in time

Temporal coupling

Referentialcoupling

Radio, TV Notice board

telephone E-mail

Connection-oriented

Asynchronousconnection

BlackboardBroadcast

noyes

no

yes

Summary Architectural Styles

60

Every Architect should have a standard set ofarchitectural styles in his/her repertoire it is important to understand the essential properties

of each style: when to (not) use them examples:

C/S, pipe and filters, blackboard, pub/sub, P2P

The choice for a style can make a big difference inthe quality properties of a system analysis of the differences can provide rational for

choosing a style

l5 architectural styles & interaction styles 2013 v1.8.ppt presented part1

Documents