Architectures: Architectural styles

Architectural styles

Distributed Systems Basic idea

(3rd Edition) A style is formulated in terms of
(replaceable) components with well-defined interfaces
the way that components are connected to each other
Maarten van Steen Andrew S. Tanenbaum the data exchanged between components
how these components and connectors are jointly configured into a
system.

Chapter 02: Architectures Connector

A mechanism that mediates communication, coordination, or cooperation
Edited by: Hicham G. Elmongui among components. Example: facilities for (remote) procedure call,
messaging, or streaming.

2 / 28

Architectures: Architectural styles Layered architectures Architectures: Architectural styles Layered architectures

Layered architecture Example: communication protocols

Different layered organizations

Request/Response Protocol, service, interface
downcall One-way call
Party A Party B

Layer N Layer N Layer N

Layer N Layer N

Layer N-1 Layer N-1 Layer N-1 Interface Service

Handle
Upcall
Layer N-2 Layer N-1
Layer N-2 Layer N-1
Protocol
Layer 2
Layer N-3

Layer 1

(a) (b) (c)

3 / 28 Layered communication protocols 4 / 28

Architectures: Architectural styles Layered architectures Architectures: Architectural styles Layered architectures

Application Layering Application Layering

Example: a simple search engine

Traditional three-layered view
Application-interface layer contains units for interfacing to users or User interface
User-interface
level
external applications
Processing layer contains the functions of an application, i.e., without HTML page
containing list
Keyword expression
specific data
HTML
Data layer contains the data that a client wants to manipulate through the generator Processing
application components Query Ranked list level
generator of page titles
Ranking
Database queries algorithm
Observation
This layering is found in many distributed information systems, using traditional Web page titles
with meta-information
database technology and accompanying applications. Database
with Web pages
Data level

Application layering 5 / 28 Application layering 6 / 28

Architectures: Architectural styles Object-based and service-oriented architectures Architectures: Architectural styles Object-based and service-oriented architectures

Object-based style Object-based style

Essence Distributed Objects

Components are objects, connected to each other through procedure calls. The separation between interfaces and their implementing objects allows us to
Objects may be placed on different machines; calls can thus execute across a place an interface at one m/c, while the object itself resides on another m/c.
network.
Client machine Server machine

State Object
Object Object Client Server
State
Method Same
Method call interface Method
Object Client
invokes as object
Object a method
Skeleton
Object Interface
Interface invokes
Proxy same method Skeleton
at object
Client OS Server OS
Encapsulation
Objects are said to encapsulate data and offer methods on that data without
Network
revealing the internal implementation. Marshalled invocation
is passed across network

7 / 28 8 / 28

Architectures: Architectural styles Resource-based architectures Architectures: Architectural styles Resource-based architectures

RESTful architectures Example: Amazon’s Simple Storage Service

Essence
View a distributed system as a collection of resources, individually managed by
Essence
components. Resources may be added, removed, retrieved, and modified by
(remote) applications. Objects (i.e., files) are placed into buckets (i.e., directories). Buckets cannot be
placed into buckets. Operations on ObjectName in bucket BucketName require
1 Resources are identified through a single naming scheme the following identifier:
2 All services offer the same interface
3 Messages sent to or from a service are fully self-described http://BucketName.s3.amazonaws.com/ObjectName
4 After executing an operation at a service, that component forgets
everything about the caller Typical operations
All operations are carried out by sending HTTP requests:
Basic operations
Operation Description
Create a bucket/object: PUT, along with the URI
Listing objects: GET on a bucket name
PUT Create a new resource
Reading an object: GET on a full URI
GET Retrieve the state of a resource in some representation
DELETE Delete a resource
POST Modify a resource by transferring a new state

9 / 28 10 / 28

Architectures: Architectural styles Resource-based architectures Architectures: Architectural styles Resource-based architectures

On interfaces On interfaces

Issue Simplifications
Many people like RESTful approaches because the interface to a service is so Assume an interface bucket offering an operation create, requiring an input
simple. The catch is that much needs to be done in the parameter space. string such as mybucket, for creating a bucket “mybucket.”

Amazon S3 SOAP interface SOAP

Bucket operations Object operations import bucket
bucket.create("mybucket")
ListAllMyBuckets PutObjectInline
CreateBucket PutObject
DeleteBucket CopyObject RESTful
ListBucket GetObject
PUT "http://mybucket.s3.amazonsws.com/"
GetBucketAccessControlPolicy GetObjectExtended
SetBucketAccessControlPolicy DeleteObject
GetBucketLoggingStatus GetObjectAccessControlPolicy Conclusions
SetBucketLoggingStatus SetObjectAccessControlPolicy Are there any to draw?

11 / 28 12 / 28
Architectures: Architectural styles Publish-subscribe architectures Architectures: Middleware organization Wrappers

Coordination Using legacy to build middleware

Temporal and referential coupling
Temporally Temporally
coupled decoupled
Referentially Direct Mailbox
Problem
coupled
Referentially Event- Shared The interfaces offered by a legacy component are most likely not suitable for all
decoupled based data space applications.

Event-based and Shared data space Solution

A wrapper or adapter offers an interface acceptable to a client application. Its
Component Component Component Component functions are transformed into those available at the component.
Subscribe Notification
Publish Subscribe Data
delivery
delivery
Event bus

Publish

Component
Shared (persistent) data space

13 / 28 14 / 28

Architectures: Middleware organization Wrappers Architectures: Middleware organization Interceptors

Organizing wrappers Developing adaptable middleware

Two solutions: 1-on-1 or through a broker

Wrapper

Application Broker Problem

Middleware contains solutions that are good for most applications ⇒ you may
want to adapt its behavior for specific applications.

