Reingegnerizzazione di un’applicazione: da un modello single-user ad un’architettura distribuita tollerante ai guasti basata sul discovery dinamico dei.

Presentazione sul tema: "Reingegnerizzazione di un’applicazione: da un modello single-user ad un’architettura distribuita tollerante ai guasti basata sul discovery dinamico dei."— Transcript della presentazione:

1 Reingegnerizzazione di un’applicazione: da un modello single-user ad un’architettura distribuita tollerante ai guasti basata sul discovery dinamico dei servizi Reti di Calcolatori LS Ch.mo Professor Antonio Corradi Progetto di Gottardi Gianpaolo Matr. 197814

2 Motivazioni del progetto Introdurre un’infrastruttura per rendere distribuita un’applicazione single-user preesistente contemplando politiche di:  Fault tolerance, al fine di garantire il corretto funzionamento del sistema anche a fronte del guasti di un server;  Discovery dinamico dei servizi per rendere scalabile la soluzione proposta; Reti di calcolatori - 1

3 L’applicazione originale Si tratta di un prodotto sviluppato in C# demandato alla gestione a 360° di uno studio odontoiatrico (quindi pazienti, cartelle cliniche, appuntamenti, listini, fatture, report) con particolare attenzione all’aspetto legislativo. Da tempo il committente aveva espresso l’esigenza di poter utilizzare l’applicazione all’interno di una rete locale, garantendo l’accesso a più postazioni mobili contemporaneamente. Questo naturalmente ha richiesto una profonda rivisitazione del software precedente, portando al progetto di una nuova infrastruttura al cui interno si prevede l’assegnamento delle diverse funzionalità a più server cooperanti tra loro. Reti di calcolatori - 2

4 Soluzione precedente Una prima (e molto semplice) realizzazione prototipale prevedeva: la condivisone di un unico database, senza considerare l’eterogeneità dei servizi; la mutua esclusione degli accessi, garantita da un processo coordinatore centralizzato e noto a tutti i client; Naturalmente la soluzione era poco “robusta”: il server costituiva un single point of failure ed in caso di guasti gli effetti erano: o condizioni di deadlock permanente conseguente al rifiuto delle richieste di accesso al database; o corruzione dei dati, a causa del loro aggiornamento contemporaneo da parte di più client (in caso di intervento manuale dell’utente, tasto reset); Reti di calcolatori - 3 Purtroppo, entrambi gli aspetti vanificavano di fatto la validità dell’intero software….

5 Scelte tecnologiche (1) Per quanto riguarda l’ambiente di sviluppo, si prevede di mantenere quello del software originario, ovvero Visual Studio 2005 e il linguaggio C#. Non sono sorti in fase progettuale motivi sufficienti per spingere lo sviluppatore alla realizzazione di un’applicazione ibrida. Tale decisione è stata giustificata anche dalla disponibilità, nell’ambiente scelto, di un valido strumento di supporto alla programmazione distribuita: Microsoft.NET Remoting Reti di calcolatori - 4

6 Per le motivazioni riportate di seguito, la persistenza dei dati verrà garantita attraverso ADO.Net, Scelte tecnologiche (2) Reti di calcolatori - 5

7 Progetto (1) Da un punto di vista macroscopico, l’architettura elaborata prevede l’adozione del modello three-tier introducendo una netta separazione tra i livelli di presentazione (i client), di business (la logica applicativa mantenuta dai server) e di persistenza dei dati (database server). In particolare, la matrice sottostante deriva dall’applicazione del patter PAC. Reti di calcolatori - 6

8 Scalabilità e flessibilità sono stati i principi guida del processo di sviluppo: a tal fine è stato introdotto il DiscoveryServer per la pubblicazione dinamica dei servizi; La tolleranza ai guasti è garantita invece dall’adozione di un modello standby: si associa un componente detto Monitor ad ogni server, avente il compito di controllare periodicamente la liveness di quest’ultimo. In caso di guasto si provvede all’attivazione di una copia di standby del servizio, in maniera trasparente all’utente. Per l’accesso mutuamente esclusivo / concorrente / transazionale alla base dati, in fase progettuale si ritiene opportuno l’impiego di un database server commerciale, in quanto tali problematiche esulano dallo scopo del presente lavoro. Progetto (2) Reti di calcolatori - 7

