ICS362 – Distributed Systems

Dr. Ken Cosh

Week 2

Review

Introduction Goals of DS

– Available Resources– Transparency– Openness– Scalability

Types of DS– Computing Systems– Information Systems– Pervasive Systems

This Week

Architectures– Architectural Styles– System Architectures– Architectures vs Middleware

Software/System Architectures

Logical Organisation of components vs Physical Organisation

Design decisions– Centralised vs Decentralised Architectures– Middleware Layers– Adaptive Systems? (Autonomic Systems?)

Architectural Style

Essential for successful system development In this case: Interrelated Components and

Connectors– A component is a modular unit with well-defined

required and provides interfaces that is replaceable within its environment.

– A connector is a mechanism that mediates communication, co-ordination or co-operation between components.

Architectural Styles

Key styles for Distributed Systems– Layered Architectures– Object-based Architectures– Data-centered Architectures– Event-based Architectures

Layered Architectures

Components at layer Li are allowed to call components at underlying layers Li-1, but not the other way around.

Database Layer

Data Management Layer

Applications Layer

User Interface Layer

Requests Results

Object-based Architectures

Looser Organisation Each Object is a ‘component’ with required

and provides interface.

Object

Object

Object

Object

Object

Method Calls

Data-centred Architecture

Processes communicate through a common (passive or active) data repository.– E.g. Web based systems where processes

communicate through shared web-based data services.

Event-based Architectures

Processes communicate through event propagation– ‘Publish/Subscribe’ systems

Processes subscribed to events will receive them.

Benefit is components are loosely coupled;– i.e. they don’t need to explicitly refer to each

other.

System Architectures

Organising Systems based on placement of software components– Centralised Architectures– Decentralised Architectures– Hybrid Architectures

Centralised Architectures

Simply: Client Server Architectures– Easy way to understand & manage complexity in

DS

Server– Process implementing a particular service

Client– Process requesting the service and waiting for a

reply.

Request-Reply Behaviour

Client

Server

Request Reply

Provide Service

Wait for Result

Time

Message Reliability?

Reliable Connections?– Resend upon failure?

“Transfer $10,000 from my account” “How much money do I have”

– Idempotency: Operation can be repeated without harm

Connectionless vs Connection-oriented protocols?– Cost of setting up and maintaining a connection.

Client Server Architecture

What is a client? What is a server? – Can we really distinguish between the two?– What is the database server needs to request a

service from another file server? Nonetheless, essentially Client Server

architecture has 3 ‘layers’– User Interface Layer– Processing Layer– Data Layer

User Interface Layer

Growing sophistication– Text based screen– GUI, with menus etc.– Drag ‘n’ Drop interface– Ajax!

Processing Layer

Example: Web Search

User Interface

Database

QueryGenerator

RankingAlgorithm

HTMLGenerator

Data Layer

Data is persistent– When applications stop, the data doesn’t

A file-system? A database? Often responsible for data management;

– Security– Verification– Consistency

Thin and Fat Clients

Thin-client model – In a thin-client model, all of the application processing

and data management is carried out on the server. The client is simply responsible for running the presentation software.

Fat-client model – In this model, the server is only responsible for data

management. The software on the client implements the application logic and the interactions with the system user.

Thin and Fat Clients

Thin-clientmodel

Fat-clientmodel Client

Client

Server

Data managementApplicationprocessing

Presentation

Server

Datamanagement

PresentationApplication processing

Thin Client Model

Used when legacy systems are migrated to client server architectures. – The legacy system acts as a server in its own

right with a graphical interface implemented on a client

A major disadvantage is that it places a heavy processing load on both the server and the network

Fat Client Model

More processing is delegated to the client as the application processing is locally executed

Most suitable for new C/S systems where the capabilities of the client system are known in advance

More complex than a thin client model especially for management. New versions of the application have to be installed on all clients

A Client-server ATM System

Account server

Customeraccountdatabase

Tele-processing

monitor

ATM

ATM

ATM

ATM

Three-tier Architectures

In a three-tier architecture, each of the application architecture layers may execute on a separate processor

Allows for better performance than a thin-client approach and is simpler to manage than a fat-client approach

A more scalable architecture - as demands increase, extra servers can be added

A 3-tier C/S Architecture

Client

Server

Datamanagement

PresentationServer

Applicationprocessing

An Internet Banking System

Database server

Customeraccountdatabase

Web server

Client

Client

Client

Client

Account serviceprovision

SQLSQL query

HTTP interaction

Use of C/S Architectures

Architecture ApplicationsTwo-tier C/Sarchitecture withthin clients

Legacy system applications where separating applicationprocessing and data management is impracticalComputationally-intensive applications such as compilers withlittle or no data managementData-intensive applications (browsing and querying) with littleor no application processing.

Two-tier C/Sarchitecture withfat clients

Applications where application processing is provided byCOTS (e.g. Microsoft Excel) on the clientApplications where computationally-intensive processing ofdata (e.g. data visualisation) is required.Applications with relatively stable end-user functionality usedin an environment with well-established system management

Three-tier ormulti-tier C/Sarchitecture

Large scale applications with hundreds or thousands of clientsApplications where both the data and the application arevolatile.Applications where data from multiple sources are integrated

Server as Client

ApplicationServer

DatabaseServer

Request Reply

Provide Service

Wait for Data

Time

UserInterface

Wait for Result

Request Reply

Centralised vs Decentralised Architectures

Centralised Architectures– Vertical Distribution– Logical for many Business Environments

Decentralised Architectures– Horizontal Distribution– Client (or Server) split up into logically equivalent

parts where each part operates on its own share of the complete data set

– Peer-to-peer systems

Decentralised or Peer-to-peer Architectures

Each process acts as a client & a server (a servent).

How to logically organise the processes?– Through an overlay network

Nodes are processes & links are possible communication channels

– In general processes can’t just communicate with another process at will, instead they have to follow the available communication channels.

Structured Peer-to-peer Architectures

1 Common Option– Distributed Hash Table assigns each node and

each data item a random key.– Each data item is mapped to a node based on

distance.– Nodes (and hence their data items) can then be

stored in a linked list like structure.– Operations include;

Lookup, Join, Leave etc.

Structured Peer-to-peer Architectures

Alternative option– Data is assigned a location in a multi-dimensional

Cartesian co-ordinate space E.g. (0.3,0.4) in a 2 dimensional space.

– Nodes are then allocated regions of data to manage

When a node joins it divides another existing nodes region in two.

When a node leaves it’s region merges with a neighbour

Unstructured Peer-to-peer Architectures

Where data is effectively randomly allocated to nodes– Searching requires flooding the network.

When a node joins, it contacts an arbitrary node from a list of access points (highly available nodes)

Superpeers can maintain an index of data items to improve search

Superpeers

Peers connect to Superpeers who connect to a superpeer network.

Further challenges exist;– Which is the best superpeer for this peer to

connect with?– What happens when a superpeer leaves?– How do we decide which nodes become

superpeers?

Hybrid Architectures

Client Server solutions combined with decentralised architectures.– Edge Server Systems

E.g. Users connecting to an ISP which resides at the “edge” of the internet.

– Bit Torrent Trackers which keep an account of active nodes across

the decentralised network.

Middleware?

Software layer between applications and platforms providing distribution transparency

If middleware is molded to an architectural style, designing applications is easier– But then the middleware might be too bloated for

the application developer’s needs