Architectural Styles I Software 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 their relationships 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 2 / 80
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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 3 / 80
Outline 1 Non-Functional Concepts 2 Introduction to Architectural Syles 3 Data-flow Architectures 4 Data-centered Architectures 5 Layered Architectures 6 Notification Architectures Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 4 / 80
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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 5 / 80
Non-Functional Concepts Examples for Cross-Cutting Concerns Logging Auditing Monitoring Exception/error handling Security (e.g. authentication, authorisation) Caching Localisation Configuration management Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 6 / 80
Non-Functional Concepts 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 components need to be modified Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 7 / 80
Non-Functional Concepts 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 injected into the method calls Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 8 / 80
Non-Functional Concepts 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 9 / 80
Non-Functional Concepts 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. protocol specification, contract,...) E.g. The receiver implements the API, the sender uses the API This relationship is therefore directed Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 10 / 80
Non-Functional Concepts Coupling Coupling: degree to which software components depend on each other The degree is influenced on a couple of aspects (more than in OO languages) E.g. how generic is the protocol? Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 11 / 80
Non-Functional Concepts 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 in another Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 12 / 80
Aspects of Coupling Non-Functional Concepts Level Loose Coupling Tight Coupling Physical coupling Physic intermediary Direct physical link required Communication style Asynchronous Synchronous Type system Data-centric, selfcontained OO-Style, complex ob- messages ject trees Control of process Distributed logic compo- Central control depen- logic Platform dencies nents OS- and programming language independent Source: Enterprise SOA Strong OS and programming language dependencies Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 13 / 80
Non-Functional Concepts 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 14 / 80
Non-Functional Concepts 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 15 / 80
Non-Functional Concepts 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 (and traceability) For some attributes it is not clear, e.g. testability Therefore slight preference to loose coupling Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 16 / 80
Examples of Coupling Non-Functional Concepts CalcViewer AppControl GUI HTTP AppControl Controller NetAnalysis NotifServ Data NetAnalyzer Calcs Datasets Users External System Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 17 / 80
Non-Functional Concepts Examples of Coupling Tight coupling between Controller and the NetAnalyzer Due to callback (both need to know each other, there might even be a 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 18 / 80
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 the architectural design An architectural style is a particular pattern that focuses on the large-scale structure of a system typically described by the common vocabulary Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 19 / 80
Introduction to Architectural Syles 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 20 / 80
Introduction to Architectural Syles Architectural style An architectural style is constrained by a particular principle of how to build systems How components are organized, how data is manipulated, how components communicate,...? E.g. a hierarchy of components, sequential processing of data, asynchronous communication,... Each principle influences some quality attributes in a positive and some other in a negative way It is again balancing between advantages and disadvantages Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 21 / 80
Introduction to Architectural Syles 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 22 / 80
Data-flow Architectures 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 transformations on successive pieces of input data. Data enter the system and then flows through the components one at a time until Finally, the data is assigned to some final destination (output or a data store). Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 23 / 80
Data-flow Architectures Data-flow architectures Data-flow architectures can be classified into batch-sequential architectures and pipe and filters In the batch sequential style each step runs to completion before the next step starts E.g. UNIX command line pipes In pipe and filters style steps might run concurrently processing parts of data incrementally Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 24 / 80
Data-flow Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 25 / 80
Data-flow Architectures 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,... Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 26 / 80
Pipes and filters Data-flow Architectures Figure: Pipe and filters style Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 27 / 80
Data-flow Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 28 / 80
Data-flow Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 29 / 80
Data-flow Architectures Pipes and filters How is the data consumed? Streaming, or All data at once (batch sequential), or Chunks of data Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 30 / 80
Pipes and filters Data-flow Architectures Figure: Pipe and filters style Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 31 / 80
Data-flow Architectures 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-cutting concerns E.g. monitor throughput, logging,... Allow concurrent/parallel execution (helps scalability) Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 32 / 80
Data-flow Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 33 / 80
Data-centered Architectures 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 store is their primary goal. Basically, it is nothing more than a centralized data store that communicates with a number of clients Important for this styles are three protocols: communication, data definition and data manipulation protocol Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 34 / 80
Data-centered Architectures 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 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 35 / 80
Repository Data-centered Architectures Figure: Repository style Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 36 / 80
Blackboard Data-centered Architectures Figure: Blackboard style Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 37 / 80
Data-centered Architectures Database architecture One of the most well-known examples of the data-centered architecture, is a database architecture There is a common database schema (i.e. meta-structure of the repository) - created with data definition protocol E.g. in RDBMS a set of related tables with fields, data types, keys,... Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 38 / 80
Data-centered Architectures 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 situated communication protocol might be An inner-process communication Communication between components on the same machine Communication over network, e.g. LAN, Internet, etc. Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 39 / 80
Data-centered Architectures Database architecture 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 40 / 80
Data-centered Architectures Data-centered architectures: advantages Ensures data integrity Reliable, secure, testability guaranteed Clients independent from the system: performance and usability on the client side is typically good Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 41 / 80
Data-centered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 42 / 80
Data-centered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 43 / 80
Data-centered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 44 / 80
Data-centered Architectures 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. Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 45 / 80
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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 46 / 80
Layered Architectures Abstract layer architectures Topological constraints: Number of layers? Limit access to next lower layer? Access to layer above? Sometimes abstraction is not completely opaque Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 47 / 80
Example Layered Architectures Figure: Layered architecture Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 48 / 80
Layered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 49 / 80
Operating systems Layered Architectures Figure: Operating system Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 50 / 80
Layered Architectures Virtual machines A virtual machine implements an instruction set for an imaginery machine Often virtual machines are the underlaying mechanism by which a programming 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 51 / 80
Virtual machines Layered Architectures Figure: Virtual machine Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 52 / 80
Layered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 53 / 80
Layered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 54 / 80
Layered Architectures Peer-to-peer protocol stacks The transport layer guarantees that packets are error-free and that they 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 the network Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 55 / 80
Layered Architectures Peer-to-peer protocol stacks Figure: TCP/IP protocol stack Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 56 / 80
Layered Architectures 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 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 development teams Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 57 / 80
Layered Architectures 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 multiple layers Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 58 / 80
Layered Architectures 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 Web applications Conceptually separate architecture into presentation, application and data storage layers Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 59 / 80
Layered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 60 / 80
2-tier architectures Layered Architectures Figure: 2-tier architecture Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 61 / 80
Layered Architectures 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 (but recently might be split between the server and the client) Scalability improved because clients are thiner Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 62 / 80
3-tier architectures Layered Architectures Figure: 3-tier architecture Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 63 / 80
Layered Architectures 3-tier architectures Another advantages Easier client maintenance because the middle tier can be updated in isolation 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 64 / 80
3-tier architectures Layered Architectures Figure: Presentation, application, data Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 65 / 80
Layered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 66 / 80
Rich clients Layered Architectures Figure: Rich client architecture Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 67 / 80
Layered Architectures 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 application knowledge is on the server Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 68 / 80
Layered Architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 69 / 80
Thin clients Layered Architectures Figure: Thin client architecture Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 70 / 80
Notification Architectures Notification architectures Architectures where information and activity is propagated by a notification mechanism When there are complex communication patterns 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 71 / 80
Notification Architectures Notification architectures 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 events might occur not only data-related events Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 72 / 80
Notification Architectures Notification architectures At execution level two variants Components interested in events register directly with the process that generates these events Components register with a dedicated notification component The communication style in both variants is callback Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 73 / 80
Notification Architectures Notification architectures Additional variants When an event occurs the notifying component may send the event to 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 registered component pulls the relevant data Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 74 / 80
Notification Architectures Notification architectures Figure: Notification architecture Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 75 / 80
Notification Architectures Notification architectures Figure: Notification architecture Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 76 / 80
Notification Architectures Notification architectures 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 77 / 80
Notification Architectures Notification architectures Examples of notification style architectures Triggers in databases, consistency check Spell checking in editors Separation of presentation from persistence of data Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 78 / 80
Notification Architectures Notification architectures - advantages Loose coupling Notification receivers can easily be changed and added Helps evolvability Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 79 / 80
Notification Architectures 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 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 Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles I Nov 14, 2012 80 / 80