Infrastruttura per la compravendita di merci all’ingrosso tramite l’utilizzo di
Java Message Service
1Gianluca Giri 0000243150
Progetto di Reti di Calcolatori LS – AA2006-2007
L’obiettivo è permettere l’interazione tra rivenditori, grossisti e fornitori di merci
Occorre superare il forte disaccoppiamento sia spaziale sia di tempi di vita delle tre entità
Le entità nel sistema non necessariamente si conoscono a priori, ma devono poter comunque comunicare.◦ Esempio: un rivenditore che desidera acquistare dei
prodotti, ma non sa a chi rivolgersi, cerca prima i grossisti disponibili e ne sceglie poi uno.
Focus:◦ ricerca e confronto di prezzi◦ Invio ed elaborazione degli ordini
2Gianluca Giri 0000243150
Possibilità di interazione oltre C/S:◦ Coordinamento tra grossista e fornitori per evadere gli
ordini.◦ Proposte di acquisto da parte dei grossisti.
Perché non usare i Web Service?◦ Alcune operazioni hanno granularità troppo fine◦ Ogni volta per ritrovare il servizio giusto bisogna
ricorrere ad un UDDI (quale?) se si presuppone la non conoscenza a priori.
◦ Non necessariamente tutti i Retailer o grossisti o fornitori interessati dispongono di un web server.
Cosa serve:◦ Possibilità di fare comunicazione multicast e unicast.◦ Possibilità per un retailer o un grossista di entrare ed
uscire dal sistema quando lo desiderano.
3Gianluca Giri 0000243150
Utilizzo di un MOM che permetta di:◦ Gestire disaccoppiamento spaziale e temporale delle entità
comunicanti.◦ Garantire persistenza dei messaggi.
Si è scelta un’implementazione recente dello standard JMS: Open Message Queue.
Server JMS (Broker)
Server JMS (Broker)
Legenda:collegamenti ideali;collegamenti reali.
4Gianluca Giri 0000243150
Lati negativi: Tutto il traffico di messaggi passa attraverso il/i broker
rischio di congestione? cluster, limitare msg depositati, politiche su esuberi
Open Message Queue:◦ Comunicazione basata su scambio di messaggi◦ Attraverso “destinazioni” fisicamente gestite come
spazi di memoria su un server chiamato “broker”◦ Broker multipli in cluster (availability)◦ Destinazioni di 2 tipi:
Code (Queue): tipicamente per scambi unicast Argomenti (Topic): tipicamente per scambi multicast
◦ Possibilità di comunicazione sia sincrona sia asincrona (NB: API JMS sempre sincrone, non bloccanti in invio, bloccanti in ricezione messaggi)
◦ Usa standard JNDI per il servizio di nomi che permette di ritrovare le destinazioni (ed altri oggetti gestiti)
◦ Usa database per persistenza messaggi
5Gianluca Giri 0000243150
Numerosi Retailer, ognuno comunica con tutti i grossisti (Vendor) presenti.
Numerosi Vendor, ognuno comunica con molti fornitori (Supplier).
Ogni Supplier comunica con numerosi Vendor.
R1R1 R2R2 RnRn…Retailers
V1V1 V2V2 V3V3 VnVn…
Vendors
S1S1 S2S2 S3S3 S4S4 … SnSn
Suppliers
1) Ri chiede a tutti i V1-Vn presenti il prezzo di un tipo prodotto cercato.2) I Vi che possono offrire il prodotto rispondono, fornendo anche il proprio
“biglietto da visita” per essere rintracciati.3) Ri seleziona un’offerta (intervento utente) e invia un ordine
direttamente all’offerente.4) Il Vi che riceve un ordine lo elabora richiedendo la merce o le parti per
assemblarla ai propri fornitori. Un Supplier può essere anche il gestore del magazzino dello stesso grossista rappresentato da Vi (divisione delle responsabilità).
5) Ri riceve l’esito dell’ordine (positivo o negativo).
6Gianluca Giri 0000243150
12
3
45
4
Ogni Retailer ha 2 Queue per le risposte:◦ Sui prezzi◦ Sugli ordini
I Vendor presenti sono tutti in ascolto su un Topic “Prices” per le richieste di prezzi in multicast.
Ogni Vendor usa 2 Queue:◦ Una per ricevere ordini;◦ Una per ricevere conferme dai
Supplier.questo permette di usare due processi gestori.
Ogni Supplier usa 1Queue per ricevere le richieste dai Vendor.
R1R1
V1V1
S1S1 S2S2 … SnSn
T Prices
Q Conf.Ord.R1
Q Risp.PrezziR1
Q OrdiniV1
Q Conf.Suppl.V1
Legenda:operazioni listeneroperazioni processo principaleQ = QueueT = Topic
Q S1 Q S2 Q Sn
7Gianluca Giri 0000243150
Messaggi strutturati per proprietà e valori
somiglianza con XML
Alla ricezione di un ordine un Vendor avvia una transazione:◦ Se ci sono problemi di comunicazione o eccezioni:
ROLLBACK e si ritenta.◦ Se si completa la sequenza delle conferme da parte di
tutti i Supplier coinvolti, allora Chiusura Transazione : Se non c’è abbastanza merce disponibile l’ordine non può
essere evaso: esito Negativo. Altrimenti esito Positivo.
Un Supplier notifica sempre ad un Vendor richiedente la quantità di merce disponibile; finché ciò non avviene la transazione resta aperta.
8Gianluca Giri 0000243150
Per un rivenditore è sufficiente un’entità Retailer funzionante per volta; non è necessario che sia sempre disponibile.
Un grossista potrebbe voler essere presente in modo continuativo nel sistema (evitare tempi di down) o dover gestire molto traffico di ordini:◦ diventa necessario avere più copie dell’entità Vendor
tutte configurate per lavorare a nome dello stesso grossista.
Si ipotizza che ogni Supplier sia sempre disponibile nel sistema, altrimenti occorrerebbe riutilizzare le stesse strategie proposte a breve per il Vendor.
9Gianluca Giri 0000243150
Un grossista può uscire dal sistema quando desidera (dopo aver terminato transazioni in corso).
Ma un Vendor che torna attivo NON ritrova una lista degli ordini depositati mentre non era operativo◦ occorrerebbe usare la sottoscrizione ad un Topic
invece di una Queue, e il Retailer dovrebbe restare in attesa della risposta (o delegare quest’attività) per un tempo imprevedibile.
Quindi se un Vendor cade o esce dal sistema mentre sta per ricevere un ordine, questo può scadere e dare esito negativo (tempo di vita del messaggio e di attesa del Retailer).
10Gianluca Giri 0000243150
È possibile attivare più copie (un pool) per:1. Avere fault tolerance ed evitare che il
malfunzionamento di un Vendor (guasto singolo) condizioni l’evasione degli ordini.
Occorre partire sempre con almeno due copie.
2. Fare load sharing in modo che il traffico di messaggi previsto sia distribuito equamente.
Tutte le copie rispondono ai prezzi; Più Vendor “gemelli” prelevano a turno
gli ordini dall’apposita Queue che tutti condividono;
Ciascuna copia gestisce un ordine in modo esclusivo, mantenendo la transazione con i Supplier.
Tutte le copie si appoggiano alla stessa base dati (gestione accessi).
V1bV1bV1aV1a
Q OrdiniV1
Q Conf.Suppl.V1a Q Conf.Suppl.V1b
S1S1 S2S2 … SnSn
Q S1 Q S2 Q Sn
11Gianluca Giri 0000243150
L’attivazione delle copie è manuale, perché:◦ Se un Vendor si replica sulla stessa macchina in realtà
le copie non eseguono in parallelo;◦ Non è possibile attraverso un MOM ordinare
l’attivazione su un’altra macchina senza l’ausilio di altre entità (a loro volta soggette a possibili guasti).
Ogni copia può essere attivata a piacere. La configurazione delle destinazioni usate da un
Vendor (vale anche per Retailer e Supplier) avviene all’attivazione e non cambia durante l’esecuzione.
Viene utilizzato un servizio di nomi (di tipo LDAP) per rintracciare, secondo la configurazione delle entità, le destinazioni predisposte sul server JMS.
12Gianluca Giri 0000243150
Due Server JMS in cluster e servizio di nomi sulla stessa macchina: necessario setup iniziale delle destinazioni.
Fino a tre applicazioni Retailer, tre Vendor e tredici Supplier sono stati attivati contemporaneamente su tre PC.
Basi di dati per le merci su due PC. Ogni istanza di Vendor è stata provata:
◦ In assenza di copie;◦ Con una copia (sia sulla stessa macchina, sia su un’altra
macchina);◦ Con più di una copia (sia sulla stessa macchina, sia su un’altra
macchina); In tutti e tre i casi precedenti si è verificato cosa succede
quando:◦ L’applicazione Vendor viene spenta bruscamente effetto
negativo sulle transazioni;◦ Uno dei due Broker si disattiva durante lo scambio di messaggi
failover automatico, comunicazione garantita
13Gianluca Giri 0000243150
Indipendenza tempi di vita tra Retailer e Vendor (mentre questi necessitano dei Supplier) Non serve preventiva conoscenza reciproca
Trasparenza della allocazione: È possibile spostare le applicazioni da una macchina all’altra
semplicemente attivandone una copia configurata nello stesso modo (stesse destinazioni e database applicativo)
Tempi di down mitigati Cosa si può ancora fare:
Far sì che se un Vendor non può contattare un Supplier della propria lista, possa almeno cercare un sostituto
estensione protocollo di ricerca; Dare l’iniziativa ai Vendor proposte d’acquisto ai Retailer
(inversione del protocollo); Permettere il passaggio dello stato di una transazione tra le
copie attive di un Vendor propagazione attraverso messaggi
14Gianluca Giri 0000243150