Infrastruttura per la compravendita di merci
all’ingrosso tramite l’utilizzo di
Java Message Service
Progetto di Reti di Calcolatori LS – AA2006-2007
Gianluca Giri 0000243150
1



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
Gianluca Giri 0000243150
2

Possibilità di interazione oltre C/S:

Perché non usare i Web Service?

Cosa serve:
◦ Coordinamento tra grossista e fornitori per evadere gli
ordini.
◦ Proposte di acquisto da parte dei grossisti.
◦ 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.
◦ Possibilità di fare comunicazione multicast e unicast.
◦ Possibilità per un retailer o un grossista di entrare ed
uscire dal sistema quando lo desiderano.
Gianluca Giri 0000243150
3

Utilizzo di un MOM che permetta di:

Si è scelta un’implementazione recente dello standard JMS:
Open Message Queue.
◦ Gestire disaccoppiamento spaziale e temporale delle entità
comunicanti.
◦ Garantire persistenza dei messaggi.
Server JMS
(Broker)

Legenda:
collegamenti ideali;
collegamenti reali.
Lati negativi:
 Tutto il traffico di messaggi passa attraverso il/i broker
rischio di congestione?  cluster, limitare msg
depositati, politiche su esuberi
Gianluca Giri 0000243150
4

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
Gianluca Giri 0000243150
5
R1
Retailers
1
R2
3
2
Vendors
V1
S1
V2
4
S2

Rn
…
V3
…
Vn
S4
…
Sn

5
S3

Numerosi Retailer, ognuno
comunica con tutti i
grossisti (Vendor) presenti.
Numerosi Vendor, ognuno
comunica con molti fornitori
(Supplier).
Ogni Supplier comunica con
numerosi Vendor.
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).
Gianluca Giri 0000243150
6

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:
R1
Q Conf.Ord.R1
Q OrdiniV1
V1
Q Conf.Suppl.V1
◦ 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.

Q Risp.PrezziR1
T Prices
Q S1
S1
Q S2
S2
Q Sn
…
Sn
Legenda:
operazioni listener
operazioni processo principale
Q = Queue
T = Topic
Messaggi strutturati per proprietà e valori
 somiglianza con XML
Gianluca Giri 0000243150
7

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.
Gianluca Giri 0000243150
8


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.
Gianluca Giri 0000243150
9


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).
Gianluca Giri 0000243150
10

Q OrdiniV1
V1a
V1b
Q Conf.Suppl.V1a
Q Conf.Suppl.V1b
È 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.

Q S1
S1
Q S2
S2
Q Sn
…
Sn
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).
Gianluca Giri 0000243150
11




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.
Gianluca Giri 0000243150
12





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
Gianluca Giri 0000243150
13

Indipendenza tempi di vita tra Retailer e Vendor
(mentre questi necessitano dei Supplier)


Trasparenza della allocazione:



Non serve preventiva conoscenza reciproca
È 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
Gianluca Giri 0000243150
14