2 Architectures: 2.1 Architectural Styles
2 Architectures: 2.1 Architectural Styles
Architectures
Architectures
Architectural styles
Software architectures
Architectures versus middleware
Self-management in distributed systems
2.1
Architectural styles
Architectural styles
Basic idea
Organize into logically different components, and distribute those components over the various machines.
Layer N
Object
Object
Layer N-1
Method call
Object
Request
flow
Response
flow
Object
Layer 2
Object
Layer 1
(a)
(b)
Architectural Styles
Observation
Decoupling processes in space (anonymous) and also time (asynchronous) has led to
alternative styles.
Component
Component
Event delivery
Component
Component
Publish
Data delivery
Event bus
Publish
Component
(a)
(b)
2.2
System Architectures
Centralized Architectures
Basic ClientServer Model
Characteristics:
There are processes offering services (servers)
There are processes that use services (clients)
Clients and servers can be on different machines
Clients follow request/reply model wrt to using services
Wait for result
Client
Request
Reply
Server
Provide service
Time
Application Layering
Traditional three-layered view
User-interface layer contains units for an applications user interface
Processing layer contains the functions of an application, i.e. without specific
data
Data layer contains the data that a client wants to manipulate through the application components
Observation
This layering is found in many distributed information systems, using traditional
database technology and accompanying applications.
Application Layering
User-interface
level
User interface
Keyword expression
HTML page
containing list
HTML
generator
Query
generator
Database queries
Database
with Web pages
Ranked list
of page titles
Processing
level
Ranking
algorithm
Web page titles
with meta-information
Data level
Multi-Tiered Architectures
Single-tiered: dumb terminal/mainframe configuration
Two-tiered: client/single server configuration
Three-tiered: each layer on separate machine
Traditional two-tiered configurations:
Client machine
User interface
User interface
User interface
User interface
User interface
Application
Application
Application
Database
User interface
Application
Application
Database
Database
Application
Database
Database
Database
(d)
(e)
Server machine
(a)
(b)
(c)
Decentralized Architectures
Observation
In the last couple of years we have been seeing a tremendous growth in peer-to-peer
systems.
Structured P2P: nodes are organized following a specific distributed data structure
Unstructured P2P: nodes have randomly selected neighbors
Hybrid P2P: some nodes are appointed special functions in a well-organized
fashion
Note
In virtually all cases, we are dealing with overlay networks (i.e. a network where
the nodes are the procs & the links are the communication channels) : data is routed
over connections setup between the nodes (cf. application-level multicasting)
Structured P2P Systems
Basic idea
Organize the nodes in a structured overlay network such as a logical ring, and make
specific nodes responsible for services based only on their ID.
Actual node
15
14
{13,14,15}
{0,1}
2
3
13
12 {8,9,10,11,12}
{2,3,4}
Associated
data keys
11
10
{5,6,7}
9
Note
The system provides an operation LOOKUP(key) that will efficiently route the
lookup request to the associated node.
Structured P2P Systems
Details of Chord Algorithm
Assign a random key to data item & a random number to node in system from
identifier space,
Implement an efficient & deterministic system to map a data item to a node based
on some distance metric,
LOOKUP(key) returning network address of node responsible for that data
item,
Do this by routing a request for the data item to responsible node.
Note
The Chord Algorithm will be described more fully later in the course.
Structured P2P Systems
Other example
Organize nodes in a d-dimensional space and let every node take the responsibility
for data in a specific region. When a node joins split a region.
(1,1)
(0.9,0.9)
(0.9,0.9)
(0.2,0.8)
(0.2,0.8)
(0.6,0.7)
Actual node
(0.6,0.7)
(0.9,0.6)
(0.9,0.6)
(0.2,0.45)
(0.2,0.3)
(0.7,0.2)
(0.7,0.2)
(0.2,0.15)
(0,0)
(1,0)
(a)
(b)
Structured
overlay
Protocol for
specific
overlay
Random peer
Random
overlay
Protocol for
randomized
view
Links to randomly
chosen other nodes
Note
Lower layer feeds upper layer with random nodes; upper layer is selective when it comes to
keeping references.
Time
Superpeers
Observation
Sometimes it helps to select a few nodes to do specific work: superpeer.
Regular peer
Superpeer
Superpeer
network
Examples
Peers maintaining an index (for search)
Peers monitoring the state of the network
Peers being able to setup connections
Client
Content provider
ISP
ISP
Core Internet
Edge server
Enterprise network
Lookup(F)
A BitTorrent
Web page
Web server
Ref. to
file
server
.torrent file
for F
Ref. to
tracker
List of nodes
storing F
File server
Tracker
Node 2
Node N
Basic idea
Once a node has identified where to download a file from, it joins a swarm of
downloaders who in parallel get file chunks from the source, but also distribute these
chunks amongst each other.
2.3
Client application
Intercepted call
B.do_something(value)
Application stub
Request-level interceptor
Nonintercepted call
invoke(B, &do_something, value)
Object middleware
Message-level interceptor
Local OS
To object B
Adaptive Middleware
Separation of concerns: Try to separate extra functionalities and later weave them
together into a single implementation only toy examples so far.
Computational reflection: Let a program inspect itself at runtime and adapt/change
its settings dynamically if necessary mostly at language level and applicability
unclear.
Component-based design: Organize a distributed application through components
that can be dynamically replaced when needed highly complex, also many
intercomponent dependencies.
Fundamental question
Do we need adaptive software at all, or is the issue adaptive systems?
2.4
10
Self-*
Warning
There is a lot of hype going on in this field of autonomic computing.
Feedback Control Model
Observation
In many cases, self-* systems are organized as a feedback control system.
Uncontrollable parameters (disturbance / noise)
Initial configuration
Corrections
+/-
+/-
Observed output
+/Reference input
Adjustment
measures
Metric
estimation
Analysis
Measured output
Adjustment triggers
Example: Globule
Globule
Collaborative CDN that analyzes traces to decide where replicas of Web content
should be placed. Decisions are driven by a general cost model:
cost = (w1 m1 ) + (w2 m2 ) + + (wn mn )
Example: Globule
Client
Origin server
ISP
ISP
Core Internet
Replica server
Enterprise network
Client
Client
Globule origin server collects traces and does what-if analysis by checking what
would have happened if page P would have been placed at edge server S.
Many strategies are evaluated, and the best one is chosen.