Java Service Replication Mattia Righini Mat:

Java Service Replication 2 Obiettivi Il progetto si propone di realizzare una semplice infrastruttura che: consenta la fruizione mediata di servizi garantisca una continuità di servizio in presenza di fault o disconnessione del corrispondente provider L’architettura proposta è stata realizzata in Java utilizzando RMI come metodo per la comunicazione e l’interazione tra i componenti che la costituiscono.

Java Service Replication 3 Architettura Generale Client Broker Providers Servizio A Principio Base: Un Client che necessita di un determinato servizio non accede direttamente ad esso ma si rivolge ad un mediatore (Broker) il quale si incarica di inoltrare le richieste al fornitore del servizio e di recapitarne le relative risposte.

Java Service Replication 4 Ruolo dei Componenti Client Entità che necessità di uno o più servizi esterni per la propria logica applicativa. Per ottenere tali servizi si rivolge ad una entità detta Broker. Prima di effettuare qualunque richiesta al Broker il Client deve identificarsi, in tal modo il Broker può applicare politiche diverse di gestione delle richieste a seconda della rispettiva provenienza.

Java Service Replication 5 Ruolo dei Componenti Provider Entità che fornisce un determinato servizio. Ciascun servizio è caratterizzato da: un nome un’interfaccia uno stato L’interfaccia specifica quali richieste possono essere inviate al provider e con quali modalità. Lo stato di un servizio può influenzare le risposte fornite da un provider e riassume le interazioni passate.

Java Service Replication 6 Ruolo dei Componenti Broker Entità mediatrice fra Client e Provider. Disaccoppia le due classi di entità e ha la responsabilità di: gestire le richieste provenienti dai Client gestire l’insieme dei provider disponibili Il Broker è pensato per gestire diversi tipi di servizi, è quindi necessario che i Client possano: verificare quali siano i servizi disponibili effettuare richieste verso specifici servizi I Provider all’atto della registrazione presso un Broker devono invece specificare il tipo di servizio che intendono offrire.

Java Service Replication 7 Architettura (estensioni) Essendo il Broker l’entità centrale dell’architettura ed essendo presumibile la presenza di molti Client e molti servizi (ciascuno con il proprio insieme di Provider) risulta evidente come questo componente possa costituire il collo di bottiglia del sistema, per tale ragione fin dalle prime fasi di progetto dell’architettura si è pensato di introdurre la possibilità che più Broker possano gestire lo stesso insieme di servizi.

Java Service Replication 8 Architettura (estensioni) L’architettura così ottenuta può essere riassunta con il seguente diagramma. Client1 Broker1 Providers Servizio A Broker2BrokerN Providers Servizio B Client2 ClientN Client3 Richieste provenienti da Client1 e Client3 possono competere se richiedono lo stesso servizio. Richieste provenienti da Client1 e Client2 competono per l’uso del Broker1 indipendentemente dal servizio richiesto.

Java Service Replication 9 Caratteristiche Modello di comunicazione La comunicazione fra i componenti dell’architettura è di tipo sincrono, ovvero considerando due componenti uno “client” e uno “server”, il client dopo aver effettuato una richiesta al server rimane in attesa della risposta. Locking Possibilità da parte di un Client di ottenere un lock esclusivo su di un servizio, attraverso tale operazione il sistema garantisce che solo richieste provenienti da tale Client saranno servite mentre richieste provenienti da altri Client rimarranno in attesa che il lock venga rimosso.

Java Service Replication 10 Modello di replicazione dei servizi Il modello scelto per la replicazione dei servizi è un modello di tipo passivo a copie calde. Per un determinato servizio:  esiste un insieme di Provider disponibili  in un determinato istante uno e uno solo di questi è attivo  i Broker che gestiscono il servizio rivolgono le richieste sempre verso il provider attivo L’attivazione è sotto il controllo dei Broker, nel momento in cui il provider correntemente attivo sperimenta un fault il Broker che rileva per primo il fault provvede all’attivazione di un nuovo provider; il servizio resta disponibile per i clienti fino a che esistono dei provider per esso.

Java Service Replication 11 Modello di replicazione dei servizi Gestione dello stato La consistenza dello stato è responsabilità dell’azione congiunta dei Brokers e del Provider attivo; a differenza degli schemi classici di replicazione passiva il checkpoint è infatti effettuato dal Provider attivo (master) non sulle copie inattive (slave) ma sui Broker. Ogni Broker mantiene quindi una copia dello stato di ciascun servizio gestito; tale copia, aggiornata durante le operazioni di checkpoint, viene utilizzata durante le operazioni di riattivazione, cioè nel momento in cui il provider correntemente attivo deve essere sostituito con uno nuovo.

Java Service Replication 12 Modello di replicazione dei servizi Controllo del Master e ruolo degli Slave Altra differenza rispetto agli schemi classici di replicazione passiva è Il controllo del corretto funzionamento del provider attivo, tale controllo infatti non è affidato ai provider inattivi ma ai Broker. Dalle affermazioni precedentemente fatte si deduce che il ruolo delle copie slave nel sistema si limita al rendersi disponibile a fornire il servizio e a restare in attesa dell’attivazione. Diagramma di Stato di un Provider

Java Service Replication 13 Funzionalità per i Client: Login Logout GetServiceList GetServiceInterface Lock/Unlock Service SendRequest Funzionalità per i Provider: RegisterService UnRegisterService NotifyActivation GetCurrentStatus UpdateStatus ResetStatus Funzionalità Componenti: Broker Queste operazioni possono essere eseguite solo da Client che hanno effettuato correttamente il Login. Queste operazioni possono essere eseguite solo dal Provider attivo.

