LEZIONE 2 STORIA DEI SISTEMI DISTRIBUITI E MODELLI

LEZIONE 2
STORIA DEI SISTEMI DISTRIBUITI E MODELLI ARCHITETTURALI
Anni ’60-’70: architettura centralizzata, monolitica (vedi lezione 1)
 host (mainframe, mini) a cui vengono collegati terminali “stupidi”
 a tutt’oggi è l’architettura dominante
Anni ’80: reti locali di PC
 terminali dotati di intelligenza propria, che condividono risorse “pregiate”, come stampanti, dischi, etc.
Fine anni ’80 - Inizio anni ’90: applicazioni pienamente distribuite, modello client-server e peer-to-peer
 reti locali di PC e server, connesse su collegamenti geografici
Metà-fine anni ’90: Internet, WWW, Distributed Object Computing (vedi lezione 3)
 sistemi network-centrici (“The network is the computer”)
PRINCIPALI MODELLI DI ARCHITETTURE DISTRIBUITE
 client-server
 2-tiers, 3-tiers, n-tiers (vedi lezione 3)
 peer-to-peer
INTRODUZIONE MODELLO CLIENT_SERVER
Pattern (modello) di interazione Client/Server
I nodi della rete vengono suddivisi in due sottoinsiemi, non necessariamente disgiunti
 Client: consumatori di servizi
 A richiesta del proprio utente, iniziano il processo di interazione attraverso una richiesta di servizio
verso un server
 Elaborano la risposta ricevuta e la presentano all’utente
 Possono diventare inattivi in qualunque momento
 Server: fornitori di servizi
 Offrono servizi a richiesta dei client
 Possono ricevere molte richieste contemporaneamente da client differenti
 Devono garantire la propria disponibilità nel tempo
 Vantaggi
 Il client può essere (relativamente) semplice e indipendente dalla specifica applicazione
 Lo stesso client può essere usato per una molteplicità di scopi differenti
LEZIONE 2
Pagina 1 di 6
 Svantaggi
 Limiti nelle prestazioni: il server costituisce il collo di bottiglia
 Affidabilità: il malfunzionamento di un server centralizzato paralizza tutti i client
 Scalabilità ed estendibilità dei sistemi: come fanno i client a scoprire l’esistenza di nuovi server?
Programmi Client/Server
 Client e server sono programmi distinti
 non hanno quindi uno spazio di indirizzamento comune
 Occorre introdurre uno strato (middleware/S.O.) che consente la comunicazione tra i due programmi
 La struttura dei programmi si complica:
 È necessario far incontrare client e server
 Si devono gestire gli accessi concorrenti sul server
 Si devono trasformare i parametri in formati adatti ad essere trasportati attraverso la rete
IL MIDDLEWARE:
ha lo scopo principale di aiutare a risolvere problemi di interoperabilità (a livello di sistema operativo) e di
connettività riscontrati da applicazioni che devono lavorare su piattaforme distribuite. Tale software si
interpone negli elaboratori locali tra le applicazioni ed il sistema operativo locale creando quindi una
architettura a tre livelli
oppure
è un software di connessione che consiste in un insieme di servizi e/o di ambienti di sviluppo di applicazioni
distribuite che permettono a più entità (processi, oggetti ecc.), residenti su uno o più elaboratori, di
interagire attraverso una rete di interconnessione a dispetto di differenze nei protocolli di comunicazione,
architetture dei sistemi locali, sistemi operativi,ecc.
Schematicamente possiamo collocare il middleware come segue:
LEZIONE 2
Pagina 2 di 6
MIDDLEWARE SERVIZI
Servizio di Comunicazione. Questo servizio offre una API che permette all’applicazione distribuita di
scambiarsi informazioni tra le sue componenti residenti su elaboratori con caratteristiche hardware e/o
software differenti. Lo scopo di questo servizio è di nascondere le disomogeneità dovute alla
rappresentazione dei dati usata dai vari elaboratori, ai sistemi operativi locali ed a differenti reti che
costituiscono l’infrastruttura della piattaforma. Per comunicazioni si intendono diversi paradigmi di
interazione che vanno dalle RPC, alla messaggistica applicativa, al modello publish/subscribe, al
mantenimento di discipline diverse da quella FIFO (esempio causal order, total order)
Servizi di astrazione e cooperazione. Questi servizi rappresentano il cuore del middleware e comprendono
tra gli altri:
 Directory Service (o servizio di “pagine gialle”) che provvede alla identificazione ed alla localizzazione di
