Live auction un’ infrastruttura di supporto per aste in tempo reale basata su JMS.

1. Corso di Laurea in Ingegneria Informatica L-S Anno Accademico 2007-2008 Live auctionun’ 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

2. 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.

3. 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.

4. Caratteristiche della comunicazione • Comunicazione push based di tipo molti a molti. • Sia bidder che admin sono produttori e consumatori di informazioni. • Numero di client non noto a priori. • I partecipanti all’ asta possono essere numerosi. • Asincronicita’: • 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.

5. 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.

6. JMS – generalita’ • Queue (coda) : realizza il modello di comunicazione point-to-point • Topic (topic): realizza il modello di comunicazione publish-subscribe

7. 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.

8. Architettura logica del sistema

9. <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> Struttura dei messaggi Bidder e Admin creano degli oggetti TextMessage che incapsulano un documento XML come stringa Java.

10. 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

11. 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.

12. Ricezione dei messaggi • La sessione di un subscriber è caratterizzata dalla modalità AUTO_ACKNOWLEDGE. • Politica della consegna dei messaggi once-and-only-once. • 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.

13. 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> Servizio di login

14. 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.

15. 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.

16. 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.

17. 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