Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
Architectural Styles IISoftware Architecture VO/KU (707.023/707.024)
Denis Helic, Roman Kern
KMI, TU Graz
Nov 21, 2012
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 1 / 66
Recap
Software architecture defines the components and theirrelationships in a (complex) system
Software architecture tries to solve the non-functional requirements
... and focus on the non-runtime quality attributes - X-ability
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 II Nov 21, 2012 2 / 66
Recap
Architectural style defines the structural pattern, which consists of
The components, the connections, set of constraints
Architectural style are re-occurring patterns
Such patterns and structures become a part of the vocabulary
Each pattern may address different quality attributes
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 3 / 66
Recap
Data flow: Pipes & filters (block-sequential, pipelines)
Data centred: Repository, Blackboard (databases, Web, ...)
Layered (indirection): Operating system, virtual machine, interpreter
Layered (communication): Network stacks
Layered (functional): n-tier, 2-tier (rich client), 3-tier (thin client)
Notification: Publish/subscribe
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 4 / 66
Outline
1 Network-Centred Style
2 Service Architectures
3 GUI Architectures
4 Distributed Architectures
5 Heterogeneous Architectures
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 5 / 66
Network-Centred Style
Client-Server
Basic concept:
The client uses a service
The server provides a service
The service can be any resource
E.g. data, file, CPU, display device
Typically connected via a network
Clients are independent from each other
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 6 / 66
Network-Centred Style
Client-Server
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 7 / 66
Network-Centred Style
Client-Server
The server provide 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
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 8 / 66
Network-Centred Style
Client-Server
Separation of concerns (SoC)
Functionality is clearly split into separate components
Also motivation for the layered architecture style, where each layer isresponsible for its own abstraction
Aspect oriented programming tries to separate cross-cutting concernsinto separate modules
Supports independent evolvability
If the communication between client and server is well designed
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 9 / 66
Network-Centred Style
Client-Server
Client-server pattern is used by other architectural styles
It can be used to realise a shared repository
E.g. for the data-centric repository pattern
E.g. for filters which operate on a single shared data structure
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 10 / 66
Network-Centred Style
Client-Server - Shared Repository
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 11 / 66
Network-Centred Style
Client-Server
Two basic types of topology of the server
Single, centralised server or
Multiple, distributed servers
Centralised servers are easier to administer (install, deploy updates,maintain, monitor, ...)
Distributed servers scale better, but could introduce complexity (e.g.require two-phase commits)
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 12 / 66
Network-Centred Style
Client-Server - Centralised
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 13 / 66
Network-Centred Style
Client-Server - Distributed
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 14 / 66
Network-Centred Style
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
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 15 / 66
Network-Centred Style
Client-Server - Scalability
Scaling vertically if often the only option
Especially if the system has not been designed from the ground up toallow distributed processing
Scaling vertically is easier in a virtual environment (virtual machinesinstead of physical)
Because the system could be transferred to a more meatier machine,without the system knowing
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 16 / 66
Network-Centred Style
Client-Server - Scalability
Scaling horizontally should provide a high upper limit for scalability
Needs support from the system, not every system allows beingdistributed
Might lead to a high communication overhead due to synchronisationbetween the nodes
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 17 / 66
Network-Centred Style
Client-Server - Scalability
Distributed servers need to be specifically designed to allow scalinghorizontally
Will be typically more effort to develop
Upgrading to a bigger machine might be cheaper
Which strategy (scale up or scale out) is more suitable, depends onthe actual system.
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 18 / 66
Network-Centred Style
Client-Server
Stateful vs. stateless
If the client-server communication is stateful, the server keeps trackof the application state
Typically provides a handle or a session id
The client then may manipulate the state on the server, e.g.
Open file (returns file handle)Append lineClose file
Easier for the clients, as they not need to manage the state ⇒ neededif coupled with thin clients
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 19 / 66
Network-Centred Style
Client-Server
If the client-server communication is stateless, the client is responsibleto keep track of the application state
The server does not need to store or manage session specific data ⇒typically coupled with rich clients
Therefore the scalability of stateless servers are better than stateful
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 20 / 66
Network-Centred Style
Client-Server - cloud computing
The server is no longer in the organisations network, but somewherein the Internet
Example: cloud services by Salesforce, Google, Microsoft
Scalability, security, reliability is expected to be handled by aspecialised team
Loss of control, legal issues (data is exported to another country)
Needs a working Internet connection
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 21 / 66
Network-Centred Style
Client-Server - advantages
Conceptually simple
Clear separation of responsibilities, eases evolvability, help testability
Good scalability (if stateless)
Excellent scalability (if server can be scaled out)
Good for security, as data can be held at the server with restrictedaccess
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 22 / 66
Network-Centred Style
Client-Server - disadvantages
Risk of bad usability/performance, if the communication betweenclient 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
Integrability into existing systems might not be possible (e.g. if thecommunication is not possible, or not allowed)
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 23 / 66
Network-Centred Style
Peer to peer
Separation between client and server is removed
Each client is a server at the same time, called peer
The goal is to distribute the processing or data among many peers
No central administration or coordination
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 24 / 66
Network-Centred Style
Peer to peer
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 25 / 66
Network-Centred Style
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)
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 26 / 66
Network-Centred Style
Peer to peer
Once a peer is initialised, it needs to be come part of the network
A bootstrapping mechanism is needed:
For example via a broadcast message
For example a public list of network addresses
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 27 / 66
Network-Centred Style
Peer to peer - centralised P2P
Some aspects are centralised
For example, a central component keeps track of the available peers
⇒ Centralised peer to peer
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 28 / 66
Network-Centred Style
Peer to peer - hybrid P2P
Not all peers are equal, some have additional responsibilities
They are called supernodes
⇒ Hybrid peer to peer
Example: Skype uses a peer-to-peer protocol, but also usessupernodes and a central login servers
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 29 / 66
Network-Centred Style
Peer to peer - advantages
Good for scalability
Good for reliability, as data can be replicated over peer
No single point of failure
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 30 / 66
Network-Centred Style
Peer to peer - disadvantages
Quality of service is not deterministic, cannot be guaranteed
Very complex, hard to maintain and test
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 31 / 66
Service Architectures
Remote invocation and service architectures
Remote invocation architectures involve distributed processingcomponents
Typically, a client component invokes a method (function) on aremote component
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 32 / 66
Service Architectures
Remote invocation and service architectures
Advantages: increased performance through distributed computation
Only if network is reliable and fast and the communication overheadis manageable
Disadvantages: tightly coupling of components
Managing of addressability (recollect unique identity of objects)increases communication overhead
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 33 / 66
Service Architectures
Remote invocation and service architectures
Service architectures introduce a special component where servicesare registered
Any component interested in a service asks that component for theaddress of the service
It tries to solve the addressability problem
If communication protocols are standardized then services can beintegrated on-the-fly
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 34 / 66
Service Architectures
Remote invocation and service architectures
Web services
Use Web protocols for communication
However, the addressability is still not managed because you have toknow how to address objects in a remote service
Web services are in essence only remote procedure calls using Webprotocols
Same advantages and disadvantages apply
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 35 / 66
Service Architectures
Broker
Separate communication from the application functionality
Support for distributed systems
The broker hides the communication from the components of thesystem
The broker coordinates the communication
For example: The client interacts with a remote object via a broker
Note: Similar to the proxy design pattern
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 36 / 66
Service Architectures
Broker
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 37 / 66
Service Architectures
Broker - tasks of a broker
The task of the broker is to:
Find 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
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 38 / 66
Service Architectures
Broker - relationship to other patterns
The broker pattern has relationships with other patterns
E.g. the broker can be implemented as separate layer
E.g. the broker uses a client/server infrastructure
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 39 / 66
Service Architectures
Broker - advantages
Decoupling of components (the networking aspect)
Helps flexability, maintainability and evolvability
Allows a system to be distributed, even if it has not been designed forthis in the first place
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 40 / 66
Service Architectures
Broker - disadvantages
Network communication might introduce new types of errors
Due to network latencies and limited bandwidth the behaviour mightchange
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 41 / 66
Service Architectures
Interceptor - overview
Motivation: Separate functionality into a separate component
Allow integration of additional services without changing the corecomponents
Interface provided by a component, which allows another componentto register itself
And be invoked at specific events
Open-closed design principle (open for extension, but closed formodifications)
Used to address cross-cutting concerns
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 42 / 66
Service Architectures
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
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 43 / 66
Service Architectures
Interceptor - example
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 44 / 66
Service Architectures
Interceptor - advantages
Interceptor components can be reused
Clear separation of concerns, loose coupling ⇒ maintainability,evolvability
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 45 / 66
Service Architectures
Interceptor - disadvantages
Can get quite complex quickly
Potential cascading callbacks, endless loops
Core components need to provide the callback interface
May lead to bad testability
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 46 / 66
GUI Architectures
Model View Controller (MVC)
Motivation: reusability and separation of concerns
Three roles: model, view & controller
Model: encapsulates the behaviour and data of the applicationdomain
View: renders the model for presentation
Controller: Reacts on user input, modifies the model and dispatchesto the view
Both, controller and view, depend on the model
Controller and view are part of the UI
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 47 / 66
GUI Architectures
Model View Controller (MVC)
MVC is often used for web applications
Many existing frameworks:
JavaServer Faces (JSF), Struts, CakePHP, Django, Ruby on Rails, ...
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 48 / 66
GUI Architectures
Interceptor - example
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 49 / 66
GUI Architectures
MVC - Model
The model:
Encapsulates the application state
Response to state queries
Exposes application functionality
Notify view of changes
Note: Nofication only necessary, if the model and view realise anobserver pattern
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 50 / 66
GUI Architectures
MVC - View
The view:
Renders the model
Requests updates from model
Prepares the user interface for the controller
Usually multiple views
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 51 / 66
GUI Architectures
MVC - Controller
The controller:
Defines application behaviour
Manipulates the model
Selects view for response
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 52 / 66
GUI Architectures
MVC - Relationships
The model-view-controller pattern does not replace a n-tierarchitecture
Model is part of the n-tier pattern and the MVC pattern
The model communicates with lower abstraction layers (e.g. dataaccess layer)
The model might use a notification pattern to inform the view ofchanges
The lesser known presentation-abstraction-control pattern is similar toMVC
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 53 / 66
GUI Architectures
MVC - Advantages
Separation of concerns, helps reusability
Multiple different user interfaces without changes to the model
Helps configurability (as interface changes are easier, with lessexpected side effects than changes to the application logic)
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 54 / 66
GUI Architectures
MVC - Disadvantages
Increases the complexity by additional components
If updates to the view are based on notifications, it might be hard tofind errors
In this cases, it is hard to ensure a good usability (no control when anupdate happens)
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 55 / 66
Distributed Architectures
Share-Nothing-Architecture
No centralised data storage
Can scale almost infinitely
Used since the beginning of the 80ies
Popularised by Google
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 56 / 66
Distributed Architectures
Sharding
Split the data horizontally
Each node in a network may manage a separate chunk of the data
For example in web search engines
Each node is responsible for a number of web-pages
Returns search results from the local collection
All results from all shards are then combined into a single result
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 57 / 66
Distributed Architectures
Sharding - example
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 58 / 66
Distributed Architectures
Sharding
Need redundancy, in case a node goes down
Level of redundancy depends on the data
E.g. if a node with low-traffic web-pages goes down, it might noteven have an impact on the quality of the search results (at least onthe first page)
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 59 / 66
Heterogeneous Architectures
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 heterogeneous
N-tier architectures are layered architectures
N-tier architectures are typically data-centric architectures
Thin clients involve some sort of notification architecture
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 60 / 66
Heterogeneous Architectures
Heterogeneous architectures
Architectures might be structurally heterogeneous
Overall 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
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 61 / 66
Heterogeneous Architectures
Heterogeneous architectures
Architectures might be heterogeneous at execution level
At execution level components follow different styles
E.g. notification architectures might include remote procedure calls ifcomponents are distributed
Service architectures require networking architecture which is alayered architecture, etc..
In real systems architectures are heterogeneous at all levels!
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 62 / 66
Heterogeneous Architectures
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, ...
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 63 / 66
Heterogeneous Architectures
Example: Google search engine architecture
Figure: Google architecture
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 64 / 66
Heterogeneous Architectures
Example: Google search engine architecture
Crawlers: multiple and distributed
I.e. you have layered, service-oriented, notification
URLServer notifies and syncronizes crawlers ehat URLs to fetch
Web pages fetched and stored in storeserver
Storeserver: data-centric architecture
The searcher runs as a Web server
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 65 / 66
Heterogeneous Architectures
Conclusion
Architectural styles provide patterns
Why one should know these styles?
They provide a common vocabulary
They provide blueprints on how a system can be designed
Denis Helic, Roman Kern (KMI, TU Graz) Architectural Styles II Nov 21, 2012 66 / 66