9 L’architettura risultante è dunque la seguente: Progetto (3) Reti di calcolatori - 8 DB Server Discovery Server Client Manager Price-list manager Monitor Client Manager Standby copy Price-List Manager Standby copy Client election

10 La realizzazione di un prototipo funzionante, nel rispetto dei vincoli temporali imposti, ha richiesto due compromessi: impiego della tecnologia ADO.Net per la persistenza dei dati: l’adozione di un database server avrebbe richiesto infatti tempi di apprendimento / sviluppo / deployment troppo lunghi, per cui l’autore ha preferito introdurre database Access locali ai server, gestiti attraverso ADO.Net. A questa decisione segue la necessità del mantenimento della coerenza tra i dati gestiti dai server primari e quelli mantenuti dalla copia di standby. implementazione completa dell’infrastruttura di supporto, ma integrazione di un unico servizio completamente funzionante a disposizione del cliente: sempre per motivi di tempo e per non dover adottare soluzioni temporanee per la sincronizzazione dell’accesso a dati condivisi (in vista dell’introduzione di un apposito database server), il prototipo prevede l’erogazione di un unico servizio, ovvero quello demandato alla gestione dei pazienti dello studio odontoiatrico. Prototipo (1) Reti di calcolatori - 9

11 Reti di calcolatori - 10 Prototipo (2) Gestione della persistenza: ogni componente lavora sulla propria copia dei dati mediante un meccanismo basato su ADO.Net realizzato e testato da tempo dall’autore. In estrema sintesi, una libreria estende le funzionalità dei componenti propri del framework.Net consentendo non solo il mantenimento dell’associazione e della consistenza tra la base dati e il DataSet, ma anche la creazione automatica delle entità del business layer. Dal punto di vista prestazionale, a fronte di un transitorio iniziale dovuto al caricamento dell’intero database nel DataSet (residente in memoria principale) si ha un’estrema rapidità di esecuzione delle operazioni di aggiornamento dei dati, aspetto molto importante per la scelta delle politiche realizzate dal server. Si vuole sottolineare come il punto precedente richieda la specifica della sola linea di codice: StudioDocument _document = new StudioDocument();

12 Pur delegando all’apposita relazione una descrizione dettagliata dei singoli componenti dell’architettura, si presenteranno in seguito: I componenti Le entità responsabili del soddisfacimento dei requisiti funzionali: i server; I client per l’interazione con l’utente; Il DiscoveryServer per la pubblicazione dinamica dei servizi; Monitor e StandbyManager per garantire liveness e fault tolerance del sistema. Reti di calcolatori - 11

13 Cliente vs servitore (1) Segue l’interfaccia del server Client_manager demandato alla gestione dei pazienti: Reti di calcolatori - 12

14 I primi tre metodi permettono l’aggiornamento dei dati contenuti nel database e restituiscono all’utente un’indicazione della corretta esecuzione dell’operazione mendiante la classe Response; Get_client () consente il recupero di tutti i dati relativi ad un singolo paziente per la loro visualizzazione attraverso un’apposita form; Get_client_list() invece restituisce al client una lista di tutte e sole le informazioni necessarie al popolamento della ListView a fianco Cliente vs servitore (2) - Osservazioni L’introduzione dei due diversi metodi risponde all’esigenza di ottimizzare la comunicazione tra i due componenti. Reti di calcolatori - 13

