Architetture
Organizzazione dei SD
• Distinzione: Organizzazione logica –
Realizzazione fisica
• Organizzazione logica: Architettura Software
• Organizzazione ed interazione delle varie
componenti software
• Classificazione
– Architetture Centralizzate
– Architetture Decentralizzate
– Architetture Ibride
D. Rosaci
Sistemi Distribuiti - Architetture
2
Obiettivo importante dei SD
• Separazione delle applicazioni dalle
piattaforme sottostanti (strato di
middleware)
• Garantire la trasparenza alla
distribuzione: il middleware deve
essere adattabile
• Varie tecniche per ottenere
l’adattabilità
D. Rosaci
Sistemi Distribuiti - Architetture
3
Stili Architetturali
• Si esprimono in termini di:
–
–
–
–
Componenti
Connessione dei componenti
Dati scambiati tra i componenti
Modalità di cofigurazione dei componenti
• Un componente è un’unità modulare con interfacce ben
definite e sostituibile nel suo ambiente
• Un connettore è un meccanismo che media la comunicazione
tra due componenti
• Quattro principali architetture
–
–
–
–
D. Rosaci
Architetture a livelli (layered)
Architetture basate sugli oggetti
Architetture centrate sui dati
Architetture basate sugli eventi
Sistemi Distribuiti - Architetture
4
Architetture basate su livelli
• I componenti sono organizzati a strati,
e ogni componente a livello i può
richiamare i componenti del livello
sottostante i-1. Le richieste scendono
lungo la gerarchia, mentre le risposte
risalgono
• Largamente adottato dalla comunità
della Rete (es. Architetture di Rete,
ISO-OSI, TCP/IP)
D. Rosaci
Sistemi Distribuiti - Architetture
5
Architetture basate su oggetti
• Ogni componente è un oggetto e gli
oggetti sono connessi attraverso un
meccanismo di chiamata a procedura
remota.
• Corrisponde all’architettura clientserver
• I grandi sistemi software sono
oggigiorno organizzati principalmente
a livelli e ad oggetti
D. Rosaci
Sistemi Distribuiti - Architetture
6
Architetture centrate sui dati
• Idea di base: i processi comunicano
attraverso un reppsitory comune.
• Sono state sviluppate un gran numero
di applicazioni in rete che si basano su
un file system distribuito condiviso, e
tutta la comunicazione ha luogo
attraverso dei file
• I sistemi distribuiti basati sul Web sono
spesso centrati sui dati
D. Rosaci
Sistemi Distribuiti - Architetture
7
Architetture basate sugli eventi
•
•
•
•
•
•
•
I processi comunicano attraverso la propagazione di eventi, che
facoltativamente trasportano anche dei dati
Politica PUBLISH/SUBSCRIBE
I processi possono pubblicare degli eventi, dopodichè il middleware
assicura che solo quei processi che si sono iscritti a quei determinati
eventi li ricevano
Sistemi blandamente accoppiati, disaccoppiati nello spazio, o
disaccoppiati referenzialmente (referentially decoupled)
Le architetture basate sugli eventi possono essere combinate con
quelle centrate sui dati, generando i cosiddetti spazi di dati
condivisi
Negli spazi di dati condivisi, i processi sono anche disaccoppiati nel
tempo: non è necessario che siano entrambi attivi quando la
comunicazione ha luogo
Molti spazi di dati condivisi utilizzano un’interfaccia tipo SQL per il
repository condiviso, rendendo così i dati accessibili attraverso una
descrizione anziché attraverso un riferimento esplicito
D. Rosaci
Sistemi Distribuiti - Architetture
8
Architetture di Sistema
• Domande:
– Quali componenti software usare?
– Come interagiscono i componenti?
– Dove sono posizionati i componenti?
–
• Tre tipologie:
– Architetture centralizzate
– Architetture decentralizzate
– Architetture ibride
D. Rosaci
Sistemi Distribuiti - Architetture
9
Architetture di Sistema
• Domande:
– Quali componenti software usare?
– Come interagiscono i componenti?
– Dove sono posizionati i componenti?
–
• Tre tipologie:
– Architetture centralizzate
– Architetture decentralizzate
– Architetture ibride
D. Rosaci
Sistemi Distribuiti - Architetture
10
Architetture Centralizzate
• Modello client-server
• Il server è un processo che
implementa uno specifico servizio (es.
File System, Base di Dati)
• Il client è un processo che richiede un
servizio a un server attendendone la
risposta (comportamento domandarisposta)
D. Rosaci
Sistemi Distribuiti - Architetture
11
Architetture Centralizzate:
Protocolli senza Connessione
• La comunicazione client-server può essere
implementata mediante un protocollo senza
connessione, nel caso di reti affidabili (LAN). In
questo caso, il client confeziona un messaggio
identificando il servizio richiesto ed i dati necessari,
mentre il server resta in attesa di messaggi, li
processa, e confeziona la risposta per il client.
• Vantaggio: efficienza.
• Svantaggio: in caso di malfunzionamenti, il client è
costretto a reinviare la richieste. Ma se l’originale
risposta si era solo persa, allora il server dovrà
effettuare più volte la stessa operazione (es.
trasferire 10000 $ dal proprio conto!)
D. Rosaci
Sistemi Distribuiti - Architetture
12
Architetture Centralizzate:
Protocolli con Connessione
• Possibilità alternativa: protocollo
affidabile, orientato alla connessione
• Vantaggio: i messaggi non si perdono
• Svantaggio: Il costo è elevato
• Adatto su rete globale, es. TCP/IP su
Internet
D. Rosaci
Sistemi Distribuiti - Architetture
13
Client-Server: Stratificazione
delle Applicazioni
• Livelli Logici del Software
– Livello dell’interfaccia utente
– Livello applicativo
– Livello dei dati
I due ultimi livelli possono essere
psoizionati sul client, sul server, o su
entrambi
• Si noti che i livelli fisici sono invece
solo due: il client ed il server
D. Rosaci
Sistemi Distribuiti - Architetture
14
Client-Server: Stratificazione
delle Applicazioni – Esempio 1
• Motore di ricerca sul Web
• Interfaccia (front-end):l’utente digita delle
keyword e gli viene ritornata una lista di
collegamenti
• Il livello dei dati (back-end) è costituito da
una vasta base di dati di pagine Web
prelevate e indicizzate
• Il livello applicativo (cuore del sistema) è un
programma che accetta in ingresso le
keywords e genera interrogazioni per la
base di dati del back-end
D. Rosaci
Sistemi Distribuiti - Architetture
15
Client-Server: Stratificazione
delle Applicazioni – Esempio 2
• Sistema di Supporto alle Decisioni per
una mediazione di mercato
• Front-End: Interfaccia Utente
• Back-End: Base di Dati con dati
finanziari
• Livello delle Applicazioni: Programmi di
Analisi Finanziaria
D. Rosaci
Sistemi Distribuiti - Architetture
16
Client-Server: Distribuzione del
Software – Alternativa 1
• Interfaccia utente sul client
• Programmi che implementano il livello
applicativo e il livello dati sul server
• Ogni aspetto è quindi gestito dal
server, mentre il client è solo uno
“stupido” terminale
D. Rosaci
Sistemi Distribuiti - Architetture
17
Client-Server: Distribuzione del
Software – Alternativa 2
• Interfaccia utente solo parzialmente sul
client. Sono presenti sul client solo gli
aspetti dipendenti dal terminale
• Le applicazioni (che stanno sul server
insieme ai dati) hanno il controllo
(remoto) sulla presentazione dei loro
dati
D. Rosaci
Sistemi Distribuiti - Architetture
18
Client-Server: Distribuzione del
Software – Alternativa 3
• L’interfaccia grafica e parte
dell’applicazione sono posizionate sul
client. Esempio: l’applicazione fa uso
di una form che deve essere compilata
prima di essere processata. La
compilazione potrebbe avvenire sul
client
• Sul server stanno le restanti
applicazioni e i dati
D. Rosaci
Sistemi Distribuiti - Architetture
19
Client-Server: Distribuzione del
Software – Alternativa 4
• L’interfaccia grafica e tutte le applicazioni
stanno sul client. Esempio: la macchina
client è un PC connesso con una base di
dati remota. E’ il caso delle applicazioni
bancarie, che spesso vengono eseguite
sulla macchina dell’utente finale, mentre il
server della banca serve solo da base di
dati.
• Sul server stanno quindi soltanto i dati
D. Rosaci
Sistemi Distribuiti - Architetture
20
Client-Server: Distribuzione del
Software – Alternativa 5
• L’interfaccia grafica, tutte le applicazioni e
parte dei dati stanno sul client. Esempio: la
macchina client è un PC connesso con una
base di dati remota. Ad esempio, navigando
sul Web un client può gradatamente
costruire una vasta cache sul disco locale
delle pagine visitate più di recente.
• Sul server stanno quindi soltanto la parte
restante dei dati
D. Rosaci
Sistemi Distribuiti - Architetture
21
Client-Server: Distribuzione del
Software – Tendenze Attuali
• Si cerca di evitare l’uso delle alternative 4 e 5 (Fat
Client).
• I fat client rende il software lato client più soggetto
ad errori e più dipendente dalla piattaforma del
client
• Più usate le alternative 1,2 e 3 (Thin Client)
• Si potrebbe pensare che questo significhi che non
vogliamo distribuire le risorse. In realtà, non
vogliamo distribuire le risorse sui client, e
preferiamo distribuire le risorse su più server. Per
far questo però il server deve poter agire anche da
client.
• In tal modo passiamo da architetture a due livelli
fisici ad architetture a tre livelli fisici
D. Rosaci
Sistemi Distribuiti - Architetture
22
Esempio di Architettura a 3 livelli
fisici
• Organizzazione di un Sito Web di ECommerce
• Il server Web opera come punto d’ingresso
al sito. Può contenere applicazioni come ad
esempio l’elaborazione di una richiesta di un
prodotto proveniente dal client (Application
Server).
• L’Application Server a sua volta interagisce
con un server di una base di dati (Database
Server)
D. Rosaci
Sistemi Distribuiti - Architetture
23
Architetture Decentralizzate
• Le architetture a tre livelli fisici prima
introdotto sono un esempio di distribuzione
verticale: componenti logicamente diversi
vengono posizionati su macchine diverse
• La distribuzione verticale è solo un modo di
organizzare le applicazioni client-server.
• Nelle architetture moderne si è invece più
interessati a come sono distribuiti i client ed
i server: distribuzione orizzontale
• Importante classe di sistemi che supportano
la distribuzione orizzontale: sistemi peer-to
peer
D. Rosaci
Sistemi Distribuiti - Architetture
24
Sistemi peer-to-peer
• Ogni unità agisce sia come client che
come server (unità servent)
• Problema fondamentale: organizzare i
processi in una rete i cui nodi sono i
processi stessi e gli archi sono i canali
di comunicazione (reti overlay)
• Due tipi di reti overlay
– Strutturate
– Non strutturate
D. Rosaci
Sistemi Distribuiti - Architetture
25
Architetture peer-to-peer
strutturate
• La rete overlay è costruita usando una procedura
deterministica
• I processi sono organizzati attraverso una Hash Table
Distribuita (DHT)
• Ai dati viene assegnata una chiave casuale in uno spazio di
identificatori grande (es. 128 bit)
• Anche ai nodi della rete è assegnato un numero causale preso
dallo stesso spazio di identifcatori
• Un sistema basato su DHT usa un qualche schema efficiente
e deterministico per mappare la chiave di un dato
nell’identificatore di un nodo, basandosi su qualche metrica di
distanza
• Quando si cerca un dato, il sistema è in grado di restituire
l’inidirizzo di rete del nodo associato al dato.
D. Rosaci
Sistemi Distribuiti - Architetture
26
Esempio di peer-to-peer
strutturato: il sistema CHORD
• Nodi logicamente organizzati in un anello,
tale per cui un dato con chiave k è mappato
in un nodo con il più piccolo identificatore
id≥k. Questo nodo è chiamato successore di
k, succ(k)
• Un applicazione in esecuzione su un nodo
arbitrario e che sta cercando il dato k,
chiamerà la funzione lookup(k) che restituirà
l’indirizzo di rete del nodo succ(k) in cui
risiede il dato k. Questo nodo sarà poi
contattato per ottenere una copia del dato
D. Rosaci
Sistemi Distribuiti - Architetture
27
Esempio di rete CHORD
[13,14,15]
0
15
1
14
[0,1]
2
13
3
[8,9,10,11,12]
12
4
11
[2,3,4]
5
10
6
9
7
[5,6,7]
8
D. Rosaci
Sistemi Distribuiti - Architetture
28
Entrata di un nodo in CHORD
• Quando un nodo vuole entrare nel sistema, genera
causalmente un identificatore id (la probabilità di
generare un id già esistente è tendente a 0, se lo
spazio degli id. è grande)
• Il nodo fa una ricerca dell’id, che restituisce succ(id)
• Viene contattato succ(id), e il nuovo nodo si unisce
adesso. Poiché ogni nodo memorizza inoltre il suo
predecessore, viene contattato anche il
predecessore di succ(id) che diventa predecessore
del nuovo nodo
• Tutti i dati associati al nuovo nodo id sono ora
trasferiti dal vecchio nodo succ(id)
D. Rosaci
Sistemi Distribuiti - Architetture
29
Esempio di rete CHORD
[13,14,15]
0
15
[0,1]
1
14 Un nodo vuole entrare
2
Si genere random l’id 10
13
3
Si contatta il succ(10)
cioè 12
[8,9,10,11,12]
12
4
Si contatta il prec(12)
cioè 7
11
5
Si spostano sul nodo 10 i
dati 8,9,10
10
[2,3,4]
6
9
7
[5,6,7]
8
10
D. Rosaci
Sistemi Distribuiti - Architetture
30
Uscita di un nodo in CHORD
• Il nodo uscente informa della sua
dipartita il suo successore e il suo
successore
• Tutti i dati del nodo uscente vengono
trasferiti al successore
D. Rosaci
Sistemi Distribuiti - Architetture
31
Architetture peer-to-peer non
strutturate
• I sistemi p2p non strutturati si basano su algoritmi
casuali per la costruzione di reti overlay: ogni nodo
mantiene una lista dei vicini, costruita in maniera
più o meno casuale
• Anche i dati sono posizionati sui nodi in maniera
casuale
• Quindi, quando un nodo ha bisogno di trovare un
dato, non può che inondare la rete con
un’interrogazione per la ricerca
• Ogni nodo mantiene una lista dei vicini, scelta in
maniera casuale, chiamata vista parziale.
• I vari framework esistenti differiscono per il modo in
cui si costruisce la lista parziale
D. Rosaci
Sistemi Distribuiti - Architetture
32
Esempio di peer-to-peer non
strutturato (Jelasity et al., 2005)
• In questo framework si suppone che i nodi si scambino
periodicamente gli elementi delle loro viste parziali
• Ricordiamo che ogni elemento della vista parziale è un nodo
della rete, ed ha un’età associata che indica da quanto tempo
esiste un riferimento a quel nodo
• Ogni nodo usa due thread distinti: un thread attivo e un
thread passivo
• Ogni nodo può assumere, in entrambi i thread, due stati
distinti: MODALITA_PUSH e MODALITA_PULL
• Il nodo entra in modalità PULL quando ha ricevuto un buffer
da un altro nodo, entra in modalità PUSH quando decide di
costruire un buffer per un altro nodo
D. Rosaci
Sistemi Distribuiti - Architetture
33
(Jelasity et al.)-Thread Attivo
1.
2.
Seleziona un nodo P dalla vista parziale attuale
Se MODALITA_PUSH
1.
2.
3.
4.
5.
3.
4.
5.
6.
miobuffer=[(mioindirizzo,0)]
Permuta vista parziale
Sposta gli H elementi più vecchi alla fine
Appendi i primi C/2 elementi a miobuffer
Invia miobuffer a P
Altrimenti invia un trigger a P
Se MODALITA_PULL ricevi il buffer di P
Costruisci una vista parziale a partire dalla attuale
e dal buffer di P
Aumenta l’età di ogni elemento nella nuova lista
parziale
D. Rosaci
Sistemi Distribuiti - Architetture
34
(Jelasity et al.)-Thread Passivo
1. Ricevi il buffer da qualunque nodo Q
2. Se MODALITA_PULL
1.
2.
3.
4.
5.
miobuffer=[(mioindirizzo,0)]
Permuta vista parziale
Sposta gli H elementi più vecchi alla fine
Appendi i primi C/2 elementi a miobuffer
Invia miobuffer a Q
3. Costruisci una vista parziale a partire dalla
attuale e dal buffer di Q
4. Aumenta l’età di ogni elemento nella
nuova lista parziale
D. Rosaci
Sistemi Distribuiti - Architetture
35