22. Execution View
Focuses on the system runtime structure
Hardware elements, subsystems, processes and threads
Suited for examining quality attributes, most-notablyruntime
attributes
E.g. performance, security, usability,...
But also e.g. scalability
Similarly to conceptual architecture comprised of components and
connectors
23. Components in execution architecture
Concurrent components (abstraction created by execution of a
software program)
If the system is a single-computer, single-process, single-thread
system then the execution architecture is very simple
Figure: The simplestexecution architecture
24. Connectors inexecution architecture
Connectors indicate that one component calls another
The arrow depicts the call direction
The arrow head points from the calling component to the called
component
Three different types of arrows for three different calling scenarios
25. Connectors inexecution architecture
Synchronouscommunication: the calling components waits for a
response of the calledcomponent
Asynchronous communication: the calling component does notwait
for a response
Callback: The calling component receives a response asynchronously
by setting a means by which the called component can send response
later
27. Conceptual vs. Execution arch.
Element Conceptual Execution
Components Domain-level responsibilities Unit of concurrentactivity
Connectors Information flow Invocation
Views Single Multiple
28. Concurrent subsystemsmodel
Top-level execution model
To get an overview of the running system
Subsystems can be quite complex and have many processes and/or
threads
However, a concurrent subsystem is not something that is clearly
defined
In some cases it is clear
29. Process model
• Restricting a concurrency model to processes
depicts the execution structure
• Basically, you examine each concurrent
subsystem for processes You do not go into
details on external systems
• Typically, such models will be only slightly
more detailed than concurrent subsystem
models
31. Execution behaviour
Wewill use-case maps to model behaviour
Actually we need only to verify that execution architecture supports
the desired behaviour
→ find errors in the architecture
Wecan use the same use-case maps from the conceptual architecture
33. ImplementationArchitecture
Focuses on how the system is built
Which technological elements are needed to implement the system
Software packages, libraries, frameworks, classes, ...
Addresses non-runtime requirements &quality attributes:
configurability, testability, reusability, ...
Comprised of components and connectors
34. ImplementationArchitecture
Components and connectors reflect software entities and their
relationships at the level of source and binary code
Typically a number of implementation models
Each model focuses on one of the concurrent subsystems or processes
from the execution view
36. Components
Application components
... are responsible for implementing domain-level responsibilities
These are responsibilities found in a detailed conceptual architecture
Application components might be realized as binary packages, source
packages, andfiles
37. Components
Infrastructure components
... are needed to make the system run but are not related to the
application functionality
E.g. HTTP Connection Handler in our sample is a typical infrastructure
component
Whether a particular component is an application or an infrastructure
component depends on the application
E.g. if we are building a Web application server then HTTP Connection
Handler is an application component
45. Behaviordesign
Now we need to go into details
Use-case maps are too high level here
Weneed to investigate behaviour at the operation level
Thus, we need for example sequence diagrams
Still, use-case maps might be used to analyse e.g. runtime attributes
47. Prototype
Toshow that the architectural solution is feasible we implement
prototypes
For each identified application component we provide
implementation
Deploy it within the infrastructure components
Test it and check correctness, functionality, quality-attributes
Two types of prototypes: technical and executable
48. Mock-Ups
Mock-ups are special technical prototypes, especially for user
interfaces
Serve as the communication tool with the stakeholders (and within
the team)
Should give an overview on how the system will look like
But does not contain any functionality
There are specialised tools to create mock-ups
49. 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
50. Classification of styles
1 Data-flow architectures
Data-centered architectures
Abstraction layer architectures
N-tier architectures
Notification architectures
Remote invocation and service architectures
Heterogeneous architectures
2
3
4
5
6
7
51. 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
E.g. UNIX command line pipes
In pipe and filters style steps might run concurrently processing
parts of data incrementally
52. Pipes and filters
Data flows through pipes: communication channels between filters
Processing units: filters
Depending on where the filters reside different types of execution
architectures might apply
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
53. 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
54. 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. insertdata)
Blackboard: the system sends notification and data to subscribers
when data of interest changes, and is thus active
57. 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,...
58. 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 notablyabstraction
59. 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
60. 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
61. 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)
62. 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 inGUIs
64. Peer topeer
Separation between client and server is removed
Eachclientisaserveratthesametime,calledpeer
Thegoalistodistributetheprocessing or data amongmanypeers
Nocentraladministrationorcoordination
70. Distributed Architectures
Parallel computing vs. distributedcomputing
In parallel computing all component share a common memory,
typically threads within a single program
In distributed computing each component has it own memory
▶ Typically in distributed computing the individual componentsare
connected over anetwork
▶ Dedicated programming languages (or extensions) forparallel
computing
71. Distributed Architectures
Distributed architectures
Most complex solution
▶ Due to the added parallelism of data and processing
▶ And therefore an increased risk oferrors
Overall latency will be the the one of the slowest machine
▶ I.e. latency cannot be decreased via distributedsolutions
Therefore the architecture needs to be sound
... focus on abstraction andcomposition
Note: In practice people are often biased towards technologies they know (e.g. SQL)
72. Distributed ArchitecturesBasics
Number of issues toaddress
1 Serialisation
Group membership
Leader election
Distributed locks
Barriers
Shared resources
Configuration
73. Asynchronous Architectures -Motivation
Synchronous architectures
Each call terminates after the request has been completely processed
E.g. traditional data-centric architectures (databases)
Pro: Easy to use and predictivebehaviour
Con: Does not deal well with load (need to plan with the worst case)
Asynchronous architectures
The call returns before the request has been processed
The processing happens in the background
Con: Non predictive behaviour
Pro: Load can be distributed over time, thus better scalability
75. Asynchronous Architectures - Queue&Worker
Asynchronous queue & worker architecture
The client puts the request into the queue, the workers poll the queue for
requests
76. Asynchronous Architectures - StreamProcessing
Two basic stream processing types
One-at-a-time
▶ Each event is processedindividually
Micro-batch
▶ Multiple events are combined into a single batch
78. Kappa Architecture -Motivation
Basic idea behind Kappa Architecture
The Lambda Architecture is relatively complex
Most of the problems can be solved via a streaming approach
→ treat the batch processing as if it were a stream of data
▶ Have the framework optimise for the two cases (stream vs. batch)
http://www.kappa-architecture.com/
80. Motivation forMicroservices
Traditional service architectures
Services have oftenbeen used to decouple the UI from the server components
Services have been envisioned to provide high level functionality
Defined and coordinated interfaces versioned via schema (or something similar)
Microservices
Expose finer grained functionalities in form of services
Services are developed and deployed independently from each other
Use API versioning locally to handlechanges
83. • Scalable computing instances (AWS EC2)
• Scalable storage (AWS S3)
• Business logic microservices (purpose-built frameworks by
Netflix)
• Scalable distributed databases (AWS DynamoDB, Cassandra)
• Big data processing and analytics jobs (AWS EMR, Hadoop,
Spark, Flink, Kafka and other purpose-built tools by Netflix)
• Video processing and transcoding (purpose-built tools by
Netflix)
• Open Connect CDN is a network of servers called Open
Connect Appliances (OCAs)
Backend on AWS
