Java Service Replication Mattia Righini Mat: 0000170738.

Java Service Replication

Mattia Righini

Mat: 0000170738

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.

3


Architettura Generale

Client BrokerProvidersServizio 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.

4


Ruolo dei Componenti

ClientEntità 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.

5



ProviderEntità 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.

6



BrokerEntità 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.

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.

8


Architettura (estensioni)

L’architettura così ottenuta può essere riassunta con il seguente diagramma.

Client1

Broker1

ProvidersServizio A

Broker2 BrokerN

ProvidersServizio 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.

9


Caratteristiche

Modello di comunicazioneLa 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.

LockingPossibilità 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.

10


Modello di replicazione dei serviziIl 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.

11


Modello di replicazione dei serviziGestione dello statoLa 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.

12


Modello di replicazione dei serviziControllo del Master e ruolo degli SlaveAltra 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

Ready Waiting (inactive)

Working (active)

Creazione Registrazione

Attivazione

Deregistrazione

Deregistrazione / Fallimento

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.

14


Funzionalità Componenti: ProviderFunzionalità per i Broker:

• Alive• Activate• GetInterface• GetStatus• SetStatus• SendRequest• Lock/Unlock

Queste operazioni possono essere eseguite solo sul Provider attivo.

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

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 ProviderSi è 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.

17


Implementazione (note)

Duplicazione di un BrokerPer 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 differitaPer 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.

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.

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.

20


Registrazione di un Provider

Broker1 ProvidersServizio A

Broker2GlobalIdGenerator

P

Nuovo Provider per

A

1) registerService2) 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.

21


Riattivazione Servizio

Broker1

Broker2

7

12

9

ProvidersServizio 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) alive6) activate

7) notifyActivation

8) sendRequest

5) setStatusS(n)

S(0) S(0)

S(0)S(n)

22


Checkpoint

Broker1

Broker2

7

12

9

ProvidersServizio 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(0)

S(0)S(n+1)

5) updateStatus

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

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

Java Service Replication Mattia Righini Mat: 0000170738.

Documents