Architetture dei sistemi distribuiti

Architetture dei sistemi
distribuiti
Ingegneria del software
a.a 2009-2010
Sommario
•
•
•
•
Architetture multiprocessore
Architetture client server
Architetture a oggetti distribuiti
Calcolo interoganizzativo
Sistemi distribuiti
• Sistemi in cui l’elaborazione delle
informazioni è distribuita su diversi
computer
Vantaggi
•
•
•
•
•
Condivisione delle risorse
Apertura
Simultaneità
Scalabilità
Fault tolerance
Svantaggi
•
•
•
•
Complessità
Protezione
Gestibilità
Non prevedibilità
Architetture multiprocessore
• Il software consiste in una serie di processi che possono
essere eseguiti su processori separati
• Tipico nei sistemi real time:
– Sistemi che raccolgono le informazioni in base alle quali
prendono decisioni e inviano segnali agli attuatori che
modificano l’ambiente del sistema
– I processi possono essere eseguiti su un unico processore sotto
il controllo di uno scheduler
– L’uso di processori multipli ( non obbligatorio) migliora le
prestazioni del sistema
– La ripartizione dei processi è determinata da un dispatcher
• Es. sistema di controllo del traffico
• I sistemi composti da processi multipli non sono
necessariamente dei sistemi distribuiti
Architetture
• Tipi di architetture di sistema
– Client server:
• Il sistema può essere considerato come un
insieme di servizi forniti ai client che ne fanno uso
– A oggetti distribuiti
• Il sistema è un insieme di oggetti interagenti in cui
non c’è distinzione tra fornitore e utente di servizi
– Peer-to-peer: utilizzate principalmente per
sistemi personali
– A servizi distribuiti
middleware
“software di mezzo”
• Un sistema distribuito necessita di un software
che gestisca le diverse componenti di un
sistema distribuito
– Le diverse componenti possono essere implementate
in linguaggi di programmazione diversi ed eseguiti su
differenti tipi di processore
Il middleware deve gestire la comunicazione e lo
scambio di dati tra le diverse componenti
Architetture client server
• Un’applicazione viene modellata come un
insieme di servizi forniti da un server e un
insieme di client che li utilizza
– Client, server
• identificano i processi logici (possono essere utilizzati per
individare i processori su cui i processi sono eseguiti)
– Client:
• devono conoscere i server disponibili
• Non sanno dell’esistenza di altri client
– Server:
• Diversi processi server possono essere eseguiti su un
singolo processore server
Struttura logica dell’applicazione
• Un’applicazione è strutturata in 3 strati :
– Presentazione:
• Rappresentazione dei dati e interazioni con
l’utente
– Elaborazione applicativa:
• Implementa la logica dell’applicazione
– Gestione dei dati:
• Esegue tutte le operazioni sul database
Architettura client server e struttura
logica dell’applicazione
• Se si sta progettando un sistema
distribuito ogni strato dell’applicazione
dovrebbe essere distribuito su un
computer diverso
Architetture client server
• A due livelli
– Thin-client
– Fat-client
• A tre livelli
• A livelli multipli
Architettura two-tier
È un’applicazione organizzata in un server
(o diversi server identici) e un insieme di
client
Thin client
• Tutte le elaborazioni applicative e la gestione dei
dati sono gestite dal server
• Il client si occupa soltanto di eseguire il software
di presentazione
– Esempio
• un sistema centralizzato ereditato
– L’interfaccia viene migrata verso PC, l’applicazione funge da
server e gestisce tutte le elaborazioni applicative e le gestioni
dei dati
• I client sono semplici dispositivi di rete (anziché dei pc), il
dispositivo usa un browser internet e l’interfaccia è
implementata tramite tale sistema
Svantaggi del thin client
• Pesante carico di lavoro sul server e sulla
rete
• La potenza di elaborazione dei dispositivi
client viene sprecata
Fat client
• Client:
– elaborazione della logica dell’applicazione
– Presentazione
• Server:
– È un server di transazione che gestisce le transazioni al
database
• Esempio
– Bancomat, lo sportello è il client, il server è un mainframe che
gestisce il database dei conti dei clienti, l’hardware dello
sportello esegue molte delle elaborazioni relative al cliente
associate a una transazione, lo sportello non si connette
direttamente al database ma a un monitor di telelaborazione , un
middleware che organizza le comunicazioni con i client e
serializza le transazioni
Svantaggi del fat client
• La gestione del sistema è più complessa:
– Le funzionalità dell’applicazione sono divise
su diversi computer
– Quando deve essere modificato il software è
necessario reinstallare su ogni computer
client
– Costi notevoli
Svantaggi del two-tier
• Gli strati logici sono mappati su due soli
sistemi
– Problemi di scalabilità e prestazioni ( nel thin
client)
– Problemi di gestione del sistema ( nel fat
client
Architettura three-tier
• La presentazione, l’elaborazione
applicativa e la gestione dei dati sono
processi logicamente separati ed eseguiti
su processori diversi
– Esempio
• Un sistema di internet banking: il database dei
clienti, mainframe fornisce i servizi di gestione dei
dati, un server web fornisce i servizi applicativi
estratti conto, invio di pagamenti, ecc, il computer
dell’utente, dotato di un browser internet è il client
Vantaggi dell’architettura three-tier
• Ottimizzazione del trasferimento delle
informazioni tra il server web e il server
database: è possibile usare un protocollo
veloce di basso livello
• Utilizzo di un middleware efficiente per
recuperare le informazioni dal database
Architettura multi-tier
• Il modello three-tier può essere esteso ad un
modello multi-tier in cui sono presenti server
aggiuntivi:
• Usato quando le applicazioni devono accedere e
utilizzare dati di database diversi
• Tra il server applicativo e i server database si
posiziona un server di integrazione che
raccoglie i dati distribuiti e li invia all’applicazione
come se provenissero da un unico database
3-multitier vs 2-tier
• Maggiore scalabilità:
– le architetture 3 e multi tier distribuiscono
l’elaborazione applicativa su diversi server:
• sono più scalabili delle architetture a due livelli
• Minor traffico di rete
– rispetto alle thin-client
• Facilità nell’aggiornamento della parte
applicativa (essendo posizionata centralmente)
• Risposta più rapida alle richieste dell’utente
(essendo l’elaborazione distribuita sui server
applicativo e database)
Uso delle diverse applicazioni client
server
• Due livelli thin-client:
– Sistemi ereditati in cui non è attuabile la separazione tra l’elaborazione
applicativa e la gestione dei dati
– Applicazioni di calcolo intensivo ( es. compilatori) con minima gestione
dati
– Applicazioni dati intensivi con elaborazione applicativa inesistente
• Due livelli fat-client
– Elaborazione applicativa fornita da software off-the shelf( es. foglio di
calcolo)
– Elaborazione di calcolo intensivo di dati ( es. visualizzazione)
– Funzionalità end-user stabili e realizzare in un ambiente con gestione
del sistema ben salda
• Tre o multi livelli
– Applicazioni su vasta scala con centinaia o migliaia di client
– Dati e applicazioni volatili
– Dati integrati da sorgenti multipli
Limiti del modello client server
• Scarsa flessibilità del progetto:
– Occorre decidere dove bisogna fornire i
servizi
• Progettare la scalabilità
• Fornire mezzi per distribuire il carico tra
diversi server in caso di aggiunta di nuovi
client
Architetture a oggetti distribuiti
• I componenti fondamentali sono oggetti che dotano di
un’interfaccia un insieme di servizi da essi forniti
– Altri oggetti richiamano questi servizi
• Non vi è distinzione logica tra client e server
• Gli oggetti possono essere distribuiti su diversi computer
di una rete e comunicare attraverso un middleware che
fornisce un’interfaccia trasparente tra gli oggetti, Object
Request Broker, ORB
• Un insieme di servizi permette agli oggetti di comunicare
e di essere aggiunti e rimossi dal sistema
Vantaggi del modello
• Ritardare le decisioni su dove e come
collocare i servizi
• architettura molto aperta
• Flessibile
• Scalabile
• È possibile riconfigurare il sistema
dinamicamente attraverso la migrazione di
oggetti sulla rete
Esempio
Un’applicazione di vendita al dettaglio può essere strutturata secondo approcci differenti:
1.
usando un modello logico di architettura ad oggetti distribuiti:
–
Le funzionalità del sistema sono fornite in termini di servizi o combinazione di servizi
•
–
•
1.
(es. controllo delle scorte, dell’ordine, delle merci ecc.)
Forniti usando una serie di oggetti distribuiti, oggetti business forniscono servizi specifici
del dominio, domain specific
Tale modello logico può essere realizzato come modello di implementazione
Usando un approccio ad oggetti distribuiti per implementare un sistema client
server:
Il modello logico è un modello client server ma sia client che server sono realizzati
come oggetti distribuiti che comunicano attraverso un software bus
2.
1.
2.
Il sistema è facilmente modificabile, es passare da un’architettura two tier ad una three
tier
Il server o i client possono essere implementati come singolo oggetto distribuito ma
essere composti da oggetti più piccoli che forniscono specifici servizi
Altri esempi
Sistemi in cui le architetture ad oggetti distribuiti
sono indicate:
Sistemi data mining
catena di negozi al dettaglio con vendita di
generi alimentari e di arredamento che vuole
cercare relazioni tra gli acquisti:
Ogni database può essere incapsulato in un
oggetto distribuito con un’interfaccia che
fornisce accesso di sola lettura ai prpri dati
oggetti distribuiti vs client server
• Le architetture a oggetti distribuiti sono più
complesse da progettare
• I sistemi client server riflettono il modo
naturale di pensare ai sistemi,
• Riproducono molte transazioni umane in
cui gli utenti richiedono e ricevono servizi
da altri utenti specializzati in tali servizi
Implementazione di un’architettura
a oggetti distribuiti
• Richiede un middleware per gestire la
comunicazione tra gli oggetti distribuiti
– il middleware è detto Object Request Broker
(ORB)
• Gli oggetti possono essere implementati
utilizzando linguaggi di programmazione
diversi, eseguiti su piattaforme diverse e
non aver bisogno di conoscere tutti i nomi
degli altri oggetti del sistema
Il middleware
• Il middleware deve garantire la comunicazione
trasparente tra gli oggetti:
È richiesto a due livelli:
• Comunicazione logica:
– fornisce funzionalità che permettono agli oggetti su computer
diversi di scambiarsi dati e controllare le informazioni
• Standard sviluppati sono CORBA, COM per facilitare la
comunicazione tra oggetti su piattaforme diverse
• Componenti:
– Il middleware fornisce una base per lo sviluppo di componenti
compatibili
• Standard come EJB, CORBA, ActiveX forniscono una base per
l’implementazione di componenti con metodi standard che possono
essere interrogati e utilizzati da altri componenti
Calcolo distribuito interorganizzativo
• Calcolo distribuito
– Un’organizzazione ha un insieme di server sui quali distribuire il
carico
– i server sono tutti collocati nella stessa organizzazione
– Possono essere applicati standard e processi operativi interni
– I client hanno il limitato compito dell’esecuzione dell’interfaccia
utente (per i sistemi web-based)
• Nuovi modelli di calcolo distribuito
– Peer-to-peer (p2p)
• Basato sull’esecuzione del calcolo da parte di nodi di rete individuali
– orientato ai servizi
• Basato su standard per lo scambio di dati
Architetture peer-to-peer
• Sono sistemi decentralizzati dove i calcoli
possono essere eseguiti da ogni nodo
della rete e non ci sono distinzioni tra
client e server.
• Il sistema generale viene progettato per
trarre vantaggio dalla potenza di calcolo e
della memoria disponibile su una vasta
rete di computer
Applicazioni del peer-to-peer
• usate per lo più per:
– sistemi personali
• Condivisione di file, sistemi di messaggeria
istantanea
• Fornire comunicazione diretta tra utenti senza
utilizzare un server intermedio
Prospettive sul p2p
• L’architettura logica della rete è
l’architettura di distribuzione del sistema
• L’architettura dell’applicazione è
l’organizzazione generica dei componenti
all’interno di ogni tipo di applicazione
Architettura logica del p2p
• Architetture
– decentralizzate
– Semi-centralizzate
Architettura decentralizzata
• Ogni nodo della rete può essere a
conoscenza di ogni altro nodo e può
connettersi ad esso per scambiare dati
– Nella pratica, però, i nodi vengono organizzati
in “località” con alcuni nodi che fungono da
ponte ad altre località
• I nodi della rete non sono solo elementi
funzionanti, ma anche commutatori di
comunicazione che indirizzano i dati e i segnali di
controllo da un nodo all’altro
Vantaggi/svantaggi
• Ridondanza
– Tolleranza agli errori e ai nodi che si
disconnettono dalla rete
• Overhead del sistema:
– La stessa ricerca può essere elaborata da
diversi nodi con aumento della comunicazione
tra diversi peer
Architettura semi-centralizzata
• Uno o più nodi fungono da server per
semplificare la comunicazione tra i nodi
• Un server aiuta a stabilire il contatto tra i
nodi della rete e a coordinare i risultati del
calcolo
P2p vs service oriented
• P2p più efficiente
• Problemi: protezione fiducia
• Preferibili in applicazioni non critiche con
relazioni di lavoro già esistenti tra le
organizzazioni
Architetture orientate ai servizi
• Web-service
– Una rappresentazione standard di risorse elaborative
o informative che può essere utilizzata da altri
programmi
• Usando un web-service le organizzazioni che vogliono
rendere accessibili le proprie informazioni ad altri programmi
possono farlo definendo e pubblicando un’interfaccia di
servizio che specifica i dati disponibili e come accedervi
• Un webservice è un’istanza della più generica nozione di
servizio:
– Un atto o una prestazione offerta da un parte a un’altra
[Lovelock, 1996]
La sua erogazione è indipendente dall’applicazione che sta
usando il sistema
Modello di servizio
• Un fornitore offre un servizio definendo la sua
interfaccia e implementandone la sua
funzionalità
• Un richiedente si collega al servizio dalla propria
applicazione che deve includere codice per
richiamare quel servizio e per elaborarne i
risultati
• Per assicurarsi che il servizio sia accessibile agli
utenti esterni, il fornitore inserisce un record in
un registro dei servizi che comprende
informazioni sul servizio e su cosa fa
Modello service oriented vs
modello distributed-object
•
•
I servizi possono essere offerti da ogni fornitore di servizio dentro o fuori
un’organizzazione
I fornitori di servizio rendono pubbliche le informazioni sul servizio in modo che
qualsiasi utente autorizzato possa utilizzarlo
–
•
Le applicazioni possono attendere il collegamento ai servizi finchè non sono
consegnati o fino all’esecuzione
–
•
•
•
Le applicazioni possono cambiare fornitore di servizio dinamicamente mentre il servizio è in
esecuzione
Un fornitore può riconoscere nuovi servizi che possono essere creati collegando i
servizi esistenti in modo innovativo
Gli utenti possono pagare i servizi a seconda dell’utilizzo anziché della fornitura
–
•
Fornitore ed utente non devono negoziare cosa il servizio fa
Anziché acquistare un componente costoso, l’utente può utilizzare un servizio esterno che
pagherà solo quando necessario
Le applicazioni possono essere più piccole poiché possono implementare la gestione
delle eccezioni come servizio esterno
Le applicazioni possono essere reattive e adattarsi alle variazioni dell’ambiente
collegandosi a diversi servizi
Vantaggi/svantaggi
• Architetture debolmente accoppiate
– I collegamenti ai servizi possono cambiare
durante l’esecuzione
• Sviluppo basato su standard
– Standard sviluppati solo di recente