CMON: Commerce Message Oriented Network

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


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.


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.


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


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


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


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.


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.


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


È 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


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.


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


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


CMON: Commerce Message Oriented Network

Documents

Transcript of CMON: Commerce Message Oriented Network