8. Sistemi Distribuiti e Middleware - isti.cnr.itpolini/downloads/SE0708/IdS_8.pdf · Ingegneria...
-
Upload
truongtram -
Category
Documents
-
view
219 -
download
0
Transcript of 8. Sistemi Distribuiti e Middleware - isti.cnr.itpolini/downloads/SE0708/IdS_8.pdf · Ingegneria...
8. Sistemi Distribuiti e Middleware
Andrea Polini
Ingegneria del SoftwareCorso di Laurea in Informatica
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32
Sommario
1 Sistemi distribuiti - generalità
2 Middleware - generalità
3 Middleware - Tecnologie e Paradigmi
4 Modelli di calcolo distribuito
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 2 / 32
Sistemi distribuiti - generalità
Sommario
1 Sistemi distribuiti - generalità
2 Middleware - generalità
3 Middleware - Tecnologie e Paradigmi
4 Modelli di calcolo distribuito
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 3 / 32
Sistemi distribuiti - generalità
Sistemi distribuitiuna definizione
Un sistema distribuito è una collezione di processori che noncondividono memoria o clock. Ogni processore ha invece una suamemoria locale e la comunicazione tra processi avviene attraversolinee di comunicazione. I processori in un sistema distribuito variano indimesioni e funzionalità.. . .Un sistema distribuito deve fornire meccanismi per la sincronizzazionee la comunicazione, per gestire il problema del deadlock, ed infini pergestire un insieme di tipologie di fallimento che non possono occorrerein un sistema centralizzato.
(Silberschatz - Galvin, Operating System Concepts)
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 4 / 32
Sistemi distribuiti - generalità
Sistemi distribuitiin evidenza
no memoria comuneeterogeneitàpresenza dei problemi tipici della concorrenza e necessità dimeccanismi di supporto alla loro gestionepiù punti di fallimento e nuove tipologie di fallimentoproblemi di sicurezza ed integrità
CONCLUSIONE
La realizzazione di un sistema distribuito è tipicamente estremamentecomplessa e constosa rispetto alla realizzazione di un sistemacentralizzato. Dunque se non è effettivamente necessario è ingenerale meglio non pianificare e progettare un sistema distribuito.
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 5 / 32
Sistemi distribuiti - generalità
Sistemi distribuitiin evidenza
no memoria comuneeterogeneitàpresenza dei problemi tipici della concorrenza e necessità dimeccanismi di supporto alla loro gestionepiù punti di fallimento e nuove tipologie di fallimentoproblemi di sicurezza ed integrità
CONCLUSIONE
La realizzazione di un sistema distribuito è tipicamente estremamentecomplessa e constosa rispetto alla realizzazione di un sistemacentralizzato. Dunque se non è effettivamente necessario è ingenerale meglio non pianificare e progettare un sistema distribuito.
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 5 / 32
Sistemi distribuiti - generalità
Sistemi distribuitiin evidenza
no memoria comuneeterogeneitàpresenza dei problemi tipici della concorrenza e necessità dimeccanismi di supporto alla loro gestionepiù punti di fallimento e nuove tipologie di fallimentoproblemi di sicurezza ed integrità
CONCLUSIONE
La realizzazione di un sistema distribuito è tipicamente estremamentecomplessa e constosa rispetto alla realizzazione di un sistemacentralizzato. Dunque se non è effettivamente necessario è ingenerale meglio non pianificare e progettare un sistema distribuito.
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 5 / 32
Sistemi distribuiti - generalità
Sistemi distribuitiquando?
Alcune caratteristiche sono però difficilmente ottenibili da un sistemcentralizzato. Quando dunque queste proprietà diventanoparticolarmente importanti si dovrà ricorrere alla progettazione di unsistema distribuito.
scalabilitàeterogeneitàcondivisione delle risorsetolleranza ai guastiapertura (openness)
Riguardo la performance? È questa una proprietà che dovrebbesuggerire di implementare un sistema distribuito?
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 6 / 32
Sistemi distribuiti - generalità
Sistemi distribuitiquando?
Alcune caratteristiche sono però difficilmente ottenibili da un sistemcentralizzato. Quando dunque queste proprietà diventanoparticolarmente importanti si dovrà ricorrere alla progettazione di unsistema distribuito.
scalabilitàeterogeneitàcondivisione delle risorsetolleranza ai guastiapertura (openness)
Riguardo la performance? È questa una proprietà che dovrebbesuggerire di implementare un sistema distribuito?
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 6 / 32
Middleware - generalità
Sommario
1 Sistemi distribuiti - generalità
2 Middleware - generalità
3 Middleware - Tecnologie e Paradigmi
4 Modelli di calcolo distribuito
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 7 / 32
Middleware - generalità
Middlewaredefinizione
Il Middleware è un insieme di servizi di supporto alla distribuzioneindipendenti dalle applicazioni. In definitiva il middleware è il softwareche risiede al di sopra della rete ed al di sotto delle applicazionisoftware.
(Umar, Object-Oriented Client/Server Internet environments)
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 8 / 32
Middleware - generalità
Middlware - “vista d’insieme”
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 9 / 32
Middleware - generalità
Perché ne abbiamo bisogno
Sviluppo di ambiente distribuito eterogeneo complesso perché:scambio di dati complessidifferenti tipi di codificaparametri di ritorno possono rappresentare altri componentidistribuitiattivazione e deattivazione di componenti distribuitinecessità di azioni atomichesincronizzazione e parallelismo reale. . .
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 10 / 32
Middleware - generalità
Situazione tipica
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 11 / 32
Middleware - generalità
Middleware e trasparenza
Una tecnologia è trasparente se nasconde la complessità sottostante.Obbiettivo del middleware è dunque far “scomparire” la complessitàintrodotta dalla distribuzione.
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 12 / 32
Middleware - generalità
Dimensioni Trasparenza
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 13 / 32
Middleware - Tecnologie e Paradigmi
Sommario
1 Sistemi distribuiti - generalità
2 Middleware - generalità
3 Middleware - Tecnologie e Paradigmi
4 Modelli di calcolo distribuito
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 14 / 32
Middleware - Tecnologie e Paradigmi
Tipi di Middleware
Transaction processing middleware - semplifica la progettazionedi applicazioni che richiedono esecuzione di transazioni distribuite- TP monitors (IBM CICS, BEA TUXEDO, Transarc Encina, . . . )Message Oriented Middleware - supporta lo scambio di messaggitra applicazioni distribuite (IBM MQSeries, Sun ToolTalk . . . )Remote Procedure Calls (RPC) - permette di invocare facilmenteuna procedura residente su di una macchina remota.Richiede definizione di Inteface Definition Language - IDLObject-Oriented Middleware - permette di implementareun’applicazione ad oggetti distribuiti. Progetto di applicazionecome se fosse locale.
Attenzione: distribuzione non deve essere completamentetrasparente al progettista ed allo sviluppatore
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 15 / 32
Middleware - Tecnologie e Paradigmi
Tipi di Middleware
Transaction processing middleware - semplifica la progettazionedi applicazioni che richiedono esecuzione di transazioni distribuite- TP monitors (IBM CICS, BEA TUXEDO, Transarc Encina, . . . )Message Oriented Middleware - supporta lo scambio di messaggitra applicazioni distribuite (IBM MQSeries, Sun ToolTalk . . . )Remote Procedure Calls (RPC) - permette di invocare facilmenteuna procedura residente su di una macchina remota.Richiede definizione di Inteface Definition Language - IDLObject-Oriented Middleware - permette di implementareun’applicazione ad oggetti distribuiti. Progetto di applicazionecome se fosse locale.
Attenzione: distribuzione non deve essere completamentetrasparente al progettista ed allo sviluppatore
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 15 / 32
Middleware - Tecnologie e Paradigmi
Object-Oriented middleware
Principali elementi di un Middleware OO sono:Object Request Broker (ORB)Interface Definition Language (IDL)
Principali tipi di middleware OO sono:
Java Remote Method Invocation (JavaRMI) - SunDistributed COM (DCOM) / .Net - MicrosoftCommon Object Request Broker Architecture (CORBA) - OMG
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 16 / 32
Middleware - Tecnologie e Paradigmi
Meccanismi di invocazione remota
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 17 / 32
Middleware - Tecnologie e Paradigmi
Progettista dovrebbe sapere . . .
La progettazione di sistemi OO in distribuito presenta delle differenzeche devono essere considerate nelle varie fasi dello sviluppo. Inparticolare queste riguardano:
Ciclo di vita degli oggettiRiferimenti agli oggettiTempi di rispostaAttivazione e deattivazioneParallelismoComunicazioniFallimentiSicurezza
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 18 / 32
Middleware - Tecnologie e Paradigmi
Ciclo di vita
Creazione: tradizionalmente creazione avviene tramiteinvocazione del costruttore (il linker risolve il problema) residentenello stesso spazio di memoria). Questo non è più vero indistribuito. Meccanismo delle factory.Migrazione: è possibile che un oggetto migri dunque riferimenti adun oggetto possono cambiare.Rimozione: implementazione di meccanismi di garbage collectionin distribuito diventa particolarmente difficoltosa e molto costosain termini di risorse. Potrebbe essere necessario gestire situazioniin cui un oggetto non esiste più.
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 19 / 32
Middleware - Tecnologie e Paradigmi
Riferimenti agli oggetti
Riferimenti ad oggetti remoti richiedono strutture dati complesse(fattore anche 100).Dimensione influenza negativamente costo nel passaggio deiparametriMantenere un grosso numero di riferimenti remoti potrebbeessere troppo costoso
Nella progettazione di applicazioni distribuite OO si dovrebbe cercaredi minimizzare il numero di oggetti.
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 20 / 32
Middleware - Tecnologie e Paradigmi
Tempi di risposta
Richiesta ad oggetto remoto è tipicamente più costosa di un fattoreche oscilla tra 400 e 4000.
Nella progettazione di applicazioni distribuite OO si dovrebbe cercaredi favorire comunicazioni tra oggetti "vicini”. Oggetti che debbonocomunicare molto dovrebbero esser posti nello stesso host.
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 21 / 32
Middleware - Tecnologie e Paradigmi
Attivazione/Deattivazione
Il ciclo di vita di un oggetto tipicamente include fasi aggiuntive diattivazione/deattivazione. Queste vanno ad incidere ancor piùnegativamente sui tempi di risposta.
Le motivazioni a queste due nuove fasi sono:le macchine ospitanti gli oggetti potrebbero aver subito riavviile risorse disponibili su di un host potrebbero essere inferiori aquelle necessarie a tutti gli oggetti ospitatimolti oggetti che forniscono servizi potrebbero rimanere inattiviper lungo tempo in attesa di nuove richieste
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 22 / 32
Middleware - Tecnologie e Paradigmi
Parallelismo
Certezza di parallelismo reale richiede di considerare con cautela lasincronizzazione e l’accesso alle risorse. Accesso a oggetti condivisideve essere controllato
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 23 / 32
Middleware - Tecnologie e Paradigmi
Comunicazioni
Numerose cause che possono concorrere a ritardare le interazioniimpongono l’introduzione di meccanismi non bloccanti
Tipologie di comunicazionesincronaone-wayextended rendez-vousasincrona
MolteplicitàUnicastGroupMultiple
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 24 / 32
Middleware - Tecnologie e Paradigmi
Fallimenti
Maggiore probabilità di fallimento, maggiori punti di fallimento
Nuove tipologie di fallimento - fallimenti parziali
Differenti livelli di affidabilità:Unicast
exactly-onceatomicat-least-onceat-most-oncemaybe
Group e Multicastk-reliabilitytotally orderedbest effort
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 25 / 32
Middleware - Tecnologie e Paradigmi
Sicurezza
Distribuzione di oggetti su reti non “controllabili”
Meccanismi di sicurezza. Ogni richiesta potrebbe essere autenticata
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 26 / 32
Middleware - Tecnologie e Paradigmi
Problemi comuni
Problemi ricorrenti nella progettazione di sistemi distributi ad oggettinon strettamente correlati alla specifica applicazione. Middlewareforniscono soluzioni comuni:
LocationGestione del ciclo di vitaPersistenzaTransazioni
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 27 / 32
Middleware - Tecnologie e Paradigmi
Common Object Request Broker Architecture(CORBA)short overview
Standard aperto rilasciato dallo “Object Management Group”(OMG) - Ultima specifica rilasciata Marzo 2004 (1152 pagine)Elementi principali:
Object modelORBCORBA IDLCORBA Services, CORBA Facilities, CORBA Domain Interfaces
http://www.corba.org.vc.html (ca 220 organizzazioni)http://www.omg.org/technology/corba/corbadownloads.htm(ca 15 implementazioni free)
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 28 / 32
Modelli di calcolo distribuito
Sommario
1 Sistemi distribuiti - generalità
2 Middleware - generalità
3 Middleware - Tecnologie e Paradigmi
4 Modelli di calcolo distribuito
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 29 / 32
Modelli di calcolo distribuito
Modelli di calcolo distribuito
Modelli differenti si basano su paradigmi di interazione differenti.Tipicamente si distingue tra:
File Transfer - distribuzione riguarda i dati, basso carico e bassaconcorrenza. e.g. e-mailClient/ServerPeer-2-Peer (P2P) - più processi replicati su macchine differenticondividono risorse e scambiano informazioni
architetture decentralizzatearchitetture semi-centralizzate
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 30 / 32
Modelli di calcolo distribuito
Modello Cliente/Servente
Si distingue tra processi che richiedono servizi (Clienti) e quelli cheoffrono servizi (Serventi).
Nella computazione diverse problematiche devono essere affrontare:Interfaccia graficaLogica di businessGestione dei dati
La metodologia di gestione dei diversi “problemi” da luogo a diversepossibili architetture:
2-tierFat clientThin client
3-tiern-tier
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 31 / 32
Modelli di calcolo distribuito
Service Oriented Computing
Necessità di mettere in collegamento differenti organizzazioni (e.g.Business-to-Business - B2B).
Mettere in comunicazione differenti tecnologie “tradizionali”estremamente costosi.
Service oriented computing possibile risposta.
(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 32 / 32