Architetture Distribuite

Transcript

1 Architetture Distribuite Programmazione in Ambienti Distribuiti A.A Applicazioni software Un programma o un insieme di programmi progettati per supportare il lavoro di un insieme di utenti finali Comprendono tre aree funzionali: Interfaccia utente o Fornisce alle persone i meccanismi necessari (visualizzazioni, controlli, ) ad interagire con il programma Logica applicativa o Definisce la rappresentazione logica dei dati e dei processi aziendali che l applicazione supporta e le regole che ne governano il ciclo di vita Base dati o Offre meccanismi di accesso e memorizzazione persistente ai dati trattati dall applicazione 2 1

2 Applicazioni aziendali: le esigenze generali Integrare, in un unico schema, l accesso a tutti i servizi aziendali: Accesso ubiquo: da ogni terminale, in ogni momento, ad ogni servizio, da ogni posto (?) Essere facilmente accessibili (utilizzabili, indicizzabili, ricercabili, ) a tutti i potenziali utilizzatori Interni o esterni all azienda, con o senza formazione specifica, Persone o programmi Garantire elevati livelli di affidabilità del servizio Non compromettere la sicurezza informatica del servizio specifico né degli altri sistemi presenti Richiedere tempi di sviluppo limitati Garantire la scalabilità verso l alto 3 Evoluzione delle strategie di programmazione (1) Programmi monolitici Il programma realizza in sé tutte le funzionalità di cui ha bisogno Le uniche procedure non presenti nel programma sono costituite dall interfaccia verso l hardware del sistema operativo Programmi con funzioni di libreria Il programma attinge a codice esterno (librerie evolute di sistema operativo, librerie commerciali ) Si effettua una suddivisione logica delle operazioni Vengono definite interfacce software per la comunicazione tra programmi e librerie Nasce l esigenza di scrivere codice riciclabile 4 2

3 Evoluzione delle strategie di programmazione (2) Programmi ad oggetti Dalle librerie di funzioni si passa agli oggetti Possono esistere più istanze (oggetti) di una data interfaccia (classe): le istanze sono separate logicamente anche se presenti sullo stesso elaboratore Diventa più semplice progettare grossi applicativi software lavorando per componenti Per ridurre il time-to-market, diventa ancora più importante scrivere codice riciclabile 5 Evoluzione delle strategie di programmazione (3) Programmi distribuiti il programma viene suddiviso oltre che logicamente anche fisicamente in due o più unità funzionali Ciascuna unità può essere eseguita su calcolatori differenti purché in rete tra loro Occorre che le diverse unità riescano a parlarsi e a capirsi Diventa quindi indispensabile definire regole e formati di dati precisi (protocolli) e comuni a tutte le parti coinvolte 6 3

4 Sistemi distribuiti Componenti software distinti eseguiti su elaboratori distinti in grado di apparire come unico sistema Gli elaboratori possono essere Collocati arbitrariamente Omogenei o eterogenei Gestiti centralmente o in modo indipendente La diffusione di dispositivi (PC, cellulari, PDA, elettrodomestici intelligenti, ) e di connettività pervasiva (WLAN, GPRS, UMTS, ) esalterà ulteriormente la rilevanza di questo tipo di sistemi 7 Sistemi distribuiti: esempi Posta elettronica Telefonia (fissa e mobile) Domain Name Service (DNS) Web File system distribuiti Veicoli e case intelligenti 8 4

5 Sistemi distribuiti: caratteristiche (1) Condivisione di risorse Ogni elaboratore della rete offre potenzialmente le proprie capacità (risorse) a tutti gli altri elaboratori Supporto dell eterogeneità (apertura) Nella misura in cui i meccanismi di interazione sono noti e utilizzabili, è possibile fare interagire sottosistemi tra loro eterogenei (hardware, sistema operativo, componenti applicativi, ) Accesso concorrente Più attività possono svolgersi parallelamente attraverso la rete 9 Sistemi distribuiti: caratteristiche (2) Scalabilità Si può far crescere la potenza di calcolo aumentando le risorse presenti in rete Resilienza È possibile (necessario?) garantire il funzionamento del sistema anche in presenza di un malfunzionamento di una sua parte Trasparenza La suddivisione in sottosistemi è (dovrebbe essere) invisibile agli utenti finali 10 5

6 Sistemi distribuiti: limiti Complessità: diventa molto più difficile Progettare i sistemi Verificarne il comportamento Gestirli Sicurezza Molte più opportunità di forzare il comportamento dei sistemi a beneficio di terze parti Impredicibilità delle prestazioni Dipendenze da una molteplicità di fattori non controllabili (traffico, configurazione e politiche di gestione dei sistemi utilizzati, ) 11 Pattern 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 12 6

7 Programmi Client/Server Client e server sono programmi distinti non hanno quindi uno spazio di indirizzamento comune non sono possibili interazioni indirette tramite puntatori 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 Gestione degli accessi concorrenti sul server Trasformazione dei parametri in formati adatti ad essere trasportati attraverso la rete 13 Pattern di interazione Client/Server Vantaggi Il client può essere (relativamente) semplice e indipendente dalla specifica applicazione lo stesso client può essere usato per una molteplicità di scopi differenti Svantaggi Limiti nelle prestazioni: il server costituisce il collo di bottiglia o I possibili rimedi (duplicazione dei server, utilizzo di cache) creano ulteriori problemi (coerenza dei sistemi) 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? 14 7