15 La coppia di metodi di registrazione e deregistrazione consente l’implementazione di un meccanismo di call-back per segnalare ai client variazioni della lista dei pazienti: grazie alla serializzazione dei delegati offerta da.Net Remoting, ogni modifica al database si riflette nella generazione di un evento di tipo BasicEvent contenente sia un’indicazione dell’ azione, sia un’istanza della classe ThinyClient. I clienti registrati possono dunque aggiornare la propria lista, naturalmente attraverso un thread diverso da quello principale. Anche se il modello potrebbe sembrare troppo “accoppiato”, sono stati studiati diversi accorgimenti per limitare gli svantaggi di questa soluzione. Cliente vs servitore (3) - Osservazioni Reti di calcolatori - 14

16 Il metodo Print_client_report invia al server la richiesta di stampa di report relativi ad uno o più pazienti. La peculiarità di quest’operazione è l’attributo “OneWay()”: il processo di stampa è infatti computazionalmente oneroso e tipicamente richiede alcuni secondi. Possedendo un effetto visibile e potendo così discriminare facilmente sul successo o meno della richiesta, al metodo è stata associata una politica di tipo Fire&Forget : il client invoca l’operazione e prosegue nella computazione senza preoccuparsi di un eventuale valore di ritorno. Il server non si fa direttamente carico del servizio, ma lo delega ad un thread creato ex-novo. Il metodo Are_you_alive è connesso alla gestione della liveness del server, ed è presente nell’interfaccia al solo fine dichiarativo. Il server è registrato presso l’infrastruttura.Net Remoting come WellKnownObject in modalità Singleton. Per evitare problemi con eventuali firewall, si preferisce l’utilizzo del canale Http al Tcp; conseguentemente i messaggi di richiesta verranno inoltrati in formato Soap anzichè binario. Cliente vs servitore (3) - Osservazioni Reti di calcolatori - 15

17 Il Monitor, unico per ogni server, è chiamato a svolgere tre compiti: pubblicare il servizio interagendo con il DiscoveryServer; inviare periodicamente messaggi di heartbeating per assicurarsi della vitalità del server controllato; in caso di mancata risposta, aggiornare l’entry del DiscoveryServer ed attivare la copia di standby, attraverso il suo controllore (StandbyManager). Server vs Monitor (1) – Check della liveness Reti di calcolatori - 16 Il primo punto è espletato tramite l’invocazione del metodo Subscribe del DiscoveryServer. Il secondo mediante la creazione di un thread, responsabile dell’invio dei messaggi “Are you alive”. L’abilitazione della copia di standby invece avviene conseguentemente all’inoltro della richiesta di election al StandbyManager.

18 Lato server, per evitare di introdurre carico computazionale connesso a funzionalità che non riguardano la logica applicativa, è stato sviluppato un sink che filtra i messaggi in ingresso, costruisce la risposta alle richieste di liveness e l’invia al mittente senza interessare i livelli sovrastanti. Il sink (che di fatto realizza il pattern Interceptor) è posizionato immediatamente al di sopra del formatter in quanto lavora su messaggi e non stream di dati o envelope Soap. Lato client, è prevista una classe statica che ha il compito sia di gestire i servizi, attivando e rendendo disponibile a livello applicativo i remote refereces, sia di effettuare il Server vs Monitor (2) – Osservazioni recovery nel caso in cui si verifichino problemi di connessione con il server. Il funzionamento dell’intero sistema si basa sull’assunzione di affidabilità del mezzo trasmissivo, da cui risulta improbabile la perdita di messaggi. Si tratta di una supposizione verosimile in quanto l’ambiente di deployment sarà una piccola rete locale con non più di dieci client (come indicato dal committente). Reti di calcolatori - 17

19 Il componente è stato introdotto sia per una maggior scalabilità, sia per l’aggiornamento dinamico degli Url dei servizi (garantendo il recovery dei client). L’Url di un server è richiesto solo al primo accesso di un client. La lista dei servizi è implementata attraverso un’Hashtable formata dall’insieme delle coppie [NomeServizio,Url]. Non essendo prevista la persistenza dei dati, l’attivazione dev’esser necessariamente effettuata in modalità Singleton. Benché il prototipo preveda l’implementazione del solo Client_manager, rendendo equivalente l’impiego dei metodi Lookup_service() e Get_services(), l’utilizzo del secondo è consigliato per l’applicazione di release in quanto limita l’interazione tra i client ed il DiscoveryServer DiscoveryServer Reti di calcolatori - 18

