Modello di replicazione attivo e di supporto alla tolleranza ai guasti in

ambito MOM

Autore: Claudio FusconiMatricola: 189269

Esame: Reti di calcolatori LSUniversità 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

Argomenti coinvolti:Replicazione attiva delle risorseCoordinamento tra copieParadigma Publish/Subscriber per lo scambio dei

messaggi

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

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

Connection

Factory

ConnectionConnection

Crea

SessionSession

Crea

MessageProducerMessageProducer

Crea

MessageConsumerMessageConsumer

CreaInvia a

Destination(Topic)

Ricevi da

Destination(Topic)

Crea

message

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)

Fase 1:

Fase 2:

Fase 3:

Fase 4:

Client Topic R

ichiesta

ServerA

ServerC

ServerB

arrivo richiesta del client

risposta al client

ServerA ServerCServerB

Topic A

Topic B

Topic C

accordo tra server

ServerA ServerCServerBesecuzione operazione

Liste e messaggi (1)

La lista è un vettore di oggetti (serializzabili) PrenotazioneUn ogetto Prenotazione contiene: un messaggio JMS un campo di tipo stringa (nome del client che lo ha creato)

Lista

Posizione

Prenotazione

1

Kia

2

Sam

3

Tom

4

Mike

5

Joeinserisci: Joe

Due possibili operazioni sulla Lista:

■

■

inseriscicancella cancella: Mike

Lista

Posizione

Prenotazione

1

Kia

2

Sam

3

Tom

4

Mike

5

Joe

Posizione

Prenotazione

1

Kia

2

Sam

3

Tom

4

Joe

Lista

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 Properties, insieme di coppie nome-valore facoltativi

PROPERTIESClient: Joe

BODYTesto: inserisci

HEADERJMSReplyTo:TopicTemp

Msg di richiesta

PROPERTIESClient: JoeServer: server-APosizione: 4

HEADER

Msg d’informazione

PROPERTIESAck: true

HEADER

Msg di Acknowledge

BODYCopia di Lista

HEADER

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

session

Subscriber

Publisher

Topic Richiesta

TempTopic

Client

1-crea

2- lookup NamespaceTopicA

message

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

session

Topic Richiest

a

TempTopic

1-crea

2- lookup

Namespace

TopicB

Server TopicA

TopicC

Message listener

PublisherSubscriber

B

SubscriberA

Lista

ServerC

ServerB

Fault tolerance(1)

ServerAClient

Result=A

Result=A

Result=A

Result=A

Result=A

Result=Aiscrivirisposta

AckAck

Ack

Ack

Ack

Ack

ServerC

ServerB

Fault tolerance(2)

ServerAClient

Result=A

Result=A

Result=A

Result=A

Result=B

Result=B

AckAck

ripristino

ripristinoiscrivirisposta

se non vi è accordo tra le copie?

Con tre copie della risorsa riesco a tollerare un guasto e a rilevarne due.

Invio risposta al client di mancato servizio

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