Reti di calcolatori LS1 Service Middleware Reti di calcolatori LS progetto di Andrea Belardi Infrastruttura dedicata alla gestione di servizi disponibili.

Presentazione sul tema: "Reti di calcolatori LS1 Service Middleware Reti di calcolatori LS progetto di Andrea Belardi Infrastruttura dedicata alla gestione di servizi disponibili."— Transcript della presentazione:

1 Reti di calcolatori LS1 Service Middleware Reti di calcolatori LS progetto di Andrea Belardi Infrastruttura dedicata alla gestione di servizi disponibili in una rete locale

2 Reti di calcolatori LS2 Obiettivi del progetto Fissare attraverso la realizzazione di un progetto le idee e le nozioni apprese durante il corso. Realizzare un’infrastruttura che permetta agli utenti finali di offrire servizi dedicati a tutti gli utenti della rete locale e usufruire di tutti i servizi messi a disposizione all’interno della stessa. Individuare le problematiche connesse alla progettazione e implementazione di tale infrastruttura proponendo delle soluzioni valide e ragionate.

3 Reti di calcolatori LS3 Requisiti generali del sistema L’utente accederà al sistema da un calcolatore appartenente ad una rete locale di calcolatori. Il calcolatore dovrà essere collegato all’infrastruttura responsabile della rete di host del sistema di gestione dei servizi. L’utente potrà in ogni istante decidere di attivare un servizio e renderlo disponibile a tutta la rete, oppure di cercare e utilizzare un servizio già attivo su un altro calcolatore. L’infrastruttura responsabile della gestione dei servizi deve fornire una visione assolutamente trasparente per quanto riguarda servizi attivi in locale o su calcolatori remoti.

4 Reti di calcolatori LS4 Gestione della rete di calcolatori E’ stato scelto un sistema di controllo centralizzato. Il master mantiene una lista aggiornata dei servizi attivi nella rete e riceve e risponde alle richieste di tutti gli host collegati all’infrastruttura. Service 1 add 1 Service 2 add 2... Start service xxx Or Stop service xxx Search service xxx Sono previsti, inoltre, due controllers: il loro compito è quello di verificare il corretto funzionamento del master e dell’altro controller attraverso dei messaggi inviati a intervalli regolari. Is ok? All ok Is ok? All ok Il primo dei controllers ha inoltre la responsabilità di mantenere in memoria una lista aggiornata dei servizi attivi. Tale lista verrà aggiornata ad ogni modifica della lista del master allo scopo di averne sempre una copia consistente. Updated list of services Update list

5 Reti di calcolatori LS5 Utilizzo dei servizi (1/2) Si è scelto di implementare un modello centralizzato. Il MASTER avrà il compito di tenere una lista aggiornata dei servizi offerti dai calcolatori collegati alla rete gestita dall’infrastruttura. I calcolatori avvisano il master all’attivazione o disattivazione di ogni servizio, per permettergli di mantenere la lista aggiornata. Quando l’utente effettua una ricerca dei servizi disponibili all’interno della rete, viene inviata una richiesta al master. Questi invia, in risposta, una lista con i servizi attivi che fanno match con la chiave di ricerca. Per ognuno di essi viene indicato l’indirizzo del calcolatore su cui è attivo.

6 Reti di calcolatori LS6 Utilizzo dei servizi (2/2) Quando l’utente sceglie il servizio desiderato dalla lista ottenuta, viene inviata una richiesta di servizio al calcolatore remoto. In risposta viene ricevuto un oggetto contenente le informazioni necessarie all’utente per l’utilizzo del servizio (descrizione del servizio, nome e descrizione dei parametri necessari, ecc..). All’utente viene quindi presentata una GUI, contenente tutti i campi di inserimento destinati a ricevere i parametri e le informazioni inviate dal calcolatore remoto. Quando l’utente completa l’inserimento dei parametri, viene inviata la richiesta al calcolatore remoto, che esegue il servizio localmente e ne invia il risultato all’utente.

7 Reti di calcolatori LS7 Gestione degli errori In fase di progettazione si è tenuta in considerazione la possibilità di errori. L’infrastruttura è quindi dotata di meccanismi che possano risolvere tali situazioni. Nell’implementare questi meccanismi, si è sfruttata la ben nota ipotesi di guasto singolo, che ci ha condotto allo sviluppo delle seguenti tecniche di rilevazione e risoluzione dell’errore: –Per rilevare e risolvere gli errori del master, è stato sufficiente prevedere 2 controllers e dei messaggi di controllo lanciati a intervalli regolari. In caso di guasto uno dei controller eseguirà una procedura per sostituire il master e garantire così un corretto funzionamento agli occhi dell’utente. –Per assicurare la corretta gestione dei servizi è necessario prevedere almeno una copia aggiornata della lista dei servizi attivi sul master.

8 Reti di calcolatori LS8 Diagramma delle classi (net control) Ogni calcolatore, al momento della connessione all’infrastruttura, istanzia un oggetto della classe GenericHost. Nel caso l’host sia il primo a connettersi, assume il ruolo del master e viene creata un’istanza di MasterStructure. Se, invece, dovessero mancare dei controller, l’host ne assumerà il ruolo istanziando un oggetto ControllerStructure.

9 Reti di calcolatori LS9 Diagramma delle classi (service control) Ogni calcolatore, attiva un thread che serva le richieste per i servizi attivati e disponibili; per questo mantiene una lista con le interfacce di ogni servizio. Il master mantiene una lista di tutti i servizi attivi e degli indirizzi su cui risiedono. Un thread gestisce le richieste degli host remoti, che possono cercare, attivare o fermare un servizio. Il primo controller mantiene una copia aggiornata della lista di servizi e indirizzi del master.

10 Reti di calcolatori LS10 Test Una serie di test (assolutamente non esaustivi) sono stati eseguiti, in fase di implementazione del prototipo, per testare il corretto funzionamento dei componenti implementati. Il test conclusivo è stato eseguito in una rete locale wireless, e gli host connessi all’infrastruttura di gestione dei servizi erano 5 (quindi 1 master, 2 controller e due host generici). L’implementazione dei 2 semplici servizi SumService e ProductService era finalizzata all’esecuzione del test. Il comportamento del prototipo ha esaudito le nostre attese; escludendo alcuni semplici bug, che sono stati eliminati prontamente, l’infrastruttura svolge le sue funzioni adeguatamente. Anche i tempi di attesa del servizio percepiti dall’utente sono risultati in linea con le attese.

11 Reti di calcolatori LS11 Conclusioni e sviluppi futuri Alla luce dei test eseguiti, il sistema risulta rispondente ai requisiti formulati all’inizio della fase di progettazione. L’infrastruttura si è rivelata sufficientemente robusta e in grado di rimediare ai possibili guasti del master e dei controllers. Nell’ipotizzare uno sviluppo futuro, un aspetto fondamentale sicuramente sarà quello della scalabilità: –La versione attuale non prevede nessuna meccanismo per un facile allargamento del sistema oltre la piccola rete locale per il quale è stata progettata; –Si possono ipotizzare però semplici meccanismi da integrare all’infrastruttura. La creazione di gateway responsabili di comunicare con altre reti locali può ovviare alla fragilità di un’infrastruttura completamente centralizzata portando alla creazione di un sistema ibrido (reti locali con ognuna il proprio master e con gateway responsabili di gestire la comunicazione extra-rete).