Modello di replicazione attivo e di
supporto alla tolleranza ai guasti in
ambito MOM
Autore: Claudio Fusconi
Matricola: 189269
Esame: Reti di calcolatori LS
Università di Bologna
Agenda










Scenario
Requisiti da soddisfare
JMS
Comportamento del sistema
Liste e Messaggi
Struttura del Client
Struttura del Server
Fault tolerance
Gestione invio risposte a i Client
Possibili sviluppi futuri
Scenario
Realizzare un sistema per la gestione di una coda di
messaggi tipo FIFO, rappresentante una lista
d’attesa, in cui un client può:
 Inserire un messaggio
 Cancellare un messaggio
Argomenti coinvolti:
 Replicazione attiva delle risorse
 Coordinamento tra copie
 Paradigma Publish/Subscriber per lo scambio dei
messaggi
Requisiti da soddisfare
Caratteristiche richieste dal sistema:
 tolleranza a i gusti
 trasparenza del grado di replicazione lato client
 nessuna forma di gestione centralizzata
 Indipendenza dal MOM
Ottenuta seguendo le specifiche JMS
Java Message Service (JMS)
Elementi di base per l’utilizzo del servizio di messaging:
Connection
Factory
Crea
Connection
Crea
Message
Producer
Session
Crea
Crea
Invia a
Crea
Message
Consumer
Ricevi da
message
Destination
(Topic)
Destination
(Topic)
Comportamento del sistema
Il JMS mette a disposizione un modello di comunicazione
Publish/Subscribe, basato su una figura destinazione chiamata
Topic (rapporto uno-a-molti)
ServerA
Fase 1: arrivo richiesta del client
ServerB
Client
ServerB
ServerC
ServerB
ServerC
Topic C
ServerA
Topic A
Fase 4: risposta al client
ServerA
Topic B
Fase 3: accordo tra server
Topic Richiesta
Fase 2: esecuzione operazione
ServerC
Liste e messaggi (1)
La lista è un vettore di oggetti (serializzabili) Prenotazione
Un ogetto Prenotazione contiene:
 un messaggio JMS
 un campo di tipo stringa (nome del client che lo ha creato)
Due possibili operazioni
sulla Lista:
■
■
inserisci
cancella
Posizione
Prenotazione
1
2
3
4
5
Kia
Sam
Tom
Mike
Joe
inserisci: Joe
Lista
Posizione
Prenotazione
1
2
3
4
5
Kia
Sam
Tom
Mike
Joe
Lista
Posizione
Prenotazione
1
2
3
4
Kia
Sam
Tom
Joe
Lista
cancella: Mike
Liste e messaggi (2)
JMS Message usati sia per la comunicazione C/S che
Server-to-Server. In JMS un Messaggio è formato da tre
parti:
 Header in cui risiedono informazioni sul messaggio
 Body che determina il tipo di messaggio
facoltativi
 Properties, insieme di coppie nome-valore
HEADER
JMSReplyTo:TopicTemp
BODY
Testo: inserisci
PROPERTIES
Client: Joe
Msg di richiesta
HEADER
HEADER
PROPERTIES
Client: Joe
Server: server-A
Posizione: 4
Msg d’informazione
PROPERTIES
Ack: true
Msg di Acknowledge
HEADER
BODY
Copia di Lista
Msg di ripristino
Struttura Client
La creazione di un client richiede di:
 creare una session con cui
costruire una Topic temporanea,
un Message Producer (publisher)
e un Message
Consumer(subscriber)
 effettuare un lookup alla Topic che
l’amministratore ha creato e
registrato nel namespace sotto il
nome di TopicRichiesta
 creare un messaggio di richiesta
 pubblicare il messaggio
 attendere l’arrivo di una risposta
Client
2- lookup
Namespace
Topic
A
1-crea
session
Publisher
Topic
Richiest
a
message
Subscriber
TempTopic
Struttura Server
Per realizzare un server si deve:
 creare una session da cui effettuare i
lookup alle Topic registrate
 creare un Message Receiver di tipo
asincrono e il relativo listener
 all’interno del metodo onMessage (che
viene sollevato dal listener in caso di
ricezione di un nuovo messaggio) si
devono creare una coppia di Message
Receiver sincroni e una coppia di
Message producer
 i Receiver creati devono attendere i
messaggi pubblicati sulle Topic con cui
gli altri server inviano i messaggi di
coordinazione
 un Producer dovrà inviare i messaggi
di coordinazione per gli altri server,
mentre l’altro Producer eventualmente
invierà il messaggio di risposta al client
tramite la Topic temporanea
Namespace
Server
Topic
B
Topic
A
2- lookup
1-crea
sessio
n
Lista
Topic
C
Topic
Richiest
a
Message
listener
Publisher
Subscriber
A
Subscriber
B
TempTopi
c
Fault tolerance(1)
ServerB
Result=A
Ack
Ack
Result=A
Client
iscrivi
risposta
Ack
Result=A
ServerA
Result=A
Ack
Ack
Result=A
Ack
Result=A
ServerC
Fault tolerance(2)
ServerB
Result=A
Ack
Ack
Result=A
Client
iscrivi
risposta
Result=A
ServerA
ripristino
Result=B
Result=B
se non vi è accordo tra le copie?
ripristino
Result=A
ServerC
Invio risposta al client di mancato servizio
Con tre copie della risorsa riesco a tollerare un guasto e a
rilevarne due.
Gestione invio risposte a i client
La gestione dell’invio dei messaggi tra server e
client è realizzato da un algoritmo che tiene
conto di:
 ultimi invii effettuati
 stato dei server
In questo modo si è sicuri che un client riceva
sempre una risposta e non vi siano punti di
centralizzazione nella comunicazione
server/client
Possibili sviluppi futuri

Aggiungere la possibilità di scegliere il tipo di gestione da
applicare alla Lista. Per esempio si potrebbe prevedere una
Lista che sia organizzata in un modello misto tra FIFO e
priorità dei messaggi.

Utilizzare XML per la creazione dei messaggi, sia di
richiesta che di risposta

creare un sistema di autenticazione dei clienti in modo da
garantire la riservatezza del servizio