Java Service Replication

1
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
• Larchitettura proposta è stata realizzata in
  Java utilizzando RMI come metodo per la
  comunicazione e linterazione tra i componenti
  che la costituiscono.

3
Architettura Generale
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
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.
5
Ruolo dei Componenti

• Provider
• Entità che fornisce un determinato servizio.
• Ciascun servizio è caratterizzato da
• un nome
• uninterfaccia
• uno stato
• Linterfaccia 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
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 linsieme 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 allatto della registrazione presso un
  Broker devono invece specificare il tipo di
  servizio che intendono offrire.

7
Architettura (estensioni)
Essendo il Broker lentità centrale
dellarchitettura 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
dellarchitettura si è pensato di introdurre la
possibilità che più Broker possano gestire lo
stesso insieme di servizi.
8
Architettura (estensioni)
Larchitettura così ottenuta può essere riassunta
con il seguente diagramma.
Richieste provenienti da Client1 e Client3
possono competere se richiedono lo stesso
servizio.
Richieste provenienti da Client1 e Client2
competono per luso del Broker1 indipendentemente
dal servizio richiesto.
9
Caratteristiche
Modello di comunicazione La comunicazione fra i
componenti dellarchitettura è 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.
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
• Lattivazione è 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 allattivazione di un
  nuovo provider il servizio resta disponibile per
  i clienti fino a che esistono dei provider per
  esso.

11
Modello di replicazione dei servizi
Gestione dello stato La consistenza dello stato è
responsabilità dellazione 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 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
dellattivazione.
13
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.
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.
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 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 lidentificativo da assegnare
ad un nuovo Provider allatto della registrazione.
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
loperazione di registrazione dei Provider
bidirezionalmente. Unlock differita Per evitare
che un servizio rimanga bloccato a causa
dellimpossibilità di effettuare loperazione 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
dallinterfaccia 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 nellinterfaccia (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
1) registerService
P
2) getNextId
3) registerService
Nuovo Provider per A
Inizialmente il Provider non dispone di un
identificativo valido, per tale ragione il
Broker1 richiede lid da assegnare al servizio di
generazione degli identificativi. Il Servizio è
già noto quindi su entrambi i Broker non è
necessario creare il Manager corrispondente. Infin
e esistendo già un provider attivo per il
servizio loperazione di registrazione non è
seguita da quella di attivazione.
21
Riattivazione Servizio
2) gestione locale
1) sendRequest
4) alive
6) activate
5) setStatus
3) sendRequest
8) sendRequest
7
S(0)
S(n)
S(n)
12
9
7) notifyActivation
S(0)
S(0)
Providers Servizio A
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.
22
Checkpoint
2) gestione locale
5) updateStatus
1) sendRequest
3) sendRequest
7
S(0)
S(n)
S(n1)
12
9
4) updateStatus
S(0)
S(0)
Providers Servizio A
La richiesta è stata servita e ha causato un
aggiornamento dello stato. Viene eseguito il
Checkpoint sui Broker. La risposta viene
restituita.
23
Conclusioni

• Rispetto ad un normale C/S basato su RMI
  lutilizzo dellinfrastruttura sviluppata
  consente
• percezione di continuità di servizio a fronte di
  malfunzionamenti del rispettivo provider
• legame dinamico con linterfaccia 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

• Larchitettura 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