Upload
vanhanh
View
216
Download
0
Embed Size (px)
Citation preview
7. Progetto di Applicazioni Distribuite
Andrea Polini
Ingegneria del SoftwareCorso di Laurea in Informatica
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 1 / 35
Sommario
1 Sistemi distribuiti - generalità
2 Middleware - generalità
3 Middleware - Tecnologie e Paradigmi
4 Modelli di calcolo distribuito
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 2 / 35
Sistemi distribuiti - generalità
Sommario
1 Sistemi distribuiti - generalità
2 Middleware - generalità
3 Middleware - Tecnologie e Paradigmi
4 Modelli di calcolo distribuito
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 3 / 35
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 infine pergestire un insieme di tipologie di fallimento che non possono occorrerein un sistema centralizzato.
(Silberschatz - Galvin, Operating System Concepts)
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 4 / 35
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’applicazione distribuita è tipicamenteestremamente più complessa e costosa rispetto alla realizzazione diun sistema centralizzato. Dunque se non è effettivamente necessarioè in generale meglio non pianificare e progettare un sistema distribuito.
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 5 / 35
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’applicazione distribuita è tipicamenteestremamente più complessa e costosa rispetto alla realizzazione diun sistema centralizzato. Dunque se non è effettivamente necessarioè in generale meglio non pianificare e progettare un sistema distribuito.
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 5 / 35
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’applicazione distribuita è tipicamenteestremamente più complessa e costosa rispetto alla realizzazione diun sistema centralizzato. Dunque se non è effettivamente necessarioè in generale meglio non pianificare e progettare un sistema distribuito.
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 5 / 35
Sistemi distribuiti - generalità
Sistemi distribuitiquando?
Alcune caratteristiche sono però difficilmente ottenibili da un sistemacentralizzato. 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) 7. Progetto di Applicazioni Distribuite 6 / 35
Sistemi distribuiti - generalità
Sistemi distribuitiquando?
Alcune caratteristiche sono però difficilmente ottenibili da un sistemacentralizzato. 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) 7. Progetto di Applicazioni Distribuite 6 / 35
Middleware - generalità
Sommario
1 Sistemi distribuiti - generalità
2 Middleware - generalità
3 Middleware - Tecnologie e Paradigmi
4 Modelli di calcolo distribuito
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 7 / 35
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) 7. Progetto di Applicazioni Distribuite 8 / 35
Middleware - generalità
Middleware - “vista d’insieme”
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 9 / 35
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) 7. Progetto di Applicazioni Distribuite 10 / 35
Middleware - generalità
Situazione tipica
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 11 / 35
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) 7. Progetto di Applicazioni Distribuite 12 / 35
Middleware - generalità
Dimensioni Trasparenza
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 13 / 35
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) 7. Progetto di Applicazioni Distribuite 14 / 35
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) 7. Progetto di Applicazioni Distribuite 15 / 35
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) 7. Progetto di Applicazioni Distribuite 15 / 35
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) 7. Progetto di Applicazioni Distribuite 16 / 35
Middleware - Tecnologie e Paradigmi
Meccanismi di invocazione remota
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 17 / 35
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) 7. Progetto di Applicazioni Distribuite 18 / 35
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) 7. Progetto di Applicazioni Distribuite 19 / 35
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) 7. Progetto di Applicazioni Distribuite 20 / 35
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) 7. Progetto di Applicazioni Distribuite 21 / 35
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) 7. Progetto di Applicazioni Distribuite 22 / 35
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) 7. Progetto di Applicazioni Distribuite 23 / 35
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) 7. Progetto di Applicazioni Distribuite 24 / 35
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) 7. Progetto di Applicazioni Distribuite 25 / 35
Middleware - Tecnologie e Paradigmi
Sicurezza
Distribuzione di oggetti su reti non “controllabili”
Meccanismi di sicurezza. Ogni richiesta potrebbe essere autenticata
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 26 / 35
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) 7. Progetto di Applicazioni Distribuite 27 / 35
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) 7. Progetto di Applicazioni Distribuite 28 / 35
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) 7. Progetto di Applicazioni Distribuite 29 / 35
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) 7. Progetto di Applicazioni Distribuite 30 / 35
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) 7. Progetto di Applicazioni Distribuite 31 / 35
Modelli di calcolo distribuito
Service Oriented Computingprodromi
Avvento di Internet e opportunità di “interconnettere” e far interoperaredifferenti organizzazioni. Nuove parole chiavi:
Business-to-Business (B2B) ApplicationEnterprise Application Integration (EAI)
Interazione tra Middleware “tradizionali” estremamente difficile equando possibile risulta essere estremamente costoso
Nasciata di Service oriented computing
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 32 / 35
Modelli di calcolo distribuito
Service Oriented Architecturein una slide
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 33 / 35
Modelli di calcolo distribuito
Web Services
Web Service sono una specifica tecnologica che permette diimplementare i concetti di base di Service Oriented Computing.
4 elementi costitutivi di base:eXtensible Markup Language (XML)Simple Object Access Protocol (SOAP)Web Service Description Language (WSDL)Universal Description Discovery Integration (UDDI)
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 34 / 35
Modelli di calcolo distribuito
Web Servicesin una slide
(Ingegneria del Software) 7. Progetto di Applicazioni Distribuite 35 / 35