entità. Questo servizio rende le applicazioni al di sopra del middleware indipendenti dal sottosistema di
instradamento dei messaggi.
• Security Service che è finalizzato alla protezione di elementi critici come dati e servizi applicativi
attraverso tecniche come autenticazione, autorizzazione e criptografia.
• Time Service il quale assicura che tutti i clock interni tra client e server siano sincronizzati entro un
accettabile livello di varianza
Servizi per le applicazioni. Questi servizi permettono ad una applicazione di avere un accesso diretto o con
la rete o con i servizi offerti dal middleware. Ad esempio un servizio orientato alle transazioni, all’interno di
un middleware, può fornire un supporto per accesso transazionale a basi di dati eterogenee.
Servizi di amministrazione del sistema.
 Monitoring
 Configurazione
 Pianificazione.
Ambiente di sviluppo applicativo.
 Strumenti di aiuto alla scrittura
 Debugging
 Caricamento di applicazioni distribuite sia ad oggetti sia basate su processi.
 Interface Definition Language per l’interconnessione tra moduli scritti in diversi linguaggi di
programmazione e residenti su elaboratori distinti.
LEZIONE 2
Pagina 3 di 6
MIDDLEWARE: OBIETTIVI
 interoperabilità e connettività per applicazioni distribuite su piattaforme eterogenee
 collante delle applicazioni utilizzate all’interno di una azienda.
MODELLO PEER-TO-PEER
Pattern di interazione Peer-to-Peer
 Un sistema distribuito in cui tutti i nodi hanno le stesse responsabilità e le interazioni sono simmetriche
 Realizzati accoppiando funzionalità client e server
 Vantaggi
 Maggiore robustezza ed immunità ai malfunzionamenti
 Distribuzione del carico più uniforme
 Maggiori possibilità di interazione
 Svantaggi
 Maggiore complessità dei sistemi, dei protocolli e delle interazioni
 Necessità di sviluppare applicativi differenti per funzioni differenti (non c’è l’equivalente del browser
universale)
 Difficoltà di controllo centralizzato
Architettura peer-to-peer(P2P)
Nelle architetture peer-to-peer abbiamo coppie di host chiamati peer (letteralmente “persona di pari
grado” che dialogano direttamente fra di loro).
Un sistema P2P è formato da entità autonome (peer) capaci di autorganizzarsi, che condividono un insieme
LEZIONE 2
Pagina 4 di 6
di risorse distribuite presenti all’interno di una rete. Il sistema utilizza tali risorse per fornire una
determinata funzionalità in modo completamente o parzialmente decentralizzato.
Nei sistemi P2P gli host possono essere visti come una comunità che collabora con il binomio dare e
ricevere: ogni peer fornisce una risorsa e ottiene in cambio altre risorse.
Gli esempi più noti sono rappresentati dalle reti peer-to-peer in ambito di condivisione di file, come per
esempio eMule, oppure Gnutella.
P2P decentralizzato
Nella architettura completamente decentralizzata un peer ha sia funzionalità di client che di server
(funzionalità simmetrica = servent ), ed è impossibile localizzare una risorsa mediante un indirizzo IP statico:
vengono effettuati nuovi meccanismi di indirizzamento, definiti a livello superiore rispetto al livello IP.
Le risorse che i peer condividono sono i dati, la memoria, la banda ecc.: il sistema P2P è capace di adattarsi
a un continuo cambiamento dei nodi partecipanti (churn) mantenendo connettività e prestazioni accettabili
senza richiedere l'intervento di alcuna entità centralizzata (come un server).
P2P centralizzato
Il P2P centralizzato è un compromesso tra il determinismo del modello client-server e la scalabilità del
sistema puro: ha un server centrale (directory server) che conserva informazioni sui peer (index, cioè il
mapping resorse-peer) e risponde alle richieste su quelle informazioni effettuando quindi la ricerca in
modalità centralizzata.
I peer sono responsabili di conservare i dati e le informazioni (il server centrale non memorizza file), di
informare il server del contenuto dei file che intendono condividere e di permettere ai peer che lo
richiedono di scaricare le risorse condivise. La sua implementazione più famosa è Napset, dove gli utenti si
connettono a un server centrale nel quale pubblicano i nomi delle risorse che condividono.
LEZIONE 2
Pagina 5 di 6
P2P ibrido (o parzialmente centralizzato)
P2P ibrido è un P2P parzialmente centralizzato dove sono presenti alcuni peer (detti supernodi o superpeer o ultra-peer) determinati dinamicamente (tramite un algoritmo di elezione) che hanno anche la
funzione di indicizzazione: gli altri nodi sono anche chiamati leaf-peer.
LEZIONE 2
Pagina 6 di 6