Architectural Styles I Software Architecture VO/KU (707023/707024) Roman Kern KTI, TU Graz 2015-01-07 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 1 / 86
Outline 1 Non-Functional Concepts 2 Introduction to Architectural Styles 3 Data-flow Architectures 4 Data-centered Architectures 5 Layered Architectures 6 Notification Architectures Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 2 / 86
Non-Functional Concepts Non-Functional Concepts Implications of cross-cutting concerns Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 3 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 4 / 86
Non-Functional Concepts Examples for Cross-Cutting Concerns Logging Auditing Monitoring Exception/error handling Security (eg authentication, authorisation) Caching Localisation Configuration management Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 5 / 86
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 Eg changes due to new security constraints require all components to be inspected Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 6 / 86
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 Eg logging is done in a separate module and at runtime injected into the method calls Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 7 / 86
Non-Functional Concepts Cross-Cutting Concerns on the SA Level Keep cross-cutting functionality in separate components (is possible) Eg dedicated component for authentication/authorisation Use/develop components that allow modifications Eg Interceptor architectural pattern Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 8 / 86
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 (eg protocol specification, contract, ) Eg The receiver implements the API, the sender uses the API This relationship is therefore directed Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 9 / 86
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) Eg how generic is the protocol? Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 10 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 11 / 86
Non-Functional Concepts Aspects of Coupling Level Loose Coupling Tight Coupling Physical coupling Physic intermediary Direct physical link required Communication Asynchronous Synchronous style Type system Data-centric, selfcontained OO-Style, complex ob- messages ject trees Control of pro- Distributed logic com- Central control cess logic Platform dependencies ponents OS- and programming language independent Strong OS and programming language dependencies Source: Enterprise SOA Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 12 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 13 / 86
Non-Functional Concepts Consequences of Loose Coupling Components can be easily exchanged Components are required to be more generic Eg use standard protocols instead of custom ones Will typically require more effort and better design/planning Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 14 / 86
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, eg testability Therefore slight preference to loose coupling Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 15 / 86
Non-Functional Concepts Examples of Coupling Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 16 / 86
Non-Functional Concepts Examples of Coupling Tight coupling between Service and the RouteFinder Due to callback (both need to know each other, there might even be a temporal coupling here) Loose coupling between Tickets and External System The external system does not need to know the Ticket component The external system might use a standard protocol Easy to exchange the external system Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 17 / 86
Introduction to Architectural Styles Introduction to Architectural Styles Make use of prior experiences Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 18 / 86
Introduction to Architectural Styles Experience in building software systems Over the years a lot of experience has been gained Certain patterns and structures appear very often Therefore architectural patterns are discovered, not invented Such patterns and structures become a part of the vocabulary Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 19 / 86
Introduction to Architectural Styles Experience in building software systems 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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 20 / 86
Introduction to Architectural Styles 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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 21 / 86
Introduction to Architectural Styles 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,? Eg 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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 22 / 86
Introduction to Architectural Styles 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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 23 / 86
Data-flow Architectures Data-flow Architectures Architecture style dealing with a stream of data Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 24 / 86
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) Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 25 / 86
Data-flow Architectures Data-flow architectures Data-flow architectures can be classified into batch-sequential architectures and pipes and filters In the batch sequential style each step runs to completion before the next step starts Eg UNIX command line pipes In pipe and filters style steps might run concurrently processing parts of data incrementally Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 26 / 86
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 Eg same process: filters run within threads Eg same machine: filters run within own processes Eg network: pipes use the networking architecture Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 27 / 86
Data-flow Architectures Pipes and filters Conceptually filters consume data from input and write data to output Input and output: communication channels, ie pipes Depending on where the filters reside different execution architectures 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, Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 28 / 86
Data-flow Architectures Pipes and filters Figure : Pipe and filters style Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 29 / 86
Data-flow Architectures Pipes and filters Variations: structural and communicational Structural: more complex topologies might be used Eg 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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 30 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 31 / 86
Data-flow Architectures Pipes and filters How is the data consumed? Streaming, or All data at once (batch sequential), or Chunks of data Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 32 / 86
Data-flow Architectures Pipes and filters Figure : Pipe and filters style Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 33 / 86
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 Eg monitor throughput, logging, Allow concurrent/parallel execution (helps scalability) Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 34 / 86
Data-flow Architectures Pipes and filters - disadvantages Pipes often lead to batch processing Therefore not well suited for interactive applications Eg 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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 35 / 86
Data-centered Architectures Data-centered Architectures Architectures focused on data integrity Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 36 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 37 / 86
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 (eg insert data) Blackboard: the system sends notification and data to subscribers when data of interest changes, and is thus active Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 38 / 86
Data-centered Architectures Repository Figure : Repository style Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 39 / 86
Data-centered Architectures Blackboard Figure : Blackboard style Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 40 / 86
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 (ie meta-structure of the repository) - created with data definition protocol Eg in RDBMS a set of related tables with fields, data types, keys, Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 41 / 86
Data-centered Architectures Database architecture Clients use data manipulation protocol to work with the data Eg 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, eg LAN, Internet, etc Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 42 / 86
Data-centered Architectures Database architecture Pipes with shared data are similar to data-centered architectures Blackboard architecture traditionally used for complex systems Eg Speech and pattern recognition Allows loosely coupled components Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 43 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 44 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 45 / 86
Data-centered Architectures Web architecture Another example of data-centered architectures is the Web architecture There is a common data schema (ie meta-structure of the Web) Follows hypermedia data model Pages (nodes) and links between them, as well as addressing mechanism Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 46 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 47 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 48 / 86
Layered Architectures Layered Architectures Architectures with clear layers of responsibilities Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 49 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 50 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 51 / 86
Layered Architectures Example Figure : Layered architecture Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 52 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 53 / 86
Layered Architectures Operating systems Figure : Operating system Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 54 / 86
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 Eg 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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 55 / 86
Layered Architectures Virtual machines Figure : Virtual machine Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 56 / 86
Layered Architectures Interpreter Similar to a virtual machine, but only limited to execute code Eg 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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 57 / 86
Layered Architectures Peer-to-peer protocol stacks A common example of layered architecture is a network protocol stack Eg TCP/IP protocol stack Four layers The lowest layer handles communication between two computers The internet layer handles routing of packets accross the network Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 58 / 86
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 Eg HTTP, SMTP, FTP, The layers constitute a series of increasingly abstract operations Higher layers span a virtual connection between computers on the network Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 59 / 86
Layered Architectures Peer-to-peer protocol stacks Figure : TCP/IP protocol stack Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 60 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 61 / 86
Layered Architectures Layered architecture - disadvantages Not all systems lend themselves to be organised in layers Abstraction might have negative effect of performance Eg specific optimisations not possible Hard to find right level of abstraction In practice lot of effort to implement features which affect multiple layers Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 62 / 86
Layered Architectures 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 storage layers Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 63 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 64 / 86
Layered Architectures 2-tier architectures Figure : 2-tier architecture Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 65 / 86
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) Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 66 / 86
Layered Architectures 3-tier architectures Figure : 3-tier architecture Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 67 / 86
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 separates presentation, application logic and data storage Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 68 / 86
Layered Architectures 3-tier architectures Figure : Presentation, application, data Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 69 / 86
Layered Architectures 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 (eg e-mail clients) Clients for custom applications using a custom protocol Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 70 / 86
Layered Architectures Rich clients Figure : Rich client architecture Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 71 / 86
Layered Architectures Thin clients Thin clients have little 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 server, ie the application knowledge is on the server Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 72 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 73 / 86
Layered Architectures Thin clients Figure : Thin client architecture Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 74 / 86
Notification Architectures Notification Architectures Architectures for loosely coupled components Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 75 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 76 / 86
Notification Architectures Notification architectures Also called: publish-and-subscribe Other terminology: listeners and callbacks Similar to the observer pattern from the field of design pattern Similar to blackboard data-centric architectures Notification architectures are more general because any kind of events might occur not only data-related events Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 77 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 78 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 79 / 86
Notification Architectures Notification architectures Figure : Notification architecture Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 80 / 86
Notification Architectures Notification architectures Figure : Notification architecture Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 81 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 82 / 86
Notification Architectures Notification architectures Examples of notification style architectures Triggers in databases Consistency checks Spell checking in editors Separation of presentation from persistence of data Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 83 / 86
Notification Architectures Notification architectures - advantages Loose coupling Notification receivers can easily be changed and added Helps evolvability Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 84 / 86
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 Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 85 / 86
Notification Architectures The End Next: Architectural Styles II Roman Kern (KTI, TU Graz) Architectural Styles I 2015-01-07 86 / 86