Java Service Replication 14 Funzionalità Componenti: Provider Funzionalità per i Broker: Alive Activate GetInterface GetStatus SetStatus SendRequest Lock/Unlock Queste operazioni possono essere eseguite solo sul Provider attivo.

Java Service Replication 15 Implementazione Come già accennato in precedenza il sistema è stato implementato in Java; come meccanismo di comunicazione/interazione è stato utilizzato RMI. Broker e Provider sono stati modellati come interfacce remote: IServiceBroker: interfaccia del Broker utilizzata dai Client IReplicationManager: interfaccia del Broker utilizzata dai Provider IReplicableService: interfaccia del Provider

Java Service Replication 16 Implementazione (note) Analizzando le interfacce citate si possono notare alcune funzionalità aggiuntive rispetto al modello presentato in precedenza, tali funzionalità sono state introdotte a seguito di alcune scelte progettuali. Identificazione univoca Provider Si è scelto di dotare ogni Provider di un identificativo univoco, tale identificativo è sfruttato principalmente per facilitare le operazioni di attivazione. Per la generazione degli identificativi viene utilizzato un servizio base (servizio replicato gestito esattamente come gli altri servizi) al quale i Broker richiedono l’identificativo da assegnare ad un nuovo Provider all’atto della registrazione.

Java Service Replication 17 Implementazione (note) Duplicazione di un Broker Per semplificare il supporto a Broker multipli si sono aggiunte al Broker funzionalità che consentono ad un altro Broker di gestire gli stessi servizi gestiti dal primo, inoltre è possibile effettuare l’operazione di registrazione dei Provider bidirezionalmente. Unlock differita Per evitare che un servizio rimanga bloccato a causa dell’impossibilità di effettuare l’operazione di unlock (per indisponibilità di provider) è stata introdotta la possibilità di differire tale operazione nel tempo.

Java Service Replication 18 Implementazione base di IReplicableService Per semplificare lo sviluppo di servizi è stata realizzata una classe astratta (AReplicableService) che implementa tutti i metodi previsti dall’interfaccia IReplicableService, il servizio ottenuto estendendo tale classe è un servizio di tipo sequenziale con checkpoint event-driven eseguito ad ogni cambio di stato. I metodi presenti nell’interfaccia (quella esposta ai Client) devono corrispondere a metodi pubblici della classe stessa, il codice della classe astratta invoca dinamicamente il metodo desiderato utilizzando la riflessione di Java.

Java Service Replication 19 ServiceManager locali ai Broker Per ogni servizio gestito è presente sul Broker un oggetto a cui è affidata la gestione locale delle richieste e la gestione dei Provider. Tali oggetti vengono chiamati ServiceManager, sono stati sviluppati due tipi di Manager: QueueLessServiceManager: serve le richieste con politica FCFS senza tener conto delle priorità dei Client richiedenti QueuedServiceManager: organizza le richieste in tante code quanti sono i livelli di priorità gestiti Entrambi i Manager sono sottoclassi della classe astratta AServiceManager che fornisce alcune funzionalità base proprie dei ServiceManager.

Java Service Replication 20 Registrazione di un Provider Broker1 Providers Servizio A Broker2 GlobalId Generator P Nuovo Provider per A 1) registerService 2) getNextId 3) registerService Inizialmente il Provider non dispone di un identificativo valido, per tale ragione il Broker1 richiede l’id da assegnare al servizio di generazione degli identificativi. Il Servizio è già noto quindi su entrambi i Broker non è necessario creare il Manager corrispondente. Infine esistendo già un provider attivo per il servizio l’operazione di registrazione non è seguita da quella di attivazione.

Java Service Replication 21 Riattivazione Servizio Broker1 Broker Providers Servizio A 1) sendRequest 3) sendRequest Il Provider attivo sperimenta un fault. Broker1 rileva il fault e verifica se il provider attivo è funzionante o meno. Non ricevendo risposta il Broker procede alla riattivazione, viene attivato il Provider inattivo con il valore di identificativo minore. La richiesta effettuata non comporta modifiche dello stato dal momento che non è evidenziata alcuna operazione di updateStatus. Client 2) gestione locale 4) alive 6) activate 7) notifyActivation 8) sendRequest 5) setStatus S(n) S(0) S(n)

Java Service Replication 22 Checkpoint Broker1 Broker Providers Servizio A 1) sendRequest 3) sendRequest La richiesta è stata servita e ha causato un aggiornamento dello stato. Viene eseguito il Checkpoint sui Broker. La risposta viene restituita. Client 2) gestione locale 4) updateStatus S(n) S(0) S(n+1) 5) updateStatus

Java Service Replication 23 Conclusioni Rispetto ad un normale C/S basato su RMI l’utilizzo dell’infrastruttura sviluppata consente: + percezione di continuità di servizio a fronte di malfunzionamenti del rispettivo provider + legame dinamico con l’interfaccia del servizio + possibilità di uso esclusivo del servizio + eventuale gestione di priorità e permessi - maggiore complessità nella richiesta di servizio - possibile calo di prestazioni - necessità di gestire una disponibilità variabile nel tempo del servizio

Java Service Replication 24 To do L’architettura proposta consente di mascherare eventuali fault sperimentati dai Provider, tuttavia essendo il binding fra un Client e un Broker fisso eventuali fault del Broker sono visti direttamente dai Client. Questo problema può essere arginato utilizzando schemi di replicazione fisica; come prima possibilità di sviluppo va comunque considerata quella di introdurre un ulteriore livello di trasparenza. Altri possibili sviluppi possono essere:  modalità asincrone di invocazione  possibilità di gestire parametri che siano sia in input che in output  prevenzione o gestione di eventuali deadlock causati da lock