Java Service Replication
Mattia Righini
Mat: 0000170738
Java Service Replication
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.
2
Java Service Replication
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.
3
Java Service Replication
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.
4
Java Service Replication
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.
5
Java Service Replication
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.
6
Java Service Replication
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.
7
Java Service Replication
Architettura (estensioni)
L’architettura così ottenuta può essere riassunta con il
seguente diagramma.
Providers
Servizio A
Client1
Providers
Servizio B
Richieste provenienti da Client1 e
Client3 competono
Client2
possono competere
per l’uso se
del
richiedono
Broker1
indipendentemente
lo stesso servizio.dal
Broker1
Broker2
servizio richiesto.
ClientN
BrokerN
Client2
Client3
8
Java Service Replication
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.
9
Java Service Replication
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.
10
Java Service Replication
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.
11
Java Service Replication
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
Creazione
Ready
Registrazione
Waiting
(inactive)
Deregistrazione
Attivazione
Working
(active)
Deregistrazione / Fallimento
12
Java Service Replication
Funzionalità Componenti: Broker
Funzionalità per i Client:
• Login
• Logout
• GetServiceList
• GetServiceInterface
• Lock/Unlock Service
• SendRequest
Funzionalità per i Provider:
• RegisterService
• UnRegisterService
• NotifyActivation
• GetCurrentStatus
• UpdateStatus
• ResetStatus
Queste operazioni possono essere
eseguite solo da Client che hanno
effettuato correttamente il Login.
Queste operazioni possono essere
eseguite solo dal Provider attivo.
13
Java Service Replication
Funzionalità Componenti: Provider
Funzionalità per i Broker:
• Alive
• Activate
• GetInterface
• GetStatus
• SetStatus
• SendRequest
• Lock/Unlock
Queste operazioni possono essere
eseguite solo sul Provider attivo.
14
Java Service Replication
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
15
Java Service Replication
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.
16
Java Service Replication
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.
17
Java Service Replication
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.
18
Java Service Replication
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
19
proprie dei ServiceManager.
Java Service Replication
Registrazione di un Provider
P
Broker1
Providers
Servizio A
Nuovo
Provider per
A
Broker2
GlobalId
Generator
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.
20
Java Service Replication
Riattivazione Servizio
2) gestione locale
7
Broker1
S(n)
Client
S(0)
1
2
S(0)
S(n)
9
S(0)
Providers
Servizio A
Broker2
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.
21
Java Service Replication
Checkpoint
2) gestione locale
5) updateStatus
7
Broker1
S(n+1)
S(n)
Client
S(0)
1
2
S(0)
9
S(0)
Providers
Servizio A
Broker2
La richiesta è stata servita e ha causato un aggiornamento dello stato.
Viene eseguito il Checkpoint sui Broker.
La risposta viene restituita.
22
Java Service Replication
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
23
Java Service Replication
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
24
da lock