Complexity with N applications

1-on-1: requires N × (N − 1) = O(N 2 ) wrappers

broker: requires 2N = O(N) wrappers

15 / 28 16 / 28

Architectures: Middleware organization Interceptors Architectures: Middleware organization Modifiable middleware

Intercept the usual flow of control Developing modifiable middleware

The middleware is responsible for reacting to the continuous changes in

Intercepted call
Client application
the environment.
B.doit(val)
The increasing size of a distributed system mandates that changing
Application stub its parts be done on-the-fly.
Request-level interceptor Nonintercepted call The middleware may not only need to be adaptive, but we should be able
to purposefully modify it without bringing it down.
invoke(B, &doit, val)
Interceptors offer a means to adapt the standard flow of control.
Object middleware Replacing software components at runtime is an example of
modifying a system.
Message-level interceptor
Dynamically constructing middleware from components.
send(B, “doit”, val) Component-based design focuses on supporting modifiability through
composition.
Local OS
A system may either be configured statically at design time, or
To object B
dynamically at runtime.

17 / 28 18 / 28
Architectures: System architecture Centralized organizations Architectures: System architecture Centralized organizations

Centralized system architectures Multi-tiered centralized system architectures

Some traditional organizations
Basic Client–Server Model Single-tiered: dumb terminal/mainframe configuration
Two-tiered: client/single server configuration
Characteristics:
Three-tiered: each layer on separate machine
There are processes offering services (servers)
There are processes that use services (clients) Traditional two-tiered configurations
Clients and servers can be on different machines Client machine
Clients follow request/reply model with respect to using services User interface User interface User interface User interface User interface

Client Server Application Application Application

Database
Request

Wait Provide service User interface

Reply Application Application Application
Database Database Database Database Database

Server machine
(a) (b) (c) (d) (e)
Simple client-server architecture 19 / 28 Multitiered Architectures 20 / 28

Architectures: System architecture Centralized organizations Architectures: System architecture Decentralized organizations: peer-to-peer systems

Being client and server at the same time Alternative organizations

Vertical distribution
Three-tiered architecture Comes from dividing distributed applications into three logical layers, and
running the components from each layer on a different server (machine).
Client Application Database
server server
Request
operation
Request
Horizontal distribution
data A client or server may be physically split up into logically equivalent parts, but
Wait for
reply
Wait for
data
each part is operating on its own share of the complete data set.
Return
Return
data Peer-to-peer architectures
reply
Processes are all equal: the functions that need to be carried out are
represented by every process ⇒ each process will act as a client and a server
at the same time (i.e., acting as a servant).

Multitiered Architectures 21 / 28 22 / 28

Architectures: System architecture Decentralized organizations: peer-to-peer systems Architectures: System architecture Decentralized organizations: peer-to-peer systems

Structured P2P Unstructured P2P

Essence
Make use of a semantic-free index: each data item is uniquely associated with Essence
a key, in turn used as an index. Common practice: use a hash function Each node maintains an ad hoc list of neighbors. The resulting overlay
key(data item) = hash(data item’s value). resembles a random graph: an edge hu, v i exists only with a certain probability
P[hu, v i].
P2P system now responsible for storing (key,value) pairs.

Simple example: hypercube Searching

Flooding: issuing node u passes request for d to all neighbors. Request
0000
is ignored when receiving node had seen it before. Otherwise, v searches
0001 1001
1000
0010 0011
1010
1011 locally for d (recursively). May be limited by a Time-To-Live: a maximum
number of hops.
0100
Random walk: issuing node u passes request for d to randomly chosen
0101 1101
1100
0110 0111
1110
1111 neighbor, v . If v does not have d, it forwards request to one of its
randomly chosen neighbors, and so on.
Looking up d with key k ∈ {0, 1, 2, . . . , 24 − 1} means routing request to node
with identifier k .
Structured peer-to-peer systems 23 / 28 Unstructured peer-to-peer systems 24 / 28
Architectures: System architecture Decentralized organizations: peer-to-peer systems Architectures: System architecture Hybrid Architectures

Super-peer networks Edge-server architecture

Essence
It is sometimes sensible to break the symmetry in pure peer-to-peer networks: Essence
When searching in unstructured P2P systems, having index servers Systems deployed on the Internet where servers are placed at the edge of the
improves performance network: the boundary between enterprise networks and the actual Internet.
Deciding where to store data can often be done more efficiently through
brokers. Client Content provider

ISP
ISP

Super peer
Core Internet
Overlay network of super peers
Edge server
Enterprise network
Weak peer

Hierarchically organized peer-to-peer networks 25 / 28 Edge-server systems 26 / 28

Architectures: System architecture Hybrid Architectures Architectures: Example architectures The Network File System

Collaboration: The BitTorrent case The Network File System (NFS) for Unix Systems
Remote file service - Remote access model
Principle: search for a file F
Transparent access to a file system managed by a remote server.
Lookup file at a global directory ⇒ returns a torrent file Clients are unaware of actual location of files.
Torrent file contains reference to tracker: a server keeping an accurate
account of active nodes that have (chunks of) F . Client Server
P can join swarm, get a chunk for free, and then trade a copy of that
chunk for another one with a peer Q also in the swarm. System call layer System call layer

Virtual file system Virtual file system

Client node (VFS) layer (VFS) layer
K out of N nodes
Local file Local file
Lookup(F) Node 1 system interface NFS client NFS server system interface

A BitTorrent List of nodes Node 2

Web page or torrent file RPC client RPC server
with (chunks of)
search engine for file F stub stub
file F
Web server File server Tracker
Node N

Network

Collaborative distributed systems 27 / 28 28 / 28