CMON: Commerce Message Oriented Network

CMON: Commerce Message Oriented Network Infrastruttura per la compravendita di merci all’ingrosso tramite l’utilizzo diJava Message Service Progetto di Reti di Calcolatori LS – AA2006-2007 Gianluca Giri 0000243150

Scopo del Progetto • 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

Scelte tecnologiche (1/2) • 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. Gianluca Giri 0000243150

Server JMS (Broker) Legenda:collegamenti ideali;collegamenti reali. Scelte tecnologiche (2/2) • 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 MessageQueue. • 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

Infrastruttura JMS • Open MessageQueue: • 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

R1 R2 Rn Retailers … Vendors V1 V2 V3 … Vn S1 S2 S3 S4 … Sn Suppliers Entità e Comunicazione 3 1 2 4 4 5 • Ri chiede a tutti i V1-Vn presenti il prezzo di un tipo prodotto cercato. • I Vi che possono offrire il prodotto rispondono, fornendo anche il proprio “biglietto da visita” per essere rintracciati. • Ri seleziona un’offerta (intervento utente) e invia un ordine direttamente all’offerente. • 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à). • Ri riceve l’esito dell’ordine (positivo o negativo). • Numerosi Retailer, ognuno comunica con tutti i grossisti (Vendor) presenti. • Numerosi Vendor, ognuno comunica con molti fornitori (Supplier). • Ogni Supplier comunica con numerosi Vendor. Gianluca Giri 0000243150

R1 Q Conf.Ord.R1 T Prices Q Risp.PrezziR1 Q OrdiniV1 V1 Q Conf.Suppl.V1 Q S1 Q S2 Q Sn S1 S2 … Sn Legenda:operazioni listeneroperazioni processo principaleQ = QueueT = Topic Destinazioni e Messaggi • 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. • Messaggi strutturati per proprietà e valori somiglianza con XML Gianluca Giri 0000243150

Transazioni • 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

Replicazione, Tolleranza ai guasti e Availability • 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

Replicazione del Vendor (1/2) • 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

Q OrdiniV1 V1a V1b Q Conf.Suppl.V1a Q Conf.Suppl.V1b Q S1 Q S2 Q Sn … S1 S2 Sn Replicazione del Vendor (2/2) • È possibile attivare più copie (un pool) per: • 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. • Fare loadsharing 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

Osservazioni • 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

Deployment e Test • 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

Conclusioni e sviluppi futuri • 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 Gianluca Giri 0000243150

CMON: Commerce Message Oriented Network