Architetture

1. Architetture

2. 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 Sistemi Distribuiti - Architetture

3. 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à Sistemi Distribuiti - Architetture

4. 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 • Architetture a livelli (layered) • Architetture basate sugli oggetti • Architetture centrate sui dati • Architetture basate sugli eventi Sistemi Distribuiti - Architetture

5. 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) Sistemi Distribuiti - Architetture

6. Architetture basate su oggetti • Ogni componente è un oggetto e gli oggetti sono connessi attraverso un meccanismo di chiamata a procedura remota. • Corrisponde all’architettura client-server • I grandi sistemi software sono oggigiorno organizzati principalmente a livelli e ad oggetti Sistemi Distribuiti - Architetture

7. 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 Sistemi Distribuiti - Architetture

8. 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 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 Sistemi Distribuiti - Architetture

10. 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 Sistemi Distribuiti - Architetture

11. 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 domanda-risposta) Sistemi Distribuiti - Architetture

12. 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!) Sistemi Distribuiti - Architetture

13. 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 Sistemi Distribuiti - Architetture

14. 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 Sistemi Distribuiti - Architetture

15. 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 Sistemi Distribuiti - Architetture

16. 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 Sistemi Distribuiti - Architetture

17. 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 Sistemi Distribuiti - Architetture

18. 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 Sistemi Distribuiti - Architetture

19. 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 Sistemi Distribuiti - Architetture

20. 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 Sistemi Distribuiti - Architetture

21. 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 Sistemi Distribuiti - Architetture

22. 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 Sistemi Distribuiti - Architetture

23. Esempio di Architettura a 3 livelli fisici • Organizzazione di un Sito Web di E-Commerce • 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) Sistemi Distribuiti - Architetture

24. 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 Sistemi Distribuiti - Architetture

25. 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 Sistemi Distribuiti - Architetture

26. 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. Sistemi Distribuiti - Architetture

27. 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 Sistemi Distribuiti - Architetture

28. Esempio di rete CHORD [13,14,15] 0 [0,1] 15 1 14 2 13 3 [8,9,10,11,12] [2,3,4] 12 4 11 5 10 6 [5,6,7] 9 7 8 Sistemi Distribuiti - Architetture

29. 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) Sistemi Distribuiti - Architetture

30. Esempio di rete CHORD [13,14,15] 0 [0,1] 15 1 Un nodo vuole entrare Si genere random l’id 10 Si contatta il succ(10) cioè 12 Si contatta il prec(12) cioè 7 Si spostano sul nodo 10 i dati 8,9,10 14 2 13 3 [8,9,10,11,12] [2,3,4] 12 4 11 5 10 6 [5,6,7] 9 7 8 10 Sistemi Distribuiti - Architetture

31. 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 Sistemi Distribuiti - Architetture

32. 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 Sistemi Distribuiti - Architetture

33. 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 Sistemi Distribuiti - Architetture

34. (Jelasity et al.)-Thread Attivo • Seleziona un nodo P dalla vista parziale attuale • Se MODALITA_PUSH • 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 Sistemi Distribuiti - Architetture

35. (Jelasity et al.)-Thread Passivo • Ricevi il buffer da qualunque nodo Q • Se MODALITA_PULL • 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 • Costruisci una vista parziale a partire dalla attuale e dal buffer di Q • Aumenta l’età di ogni elemento nella nuova lista parziale Sistemi Distribuiti - Architetture