Architectural Styles II - Graz University of...

61
Architectural Styles II Soware Architecture VO (706.706) Roman Kern Institute for Interactive Systems and Data Science, TU Graz 2020-01-08 Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 1 / 61

Transcript of Architectural Styles II - Graz University of...

Page 1: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Architectural Styles IISo�ware Architecture VO (706.706)

Roman Kern

Institute for Interactive Systems and Data Science, TU Graz

2020-01-08

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 1 / 61

Page 2: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Outline

1 Network-Centred Style

2 Remote Invocation Architectures

3 GUI Architectures

4 Heterogeneous Architectures

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 2 / 61

Page 3: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Network-Centred StyleFocus on communication.

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 3 / 61

Page 4: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

Basic concept:

The client uses a serviceThe server provides a serviceThe service can be any resource

I E.g. data, file, CPU, display device

Typically connected via a network

Clients are independent from each other

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 4 / 61

Page 5: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 5 / 61

Page 6: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

The server provides an abstract service

The implementation of the server decides how to fulfil the request

Abstraction of programming language, operating system

⇒ loose coupling between client and server

The location of the server is transparent

Sometimes the client also might become the server (and vice versa)

⇒ increases the coupling

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 6 / 61

Page 7: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

Separation of concerns (SoC)Functionality is clearly split into separate components

Also a motivation for the layered architecture style, where each layer is responsible for itsown abstraction

Aspect oriented programming tries to separate cross-cu�ing concerns into separatemodules

Supports independent evolvability

Achieved, if the communication between client and server is well designed

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 7 / 61

Page 8: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

Client-server pa�ern is used by other architectural stylesIt can be used to realise a shared repository

I E.g., for the data-centric repository pa�ernI E.g., for filters which operate on a single shared data structure

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 8 / 61

Page 9: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Shared Repository

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 9 / 61

Page 10: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

Two basic types of topology of the serverI Single, centralised server orI Multiple, distributed servers

Centralised servers are easier to administer (install, deploy updates, maintain, monitor, …)

Distributed servers scale be�er, but could introduce complexity (e.g. require two-phasecommits)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 10 / 61

Page 11: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Centralised

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 11 / 61

Page 12: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Distributed

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 12 / 61

Page 13: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Scalability

Two basic types of scaling:Vertically, by increasing the computing power of a single machine (scale up)

Horizontally, by adding more machines (scale out)

Note: Scaling strategies are not specific to client-server architectures

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 13 / 61

Page 14: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Scalability

Scaling vertically is o�en the only option

Especially if the system has not been designed from the ground up to allow distributedprocessing

Scaling vertically is made easier in a virtual environment (virtual machines instead ofphysical)

Because the system could be transferred to a more powerful machine, without the systemknowing

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 14 / 61

Page 15: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Scalability

Scaling horizontally should provide a high upper limit for scalability

Needs support from the system, not every system allows being distributed

Might lead to a high communication overhead due to synchronisation between the nodes

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 15 / 61

Page 16: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Scalability

Distributed servers need to be specifically designed to allow scaling horizontally

Will be typically more e�ort to develop

Upgrading to a bigger machine might be cheaper

Which strategy (scale up or scale out) is more suitable, depends on the actual system.

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 16 / 61

Page 17: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

Stateful vs. statelessIf the client-server communication is stateful, the server keeps track of the application state

Typically provides a handle or a session idThe client then may manipulate the state on the server, e.g.

I Open file (returns file handle)I Append lineI Close file

Easier for the clients, as they not need to manage the state⇒ needed if coupled with thinclients

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 17 / 61

Page 18: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

If the client-server communication is stateless, the client is responsible to keep track of theapplication state

The server does not need to store or manage session specific data⇒ typically coupled withrich clients

Therefore the scalability of stateless servers are generally be�er than stateful

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 18 / 61

Page 19: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server

Cloud ComputingThe server is no longer in the organisations network, but somewhere in the Internet

Example: cloud services by Salesforce, Amazon, Google, Microso�

Scalability, security, reliability is expected to be handled by a specialised team

Loss of control, legal issues (data is exported to another country)

Needs a working Internet connection

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 19 / 61

Page 20: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Advantages

Conceptually simple

Clear separation of responsibilities, eases evolvability, helps testabilityGood scalability (especially, if stateless)

I Excellent scalability (if server can be scaled out)

Good for security, as data can be held at the server with restricted access

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 20 / 61

