Corso di Laurea in Ingegneria Informatica L-S
Anno Accademico 2007-2008
Live auction
un’ infrastruttura di supporto
per aste in tempo reale
basata su JMS.
Autore: Andrea Ceruti
Matricola: 0000223986
Corso: Reti Di Calcolatori L-S
Docente: Prof. Antonio Corradi
Introduzione




Live Auction vuole riprodurre l’esperienza di un’ asta in
sala su internet, ovvero ricostruire una sala virtuale
distribuita sul web.
Si è deciso che fosse prioritario permettere alle varie
parti del sistema di lavorare in modo indipendente le une
dalle altre, per quanto possibile.
Sono due le tipologie di utente che interagiscono col
sistema:
 L’ offerente (bidder).
 L’ amministratore (admin).
Ciascuno di questi tipi di utente ha a disposizione una
diversa applicazione per interagire col sistema.
Obiettivi


Applicazione Admin: usata dal battitore dell’
asta, ha come obiettivo quello di fornire
informazioni agli offerenti riguardo i lotti oggetto
dell’ asta e di ricevere da questi informazioni
sulle offerte.
Applicazione Bidder: usata dagli offerenti
distribuiti su diversi nodi. Riceve informazioni sui
lotti oggetto dell’ asta ed ha come obiettivo
quello di fornire informazioni al battitore e agli
altri offerenti sulle relative offerte.
Caratteristiche della comunicazione

Comunicazione push based di tipo molti a molti.


Numero di client non noto a priori.


I partecipanti all’ asta possono essere numerosi.
Asincronicita’:


Sia bidder che admin sono produttori e consumatori di informazioni.
le parti devono poter comunicare con successo anche se non sono tutte
presenti all’atto della comunicazione.
Affidabilita:

la comunicazione deve essere affidabile, anche su reti non affidabili,
così che le informazioni non vengano perse. Un’ evenutale perdita di
informazioni e’ infatti da considerarsi inaccettabile dal momento che i
messaggi rappresentano transazioni economiche.
Infrastruttura Middleware


Considerate le caratteristiche della comunicazione sono state escluse
tecnologie come RMI, RPC che, oltre ad essere sincrone, richiedono
una connessione fisica attiva fra il client e il server.
Un middleware orientato ai messaggi si adatta bene alle
caratteristiche di disaccoppiamento cercate:

permette alle applicazioni di comunicare tramite DESTINAZIONI che non
richiedono la presenza contemporanea di mittente e destinatario affinché la
consegna avvenga con successo;
 permette alle applicazioni di ricevere messaggi in modo asincrono rispetto al
flusso di esecuzione dell’applicazione stessa;
 supporta il modello di gestione dei messaggi publish/subscribe adatto ad una
comunicazione uno a molti o molti a molti.

Le API JMS permettono di accedere ai servizi dei messagging
system

fornendo un metodo standard tramite il quale le applicazioni possono creare,
inviare e ricevere messaggi usando un sistema MOM.
JMS – generalita’


Queue (coda) :
realizza il modello di
comunicazione pointto-point
Topic (topic): realizza
il modello di
comunicazione
publish-subscribe
Architettura logica del sistema


Il nucleo centrale del sistema è composto da un
topic in cui l’ Admin è publisher di un messaggio
chiamato Status contenente le informazioni sui
lotti correnti e i bidder sono i subscriber
interessati a ricevere questo messaggio.
A loro volta i bidder sono publisher di un
messaggio chiamato Bid contenente
informazioni sulle offerte effettuate e l’ Admin è il
subscriber interessato a ricevere questo
messaggio.
Architettura logica del sistema
Struttura dei messaggi
Bidder e Admin creano degli oggetti TextMessage che incapsulano un
documento XML come stringa Java.
<LiveAuctionMessage>
<Action> Bid </Action>
<BidderName> Andrea </BidderName>
<LotId> 1 </LotId>
<Base> 200 </Base>
<Price> 250 </Price>
<Title> moneta romana 2 secolo a.c.
</Title>
</LiveAuctionMessage>
<LiveAuctionMessage>
<Action> Status </Action>
<CurrentLot> 1 </CurrentLot>
<Base> 200 </Base>
<Title> moneta romana 2 secolo a.c.
</Title>
<CurrentPrice> 250 </CurrentPrice>
<CurrentWinner> Andrea
</CurrentWinner>
</LiveAuctionMessage>
Pubblicazione dei messaggi



In fase di pubblicazione il publisher setta il Delivery Mode a
PERSISTENT per evitare la perdita di messaggi in caso di caduta
del provider. Il JMS provider ActiveMQ si occupa di memorizzare i
messaggi in opportune tabelle.
Le sottoscrizioni sono state rese durevoli, in modo da consentire la
ricezione dei messaggi anche se il client non era in ascolto al
momento della generazione del messaggio.
L’identificazione univoca del subscriber consente in caso di crash
del JMS provider e successivo riavvio, di effettuare il resume del
subscriber dallo stato in cui era stato lasciato precedentemente,
riprendendo la ricezione dei messaggi.
Guaranteed Message Delivery
Message Selectors