20 A causa delle peculiarità del prototipo, il compito di questo componente non è solo l’attivazione della copia di standby di un server, ma StandbyManager e checkpointing (1) è anche responsabile dell’aggiornamento del database su cui essa opera, come si può notare dall’interfaccia a lato. Per il checkpointing è stato introdotto nel server primario un Updater_sink che provvede all’invocazione degli opportuni metodi: in maniera trasparente rispetto al livello applicativo; in modalità event-driven, dipendentemente dall’esito dell’operazione, analizzando il risultato dei livelli a monte. Reti di calcolatori - 19

21 L’attributo [OneWay()] dei metodi dell’interfaccia esplica la politica ottimista adottata; seguono le motivazioni alla base di questa scelta:  la fase di checkpointing è subordinata al successo dell’operazione sul server primario; un problema è segnalato all’utente ma non influenza il StandbyManager;  la limitata complessità delle operazioni di aggiornamento del DataSet rende remota la possibilità che il manager sollevi eccezioni durante tale fase, a meno di un suo fallimento totale;  il prototipo mira all’esposizione dell’intera architettura: sarebbero possibili numerosi accorgimenti per garantire l’allineamento delle copie, ma lo sforzo sarebbe vanificato dall’introduzione futura di un database server. StandbyManager e checkpointing (2) Reti di calcolatori - 20

22 La classe Configurator si occupa dell’attivazione sia del StandbyManager, sia della copia secondaria, mediante un meccanismo ad eventi:  La ricezione di un messaggio di election genera l’evento “Disable_server”;  Il relativo event handler è registrato dal metodo Configurator.Init_manager() che contemporaneamente attiva anche canale e servizio remoto (il StandbyManager);  In caso di elezione, l’event handler provvede alla disconnessione del manager dal canale di comunicazione e alla registrazione dinamica della copia di standby; Si sottolinea che il componente implementato può esser configurato sia come server primario, sia come copia secondaria, semplicemente agendo sul file di configurazione dell’applicazione (flag Is_primary_copy). StandbyManager e copia del servizio (2) Reti di calcolatori - 21

23 L’intero lavoro è stato svolto prestando particolare attenzione alla flessibilità e scalabilità del prodotto software: a tal fine, per ogni componente sono stati introdotti parametri di configurazione, modificabili dall’amministratore di sistema. Il prototipo, seppur limitato nei servizi, ha portato all’arricchimento dell’autore sotto diversi aspetti:  sperimentazione delle problematiche affrontate nel corso di Reti d.C.;  acquisizione di esperienza in merito a “nuove” tecnologie, come Microsoft.Net Remoting;  confronto diretto con il cosiddetto “chatty vs. chunky trade-off”;  definizione di un modello sufficientemente “robusto” per soddisfare le richieste del committente e contemporaneamente limitare gli interventi futuri del programmatore. Conclusioni Reti di calcolatori - 22

24 Sviluppi futuri Seguono alcune linee guida per evoluzioni future del prodotto (in ordine di priorità): introduzione di un database sever per il superamento delle limitazioni del prototipo; implementazione degli innumerevoli servizi previsti dall’applicazione originale e loro integrazione nell’architettura progettata; sviluppo di un LogServer per unificare la raccolta di informazioni in merito sia al funzionamento normale del sistema, sia all’occorrenza di guasti; utilizzo di nuovi interceptor e dei contesti per garantire l’identificazione degli utenti e la sicurezza dei loro accessi; realizzazione di canali di trasporto personalizzati per problematiche connesse alla privacy dei pazienti, adottando a tal scopo strumenti per crittografare i flussi di dati; perfezionamento del deployment, con avvio automatico in background dei vari server al boot del sistema operativo; Cessione (dietro compenso) del prodotto finale al committente. Reti di calcolatori - 23