Page 21: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Client-Server - Disadvantages

Risk of bad usability/performance, if the communication between client and server is slow,or has a high latency

Need to develop/agree on a protocol between client and server

For stateful, centralised servers scalability is limited and single point of failure

Integrability into existing systems might not be possible (e.g. if the communication is notpossible, or not allowed)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 21 / 61

Page 22: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Peer to peer

Separation between client and server is removed

Each client is a server at the same time, called peerThe goal is to distribute the processing or data among many peers

No central administration or coordination

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 22 / 61

Page 23: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Peer to peer

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 23 / 61

Page 24: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Peer to peer

Each peer provides services and consumes services

Communication might occurs between all peers

Number of peers is dynamic

Each peer has to know how to access other peers (discover, search, join)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 24 / 61

Page 25: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Peer to peer

Once a peer is initialised, it needs to be come part of the networkA bootstrapping mechanism is needed:

I For example via a broadcast messageI For example a public list of network addresses

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 25 / 61

Page 26: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Peer to peer - centralised P2P

Centralised peer to peerSome aspects are centralised

For example, a central component keeps track of the available peers

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 26 / 61

Page 27: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Peer to peer - hybrid P2P

Hybrid peer to peerNot all peers are equal, some have additional responsibilities

They are called supernodes

Example: Skype uses a peer-to-peer protocol, but also uses supernodes and a central loginservers

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 27 / 61

Page 28: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Peer to peer - Advantages

Typically, excellent scalability, as the computation can be distributed

Good for reliability, as data can be replicated over multiple peers

No single point of failure

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 28 / 61

Page 29: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Peer to peer - Disadvantages

�ality of service is not deterministic, cannot be guaranteedI E.g. high latency

Very complex, hard to maintain and to test

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 29 / 61

Page 30: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Remote Invocation ArchitecturesFocus on the remote invocation (via network)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 30 / 61

Page 31: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Remote invocation and service architectures

Remote invocation architectures involve distributed processing components

Typically, a client component invokes a method (function) on a remote component

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 31 / 61

Page 32: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Remote invocation and service architectures

Advantages: increased performance through distributed computation

Only if network is reliable and fast and the communication overhead is manageable

Disadvantages: o�en, tightly coupling of components (in comparison with a client-serverarchitecture)

Managing of addressability (recollect unique identity of objects) increases communicationoverhead

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 32 / 61

Page 33: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Remote invocation and service architectures

Service architectures introduce a special component where services are registered

Any component interested in a service asks that component for the address of the service

It tries to solve the addressability problem

If communication protocols are standardized then services can be integrated on-the-fly

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 33 / 61

Page 34: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Remote invocation and service architectures

Web servicesUse Web protocols for communication

However, the addressability is still not managed because you have to know how to addressobjects in a remote service

Web services are in essence only remote procedure calls using Web protocols

Same advantages and disadvantages apply

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 34 / 61

Page 35: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Broker

Separate communication from the application functionality

Support for distributed systems

The broker hides the communication from the components of the system

The broker coordinates the communication

A broker can be used to transparently change a non-distributed system into a distributedone

For example: The client interacts with a remote object via a broker

Note: Similar to the proxy design pa�ern

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 35 / 61

Page 36: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Broker

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 36 / 61

Page 37: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Broker - Tasks of a broker

The task of the brokerFind the appropriate server/service

Forward request to the servers, and

Report the result (or error message/exception) back to the client

The communication is abstracted away from the client

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 37 / 61

Page 38: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Broker - Relationship to other pa�erns

The broker pa�ern has relationships with other pa�erns

E.g. the broker can be implemented as separate layer

E.g. the broker uses a client/server infrastructure

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 38 / 61

Page 39: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Broker - Advantages

Decoupling of components (the networking aspect)

Helps flexibility, maintainability and evolvability

Allows a system to be distributed, even if it has not been designed for this in the first place

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 39 / 61

Page 40: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Broker - Disadvantages

Network communication might introduce new types of errors

Due to network latencies and limited bandwidth the behaviour might change

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 40 / 61

Page 41: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Interceptor - Overview

Motivation: Separate functionality into a separate components

Allow integration of additional services without changing the core componentsInterface provided by a component, which allows another component to register itself

I And be invoked at specific events

Open-closed design principle (open for extension, but closed for modifications)

Used to address cross-cu�ing concerns

Similar to the notification architecture style

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 41 / 61

Page 42: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Interceptor - Example

