8. Sistemi Distribuiti e Middleware

Andrea Polini

Ingegneria del SoftwareCorso di Laurea in Informatica

(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 35

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 / 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) 8. Sistemi distribuiti e Middleware 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 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 / 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 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 / 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 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 / 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 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 / 35

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 / 35

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 / 35

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 / 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) 8. Sistemi distribuiti e Middleware 8 / 35

Middleware - generalità

Middlware - “vista d’insieme”

(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 10 / 35

Middleware - generalità

Situazione tipica

(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 12 / 35

Middleware - generalità

Dimensioni Trasparenza

(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 16 / 35

Middleware - Tecnologie e Paradigmi

Meccanismi di invocazione remota

(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 32 / 35

Modelli di calcolo distribuito

Service Oriented Architecturein una slide

(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 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) 8. Sistemi distribuiti e Middleware 34 / 35

Modelli di calcolo distribuito

Web Servicesin una slide

(Ingegneria del Software) 8. Sistemi distribuiti e Middleware 35 / 35