8 Pattern di interazione Peer-to-Peer Un sistema distribuito in cui tutti i nodi hanno le stesse responsabilità ed 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 15 Client/server: architetture a due livelli Thin client (Interfaccia utente) Fat server (Logica applicativa + Base di dati) Fat client (Interfaccia utente + Logica applicativa) Thin server (Base di dati) 16 8

9 Limiti delle architetture a due livelli Scalabilità Traffico di keepalive in assenza di interazioni si stima tra 50 e 100 il numero massimo di connessioni accettabili Interoperabilità La piattaforma client e quella server devono essere compatibili Non esiste un client universale Difficoltà di amministrazione e configurazione Specialmente nel caso di fat client 17 Architetture a tre livelli Client: presentazione Interfaccia utente Server: logica di servizio Data Access Tier Application server DBMS 18 9

10 Architetture a tre livelli: obiettivi Garantire elevate Prestazioni Flessibilità (facilità di modificare un dato componente per utilizzarlo in altri contesti) Manutenibilità (facilità di eliminazione dei malfunzionamenti o di adattamento a nuovi requisiti) Riuso (possibilità di impiego in diverse piattaforme hardware e software) Scalabilità (possibilità di modificare un dato componente per far fronte ad una crescita delle dimensioni di un problema) Utilizzare dei meccanismi di interazione standard tra i diversi strati per nascondere al programmatore la complessità dell elaborazione distribuita 19 Presentation tier Fornisce all utente finale l accesso all applicazione Presenta le informazioni all utente e consente l introduzione e la manipolazione dei dati L interfaccia utente può essere costruita con elementi standard Costrutti HTML eventualmente arricchiti con codice di scripting o essere costituita da un programma tradizionale Maggiori funzionalità a scapito di una minor portabilità e versatilità dell architettura 20 10

11 Middle tier Definisce la logica applicativa del servizio: Gestisce i processi di autenticazione degli utenti e di autorizzazione Valida i dati e le richieste ricevuti dall interfaccia utente ed esegue i comandi Opera sui dati sottostanti, garantendone la coerenza e gestendo sessioni e transazioni Aggiorna il contenuto dell interfaccia utente in base allo stato globale del sistema È indipendente sia dalla piattaforma client (che, spesso, non è possibile imporre) che dal sistema di gestione della base dati (che impone, spesso, vincoli non marginali): È possibile cambiarne l implementazione/collocazione, per meglio rispondere alle esigenze del sistema 21 Data tier È lo strato che interagisce con il sistema di memorizzazione persistente dei dati (che può essere composto da uno o più DBMS) Può risiedere su calcolatori differenti rispetto quelli che ospitano il livello precedente Ha il compito di assicurare la coerenza dei dati in tutto l ambiente distribuito Locking dei dati Regole di consistenza Meccanismi di replicazione 22 11

12 Superare la barriera Come fanno, due programmi funzionanti su calcolatori differenti a comunicare tra loro? Astrazioni di basso livello Socket: disponibili pressoché in tutti i sistemi operativi Altri, dipendenti dalla specifica piattaforma (NamedPipe, MailSlot, ) Astrazioni di alto livello Paradigma Web (CGI e oltre) CORBA / RMI / DCOM JDBC / ODBC.NET 23 Astrazioni di basso livello Forniscono un meccanismo minimale che permette il trasferimento di informazioni da un applicazione ad un altra Ogni applicazione deve gestire esplicitamente tutti gli aspetti della comunicazione: Identificare l interlocutore Implementare un protocollo di comunicazione condiviso Gestire lo scambio di dati e gli eventuali malfunzionamenti Gestire i modo esplicito le risorse necessarie Vantaggi Massima flessibilità, potenziale efficienza Svantaggi Complessità 24 12

13 Astrazioni di alto livello Forniscono un insieme di funzioni a valore aggiunto che semplificano l interazione (middleware) Le applicazioni sfruttano l interfaccia applicativa offerta per mediare la comunicazione Vantaggi Semplificazione delle applicazioni Svantaggi Latenza Schemi di interazione più rigidi Potenziale dipendenza dalla piattaforma Costo 25 Middleware Applicazione 1 Applicazione 2 Middleware API Adattatore 1 Adattatore 2 Transport API OS OS Rete 26 13

14 Adattatori Schermano (in parte) le applicazioni dai dettagli di connessione Resta evidente il modello di comunicazione (peerto-peer o client/server) Vengono nascosti: Accesso alle funzionalità di trasporto (TCP, UDP, HTTP, ) Gestione dei flussi di elaborazione Conversione del formato dei parametri Possono offrire interfacce di tipo generico (sempre uguali, le applicazioni si adattano) specifico (si definisce l interfaccia tramite un apposito linguaggio da cui si ricavano, automaticamente gli adattatori) 27 14