Example: Logging

System consists of two components: a client and a server

Each component provides a callback interface when some event occurs

A logging components registers itself at every component

The logging components store the log into a shared repository

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 42 / 61

Page 43: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Interceptor - Example

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 43 / 61

Page 44: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Interceptor - Advantages

Interceptor components can be reused (reusability)

Excellent flexibility

Clear separation of concerns, loose coupling⇒ maintainability, evolvability

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 44 / 61

Page 45: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Interceptor - disadvantages

Can get quite complex quickly

Potential cascading callbacks, endless loops

Sometimes events are non-deterministic

Core components need to provide the callback interface

May lead to bad testability

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 45 / 61

Page 46: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

GUI ArchitecturesFocus on user interaction.

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 46 / 61

Page 47: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Model View Controller (MVC)

Motivation: reusability and separation of concerns

Three roles: model, view & controller

Model: encapsulates the behaviour and data of the application domain

View: renders the model for presentation

Controller: Reacts on user input, modifies the model and dispatches to the view

Both, controller and view, depend on the model

Controller and view are part of the UI

O�en used for web applications (but not exclusively)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 47 / 61

Page 48: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Model View Controller (MVC)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 48 / 61

Page 49: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

MVC - Model

ModelEncapsulates the application state

Response to state queries

Exposes application functionality

Notify view of changes (optionally)

Note: Notification only necessary, if the model and view realise an observer pa�ern

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 49 / 61

Page 50: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

MVC - View

ViewRenders the model

Requests updates from model

Prepares the user interface for the controller

Usually multiple views

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 50 / 61

Page 51: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

MVC - Controller

ControllerManipulates the model

Triggers application behaviour

Selects view for response (optionally)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 51 / 61

Page 52: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

MVC - Relationships

The model-view-controller pa�ern does not replace a n-tier architecture

Model is part of the n-tier pa�ern and the MVC pa�ern

The model communicates with lower abstraction layers (e.g. data access layer)

The model might use a notification pa�ern to inform the view of changes

The lesser known presentation-abstraction-control pa�ern is similar to MVC

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 52 / 61

Page 53: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

MVC - Advantages

Separation of concerns, helps reusabilityMultiple user interfaces without changes to the model, e.g. mobile and Web

Helps configurability (as interface changes are easier, with less expected side e�ects thanchanges to the application logic)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 53 / 61

Page 54: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

MVC - Disadvantages

Increases the complexity by additional components

Not all systems are applicable to MVC pa�ern

If updates to the view are based on notifications, it might be hard to find errors

In these cases, it is hard to ensure a good usability (no control when an update happens)

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 54 / 61

Page 55: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Heterogeneous ArchitecturesFocus on the real-world.

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 55 / 61

Page 56: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Heterogeneous architectures

No real system follows strictly only a single style

Styles themselves are not that strictly separated but they are blurred

Architectures might be conceptually heterogeneousN-tier architectures are layered architectures

N-tier architectures are typically data-centric architectures

Thin clients involve some sort of notification architecture

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 56 / 61

Page 57: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Heterogeneous architectures

Architectures might be structurally heterogeneousOverall architecture follows one style

Single components follow other styles

The Web has a 2-tier architecture: browser and server

The browser itself has a notification architecture to handle user events

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 57 / 61

Page 58: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Heterogeneous architectures

Architectures might be heterogeneous at execution levelAt execution level components follow di�erent styles

I E.g., notification architectures might include remote procedure calls if components aredistributed

Service architectures require networking architecture which is a layered architecture, etc..

In real systems architectures are heterogeneous at all levels!

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 58 / 61

Page 59: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Heterogeneous architectures

Web-based search engine

Conceptually: data-centric, layered, 3-tier

Structurally: layered (network), 3-tier, notification

Execution: distributed, service-oriented, notification with callbacks, …

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 59 / 61

Page 60: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

Conclusion

Architectural styles provide pa�ernsWhy one should know these styles?

I They provide a common vocabularyI They provide blueprints on how a system can be designedI They provide a well known structure and behaviour

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 60 / 61

Page 61: Architectural Styles II - Graz University of Technologykti.tugraz.at/staff/rkern/courses/sa/slides_as_ii.pdfArchitectural Styles II So†ware Architecture VO (706.706) Roman Kern Institute

The EndNext: Distributed Architectures

Roman Kern (ISDS, TU Graz) Architectural Styles II 2020-01-08 61 / 61