Vengono specificati in fase di invio del messaggio ed in fase di
creazione del consumatore.
In fase di creazione del messaggio si aggiunge ad esso una string
property di tipo ACTION, il cui valore, settato a ‘bid’ o ‘status’,
identifica l’applicazione interessata alla ricezione del messaggio
stesso.
Dal lato subscriber, in fase di creazione di una sottoscrizione
durevole, il metodo createDurableSubscriber permette di specificare
come argomento il valore del selector: solo i messaggi con property
corrispondente al valore del selector vengono consegnati dal
provider JMS.
l’ onere di filtrare I messaggi spetta al provider JMS:



ottimizzazione del traffico di rete
semplificazione del codice.
Ricezione dei messaggi


La sessione di un subscriber è caratterizzata dalla
modalità AUTO_ACKNOWLEDGE.
Politica della consegna dei messaggi once-and-onlyonce.


ottimizzazione del traffico di rete
Il subscriber definisce un message listener e ridefinisce
il metodo onMessage(). Quando un messaggio arriva
alla destinazione d'interesse, il provider JMS provvede
ad invocare in maniera asincrona il metodo di callback
onMessage(), alla cui esecuzione la sessione riconosce
automaticamente il messaggio.
Servizio di login



Il nucleo centrale del servizio
di login è costituito da due
code unidirezionali,
loginQueue e confirmQueue, e
da due attori, ovvero il Bidder
che si vuole autenticare e un
servizio autenticatore lato
server.
Messaggio di LogIn e
messaggio di Confirm
TimeToLive per entrambi i tipi
di messaggi per evitare che, in
caso di failure del servizio di
autenticazione, non rimangano
messaggi inevasi nelle code.
<LiveAuctionMessage>
<Action> LogIn </Action>
<BidderName> Andrea </BidderName>
<BidderPassword> xxxxx </BidderPassword>
</LiveAuctionMessage>
<LiveAuctionMessage>
<Action> Confirm </Action>
<UserName> Andrea </UserName>
<Token> true </Token>
</LiveAuctionMessage>
High Availability e fault tolerance (1/1)



Provider JMS punto critico per l’
applicazione.
I messaggi vengono replicati su
dei broker slave di modo che, in
caso di fallimento del master, si ha
immediato failover sullo slave
senza perdita di messaggi.
Utilizzando un DB condiviso e
JDBC come connettore si puo’
adottare una configurazione
master/slave eseguendo tanti
broker quanti si ritengono opportuni;
uno slave fornisce un broker hot
stand by sempre sincronizzato,
pronto a prendere posto se il
master s’interrompe in seguito ad
hardware failure.
High Availability e fault tolerance (2/2)

ActiveMQ mette a disposizione funzionalita’ master/slave per
garantire alta disponibilita’ e tolleranza ai guasti

Protocollo Failover: utilizzato dai client per connettersi ad uno degli
URI specificati
(Es: failover:(tcp://broker1:61616,tcp://broker2) )


Il protocolo sceglie casualmente uno degli URI specificati e tenta di
stabilire una connessione con esso, se cio’ non avviene una nuova
connessione viene stabilita con uno degli altri URI.
Per le operazioni di recovery dopo un fallimento un broker
ActiveMQ sfrutta un proprio database ACTIVEMQ da cui recupera:

le destinazioni, la lista di “durable subscriptions”, la lista di “acks” per
ogni messaggio.
Replicated Message Store

JDBC Master/Slave
database unico sistema di
gestione della persistenza,
pertanto singolo punto di
fallimento
 RAIDb combina molteplici
istanze di database in una
matrice di database e fornisce
affidabilità migliore di quella di
un singolo database.
 RAIDb-1: DB completamente
replicato su ogni macchina.


Utilizzando RAIDb-1 si fa riferimento
ad un’astrazione di database che in
realtà è composto da due backends
reali posti su due macchine diverse.
Utilizziamo il driver Sequoia, un
middleware open source che
permette a qualsiasi applicativo di
accedere in maniera trasparente ad
un cluster di database tramite JDBC.
Conclusioni e sviluppi futuri
 L’infrastruttura descritta offre un sistema robusto ed efficiente per la
gestione di aste in tempo reale.
 Consente affidabilità grazie al Guaranteed Message Delivery e alta
disponibilita e tolleranza ai guasti a basso costo.
 Si dimostra efficiente grazie alla modalita’ di consegna once and
only once e all’ ottimizzazione del traffico di rete che si ottiene con
l’utilizzo dei message selectors
 Possibili miglioramenti possono riguardare l’implementazione di
politiche di sicurezza, necessarie dal momento che i messaggi
rappresentano transazioni economiche