NEMESI Creazione e pubblicazione di una rivista online tramite l
Transcript
NEMESI Creazione e pubblicazione di una rivista online tramite l
Lucia Bentivoglio matr. 0000-172326 Corso di Reti di Calcolatori L-S NEMESI Creazione e pubblicazione di una rivista online tramite l’utilizzo di un Message Oriented Middleware Molto tempo fa, in una fredda serata invernale, un gruppo di amici appassionati di letteratura antica pensò di creare una piccola rivista online per scrivere della loro passione. Qualcuno pensava ai contenuti, qualcuno si faceva carico della parte tecnica, e il piccolo sogno sembrava farsi sempre più concreto. Da allora sono passati i mesi, gli amici si sono (quasi tutti) laureati e si sono dispersi per il mondo a caccia del loro destino. Per tutti la piccola rivista è rimasta il sogno di una sera, o di qualche giorno. Ma le idee, per quanto piccole, continuano a galleggiare nell’aria, pronte a ripresentarsi al momento giusto… INTRODUZIONE Questo progetto è nato dal desiderio di approfondire le caratteristiche di un Message Oriented Middleware, e dal desiderio di mettere alla prova le possibilità offerte dal MOM nella realizzazione di una applicazione che traesse beneficio dal disaccoppiamento tra le parti offerto da una struttura a messaggi. Tra le varie possibilità, si desiderava in particolare provare lo standard Java Message Service (JMS) proposto dalla Sun. Come applicazione si è deciso di realizzare un sistema che permetta la creazione, pubblicazione e lettura di una rivista tramite la rete, ma senza l’utilizzo di pagine web e di un browser come supporto. CARATTERISTICHE SALIENTI DELLO STANDARD JMS Destinazioni La specifica JMS prevede che l’invio di messaggi tra applicazioni mittenti e applicazioni destinatarie avvenga utilizzando degli oggetti definiti destinazioni, che svolgono il ruolo di “depositi” in cui i mittenti possono lasciare i messaggi che creano, e da cui i destinatari possono recuperare i messaggi. Le destinazioni possono essere usate contemporaneamente da più mittenti e da più destinatari. A seconda del tipo di destinazione usato, però, la consegna dei messaggi avviene in modo diverso. • QUEUE (CODA) Quando un mittente invia un messaggio a una Queue, essa lo consegna solo al primo destinatario che cerca di ricevere un messaggio dalla Queue. Quindi solo uno dei destinatari attivi su una Queue riceve ogni messaggio. La Queue, quindi, realizza il passaggio di un messaggio da un mittente a un solo destinatario. Se nessun destinatario è attivo per la Queue nel momento in cui un mittente invia un messaggio, questo viene conservato dal Middleware finché non si attiva un destinatario (o finché non scade il time-to-live del messaggio, se questo è stato impostato). Tramite l’utilizzo di una Queue, quindi, mittenti e destinatari sono assolutamente indipendenti dal punto di vista temporale. • TOPIC (ARGOMENTO) Un Topic realizza una modalità di invio messaggi uno-a-molti. Nel momento in cui un messaggio viene “pubblicato” sul Topic, esso viene consegnato a tutti i destinatari che sono attivi in quel momento. Nella sua forma base, quindi, un Topic richiede che il destinatario sia attivo al momento della pubblicazione del messaggio per poter ricevere il messaggio stesso. E’ però possibile fare in modo che i destinatari si “abbonino” a un Topic tramite una sottoscrizione permanente (DurableSubscription). In questo caso, ogni sottoscrizione permanente al Topic è caratterizzata da un identificativo. Nel momento in cui il destinatario si connette al Topic usando l’identificativo precedentemente registato, esso riceve anche tutti i messaggi pubblicati sul Topic mentre era inattivo. Invio e ricezione dei messaggi Mentre è necessario che un mittente, per spedire un messaggio a una destinazione, invochi le API JMS opportune, un destinatario può ricevere un messaggio: • in modo sincrono, invocando esplicitamente le API JMS di ricezione e bloccandosi in attesa di un messaggio (eventualmente fissando un timeout, terminato il quale il programma riprende ad eseguire); • in modo asincrono, utilizzando un MessageListener che si attiva ogni qual volta gli viene recapitato un messaggio dalla destinazione che gli compete. L’utilizzo della ricezione asincrona permette di separare la parte di gestione dei messaggi dal resto delle funzioni di una applicazione nel caso questo sia possibile. Messaggi Ogni messaggio JMS deve avere un Header, o intestazione. All’interno dell’header sono presenti varie informazioni utilizzate per identificare, smistare e gestire il messaggio. Oltre alle informazioni fisse, è possibile inserire nell’header anche delle proprietà, costituite da coppie nomevalore, che possono essere sfruttate dal middleware per filtrare i messaggi, o comunque usate dalle applicazioni di destinazione Oltre all’header, un messaggio può avere anche un Body opzionale, il cui contenuto è determinato univocamente dal tipo di messaggio che si sta utilizzando: una stringa di testo per un TextMessage, una sequenza di bytes per un BytesMessage, un oggetto Java serializzato per un ObjectMessage, e così via. SISTEMA NEMESI Struttura del sistema Pensando a quali persone potevano essere coinvolte nella creazione e nell’utilizzo di una rivista online, si sono identificate le seguenti categorie di utilizzatori del sistema: • uno o più redattori, che da uno o più computer scrivono gli articoli e li inviano al direttore della rivista; • il direttore (tendenzialmente una sola persona, o più persone che però usano la stessa macchina) che, dopo aver letto gli articoli, sceglie quali inserire nei vari numeri, e pubblica i numeri della rivista; • i clienti, che dopo essersi registrati ricevono i numeri della rivista che vengono man mano pubblicati e possono leggere in ogni momento tutti gli articoli che hanno ricevuto. • Sono state quindi pensate altrettante categorie di applicazioni: la Direzione, che riceve gli articoli dai redattori e permette al direttore di pubblicare nuovi numeri della rivista; il nodo della Direzione gestisce anche tutta l’interazione con i clienti; • • le Redazioni, con cui i redattori autorizzati possono scrivere e modificare gli articoli finché non li inviano alla Direzione; le applicazioni Cliente, che permettano di “abbonarsi” alla rivista e di leggere tutti gli articoli dei numeri che sono stati man mano ricevuti. Funzionalità applicative Direzione La Direzione è l’applicazione centrale a cui fanno riferimento sia le Redazioni che i Clienti, ed è il nodo su cui sono memorizzate la maggior parte delle informazioni. La Direzione riceve gli articoli dalle applicazioni Redazione poste su altri nodi. Gli articoli vengono accettati e memorizzati solo se il rispettivo nodo della Redazione è stato precedentemente registrato, in modo da permettere la creazione amministrativa dei canali di comunicazione relativi alla Redazione. Una volta che l’articolo è stato ricevuto, esso è a disposizione degli utenti della Direzione. Un utente può usare i comandi della Direzione solo se il suo username e password sono stati precedentemente memorizzati. Una volta entrato nell’applicazione, l’utente può • leggere gli articoli ricevuti dalle Redazioni e non ancora pubblicati • creare un nuovo numero e pubblicarlo • richiedere la rigenerazione delle informazioni della direzione relative a numeri pubblicati e articoli ricevuti. Se la Direzione viene avviata, essa può gestire i messaggi provenienti da altri nodi anche se non viene acceduta e utilizzata da alcun utente autorizzato. Redazione La Redazione è una applicazione che può essere utilizzata contemporaneamente da più persone sulla stessa macchina, a patto che ogni utente sia stato preventivamente registrato. Ogni redattore, una volta effettuato l’accesso, può creare nuovi articoli o modificare/cancellare i suoi articoli (e solo i suoi) che ha memorizzato ma non ancora inviato alla Direzione. Una volta che l’articolo ha raggiunto la sua forma definitiva, esso può essere spedito. Dopo la spedizione, un articolo non può più essere modificato dal suo autore, né da nessun altro. I redattori, una volta effettuato l’accesso, possono anche richiedere la rigenerazione delle informazioni della redazione relative a numeri pubblicati e articoli ricevuti. Come per la Direzione, una volta che la Redazione è stata avviata, essa può gestire i messaggi provenienti dalla Direzione anche se non viene acceduta e utilizzata da alcun redattore. Cliente L’applicazione Cliente ha l’unico scopo di permettere all’utente di leggere gli articoli contenuti nei numeri ricevuti. L’utente sceglie uno username che lo identifichi al suo primo accesso; questo username, una volta che è stato accettato dalla Direzione, viene salvato nel file system locale e verrà utilizzato ad ogni successivo accesso per permettere la ricezione dei numeri pubblicati. Ogni volta che l’applicazione cliente viene avviata in seguito, se vi sono messaggi pendenti sul topic di pubblicazione, essi vengono elaborati e i numeri contenuti salvati nel file system locale. L’utente può liberamente sfogliare i numeri e i vari articoli, mentre l’applicazione rimane in attesa di eventuali numeri pubblicati mentre il cliente è in funzione. Persistenza dei dati Abbiamo visto che tutte le applicazioni che compongono il sistema hanno bisogno di memorizzare informazioni per poterle recuperare qualora l’utente o un’altra applicazione del sistema le richiedesse. Gli strumenti utilizzati per realizzare la persistenza dei dati sono stati diversi nelle varie parti del sistema. La Direzione e le Redazioni sono parti del sistema che si ritengono abbastanza statiche, pensate per un funzionamento prolungato sulla stessa macchina, e quindi possono richiedere un meccanismo di persistenza dei dati abbastanza strutturato. Per questo si è deciso di usare dei database per memorizzare i dati persistenti di Direzione e Redazioni. Si è scelto di utilizzare un database MySQL perché è un prodotto gratuito, estremamente diffuso e molto ben documentato. Le applicazioni comunicano con il server MySQL tramite un connettore JDBC e agiscono sul database tramite query SQL. L’applicazione Cliente, invece, nasce per essere distribuita a chiunque ne faccia richiesta; si è quindi cercato di ridurre al minimo la necessità di strutture di supporto all’applicazione. Non potendo eliminare, ad esempio, la necessità per il cliente del supporto JMS, si è deciso di realizzare la persistenza dei dati necessari al cliente tramite l’utilizzo di file XML. Questa soluzione permette di conservare una forma di strutturazione dei dati ricostruibile dall’applicazione analizzando i file, pur non richiedendo altro che il salvataggio di semplici file di testo. Database Direzione TABELLA Campo username password DIRETTORE Tipo varchar(20) varchar(20) Null No No Chiave Primaria Descrizione nome utente direttore password utente direttore TABELLA Campo id REDAZIONI Tipo char(10) Null No Chiave Primaria Descrizione identificativo redazione TABELLA Campo username CLIENTI Tipo varchar(20) Null No Chiave Primaria Descrizione nome utente cliente TABELLA Campo id ARTICOLI Tipo char(34) Null No Chiave Primaria autore redazione varchar(20) char(10) No No Foreign titolo testo pubblicato varchar(255) No text Sì boolean No Descrizione identificativo dell’articolo che contiene la data e l’ora di creazione username dell’autore dell’articolo identificativo della redazione che ha inviato l’articolo titolo dell’articolo testo dell’articolo indica se l’articolo è già stato pubblicato TABELLA Campo id pubblicazione NUMERI_PUBBLICATI Tipo Null Chiave char(5) No Primaria char(34) Sì Descrizione identificativo del numero, di forma [aa-nn] data e ora di pubblicazione del numero TABELLA Campo id_numero id_articolo ARTICOLI PUBBLICATI Tipo Null Chiave char(5) No Foreign char(34) No Foreign Descrizione identificativo del numero, di forma [aa-nn] identificativo dell’articolo Database Redazione TABELLA Campo username password REDATTORI Tipo varchar(20) varchar(20) TABELLA Campo id ID_REDAZIONE Tipo char(10) TABELLA Campo id Chiave Primaria Descrizione nome utente redattore password utente redattore Null No Chiave Primaria Descrizione identificativo redazione ARTICOLI Tipo char(34) Null No Chiave Primaria autore titolo testo consegnato varchar(20) varchar(255) text boolean No No Sì No Foreign Unico Descrizione identificativo dell’articolo che contiene la data e l’ora di creazione username dell’autore dell’articolo titolo dell’articolo testo dell’articolo indica se l’articolo è già stato inviato alla direzione TABELLA Campo username CLIENTI Tipo varchar(20) Null No Chiave Primaria Descrizione nome utente cliente TABELLA Campo id pubblicazione TABELLA Campo id_numero id_articolo Null No No NUMERI_PUBBLICATI Tipo Null Chiave char(5) No Primaria char(34) Sì ARTICOLI PUBBLICATI Tipo Null Chiave char(5) No Foreign char(34) No Foreign Descrizione identificativo del numero, di forma [aa-nn] data e ora di pubblicazione del numero Descrizione identificativo del numero, di forma [aa-nn] identificativo dell’articolo XML L’XML permette di mantenere una struttura delle informazioni nella semplicità di un file testuale. Per fare questo, un file XML contiene una ridondanza di informazioni rispetto ai puri dati che vi devono essere memorizzati. Questa ridondanza, che può rendere più complessa la comprensione del contenuto a una persona, rende però in generale più semplice il recupero e l’utilizzo dei dati da parte di una applicazione. Fin dall’inizio si è pensato di utilizzare file XML per memorizzare i dati necessari ai nodi cliente, ovvero le informazioni di login per connettersi al topic di pubblicazione e i numeri della rivista già ricevuti. Durante lo sviluppo della parte di applicazione che gestisce il salvataggio e il recupero dei dati dai file XML si è cercato un supporto all’interazione tra programma e file testuali che fosse il più possibile snello e intuitivo. Le due famiglie di API già incorporate nella release Java, ovvero SAX e DOM, erano entrambi carenti dal punto di vista della semplicità di utilizzo, richiedendo un notevole overhead dovuto alla necessità di renderle compatibili con standard non Java-dipendenti. Visto però che l’applicazione corrente è completamente basata su Java, si è trovata una soluzione estremamente più efficiente nell’utilizzo delle API JDOM. JDOM è una famiglia di API per l’utilizzo di XML tramite Java che è stato progettato solo a partire proprio da questi due elementi, con l’obiettivo primario di mantenere le cose semplici e chiare. L’utilizzo delle API di creazione e recupero dei dati è immediato e intuitivo. Coerenza dei dati e recovery Nel progetto del sistema non è stato previsto che vi fosse una replicazione delle funzionalità, in modo che, se un nodo cade, la sua funzione possa essere svolta completamente da un altro nodo. Bisogna considerare che: • i vari nodi sono stati progettati per lavorare in modo disaccoppiato l’uno dall’altro • se vengono spediti dei messaggi a un destinatario non presente, è compito del supporto middleware mantenere in memoria i messaggi in modo permanente • l’applicazione richiede raramente una interazione diretta con il cliente Detto questo, si è deciso che fosse accettabile che qualche parte di gestione del sistema non fosse disponibile anche per un periodo abbastanza lungo di tempo. Non si è quindi ritenuto necessario duplicare le funzionalità del sistema. Si è invece ritenuto molto importante duplicare le informazioni delle applicazioni di gestione (direzione e redazioni) in modo che, se uno dei nodi dovesse perdere parte o tutti i suoi dati, attraverso l’interazione con le altro parti gli sia possibile ricostituire tutte le informazioni (o quasi). Le uniche informazioni non replicate sono gli articoli che un redattore ha salvato ma non ancora inviato alla direzione. INFORMAZIONE Articolo completo Numero pubblicato e identificativi dei suoi articoli Username clienti NODO CHE LA CONTIENE Redazione originaria, Direzione Direzione, tutte le Redazioni Direzione, tutte le Redazioni Durante il funzionamento normale, sono le redazioni che, ad ogni avvio, mandano alla direzione dei messaggi che contengono le informazioni che la redazione ha nel suo database. La direzione controlla la corrispondenza tra le informazioni ricevute e quelle in suo possesso. Se le informazioni non sono coerenti: • nel caso degli articoli, modifica le informazioni in suo possesso • nel caso di numeri e username clienti, invia un messaggio alla redazione con le sue informazioni affinché la redazione le corregga. Sia dalle redazioni che dalla direzione l’utente può far partire una richiesta di rigenerazione del proprio database. In questo caso le vecchie informazioni eventualmente presenti sono mantenute finché gli altri nodi non rispondono con le informazioni aggiornate, che vanno a sostituire le vecchie nel database. Questo comando permette a un nodo che ha perso i propri dati di recuperare tutte le informazioni di gestione necessarie a un corretto funzionamento. Interazione tra le parti In figura è riportato uno schema che mostra le applicazioni e la loro interazione con le varie Destinazioni JMS previste per il funzionamento del sistema. REDAZIONE 1 REDAZIONE 2 Redazione 1 Queue … Redazione 2 Queue Input Queue DIREZIONE Login Queue REDAZIONE N Redazione N Queue Restore Queue Confirm Queue Publish Topic CLIENTE 1 CLIENTE 2 Invio/ricezione tramite API … CLIENTE N Ricezione asincorna Si nota chiaramente che la Direzione è, come già detto, lo snodo principale delle informazioni scambiate dal sistema complessivo. E’ anche possibile vedere che, in generale, tutte le applicazioni ricevono i messaggi dalle Destinazioni in modo asincrono. Questa scelta, che garantisce un alto grado di disaccoppiamento fra le varie perti, ha portato alla progettazione di code JMS unidirezionali; se infatti la stessa applicazione che invia il messaggio fosse anche in attesa sulla stessa coda, c’è un’altissima probabilità che sia essa stessa a ricevere il messaggio. L’unico caso di ricezione sincrona è il momento in cui un nuovo cliente vuole “abbonarsi” alla rivista, procedura che richiede la contemporanea presenza attiva della Direzione per essere completata con successo. Questo è possibile perché la procedura di iscrizione è eseguita solo una volta da ogni cliente, e la probabilità di sovrapposizione di due iscrizioni è molto bassa. Se anche vi fosse sovrapposizione, se il cliente non riceve un messaggio di conferma che sia relativo al proprio username, la procedura fallisce e deve essere ripetuta. Se la Direzione non è attiva nel momento in cui un cliente tenta di registrarsi, la scadenza dei timeout fa fallire la procedura e cancella dalla coda LoginQueue il messaggio di iscrizione inevaso, in modo da non causare una elaborazione successiva da parte della Direzione. Il cliente, in questo caso, dovrà solo riprovare più tardi. Messaggi • • • Tutti messaggi che vengono scambiati tra le parti sono tutti stati dotati di tre proprietà: ACTION, per identificare l’azione che l’elaborazione di questo comando comporta; CONTENT, per identificare il contenuto dell’eventuale Body del messaggio o il contenuto a cui il comando ACTION fa riferimento SENDER, per identificare il mittente del messaggio Nel caso di messaggi che contengono informazioni nel body, si era inizialmente pensato di utilizzare degli ObjectMessage nella comunicazione tra Redazioni e Direzione, pensando di poter usare un oggetto simile al risultato di una query su database come corpo del messaggio, e dei TextMessage tra Direzione e Clienti. Visto però che gli oggetti derivanti dalle interrogazioni dei database non implementavano l’interfaccia Serializable non era possibile utilizzarli in un ObjectMessage. Si era quindi deciso di usare in tutti i casi dei TextMessage che contenessero come corpo un file XML in forma testuale. Analizzando le API JDOM si è visto che, per creare un file testuale XML, è necessaria una istanza della classe Document. La cosa che si è rivelata molto interessante nell’ambito del sistema in sviluppo è che la classe Document implementa l’interfaccia Java Serializable. A questo punto si è rivelato inutile trasformare un oggetto Document nella sua forma testuale per allegarlo a un TextMessage, per poi dover fare il processo inverso al momento della ricezione. Rivedendo le decisioni precedenti, si è deciso che, nei casi fosse necessario inserire dati nel corpo di un messaggio, questi sarebbero stati inseriti in un oggetto org.jdom.Document, che sarebbe poi diventato il corpo di un ObjectMessage. In tabella sono riportati tutti i messaggi che vengono scambiati tra le parti, e le azioni svolte dal destinatario alla ricezione del messaggio. TIPO Message Message Message Object Message Object Message Object Message Message Message PROPRIETÀ VALORE DESTINATARIO DESTINA ZIONE BODY ACTION CONTENT SENDER LOGIN <username> CLIENTE Direzione Login Queue No ACTION CONTENT SENDER ACTION CONTENT SENDER ACTION CONTENT SENDER ACTION CONTENT SENDER CONFIRM <username> DIREZIONE REJECT <username> DIREZIONE PUBLISH <id_numero> DIREZIONE CREATE <id_numero> DIREZIONE Cliente identificato da <username> Cliente identificato da <username> Tutti i clienti “abbonati” Confirm Queue No Confirm Queue No Publish Topic Tutte le redazioni Queue della redazione ACTION CONTENT SENDER ACTION CONTENT SENDER ACTION CONTENT SENDER CREATE CLIENTE DIREZIONE RESTORE NUMERI DIREZIONE RESTORE CLIENTI DIREZIONE Tutte le redazioni Una redazione qualsiasi Queue della redazione Restore Queue Un nuovo numero e gli articoli relativi Un nuovo numero e gli identificativi dei suoi articoli Lo username di un nuovo cliente No Una redazione qualsiasi Restore Queue No AZIONE DEL DESTINATARIO Controllare se lo <username> scelto è già presente nel suo database. Se non c’è, lo inserisce e risponde positivamente. Salva in locale lo username confermato dalla direzione per usarlo in tutti gli accessi successivi. Presenta di nuovo all’utente la finestra di scelta dello username. Salva le informazioni ricevute in un file XML locale. Salva le informazioni ricevute nel database della redazione. Salva le informazioni ricevute nel database della redazione. Recupera dal proprio database le informazioni circa i numeri pubblicati e le rispedisce alla direzione. Recupera dal proprio database le informazioni circa i clienti registrati e le rispedisce alla direzione. Message ACTION CONTENT SENDER ACTION CONTENT SENDER RESTORE ARTICOLI DIREZIONE REPLACE NUMERI DIREZIONE Tutte le redazioni Queue della redazione Queue della redazione No Object Message ACTION CONTENT SENDER REPLACE ARTICOLI DIREZIONE Una redazione Queue della redazione REPLACE CLIENTI DIREZIONE CREATE ARTICOLO <redazione> CHECK NUMERI <redazione> Una redazione Queue della redazione Input Queue Articoli che la direzione ha ricevuto dalla redazione Username dei clienti registrati Object Message ACTION CONTENT SENDER ACTION CONTENT SENDER ACTION CONTENT SENDER Direzione Input Queue Numeri pubblicati secondo la redazione Controlla la corrispondenza tra le informazioni ricevute e quelle salvate nel database della direzione; se sono incoerenti, rigenera i numeri per la redazione. Object Message ACTION CONTENT SENDER CHECK CLIENTI <redazione> Direzione Input Queue Elenco clienti secondo la redazione Object Message ACTION CONTENT SENDER CHECK ARTICOLI <redazione> Direzione Input Queue Articoli inviati secondo la redazione Message ACTION CONTENT SENDER RESTORE DATABASE <redazione> Direzione Input Queue No Object Message ACTION CONTENT SENDER REPLACE NUMERI <redazione> Direzione Input Queue Object Message ACTION CONTENT SENDER REPLACE ARTICOLI <redazione> Direzione Input Queue Object Message ACTION CONTENT SENDER REPLACE CLIENTI <redazione> Direzione Input Queue Numeri pubblicati e identificativi dei loro articoli Articoli che la redazione ha spedito alla direzione Elenco dei clienti secondo il database della redazione Controlla la corrispondenza tra le informazioni ricevute e quelle salvate nel database della direzione; se sono incoerenti, rigenera l’elenco dei clienti per la redazione. Controlla la corrispondenza tra le informazioni ricevute e quelle salvate nel database della direzione; se sono incoerenti, corregge le informazioni salvate nel proprio database. Recupera dal proprio database le informazioni circa numeri pubblicati e articoli ricevuti dalla redazione e le invia alla redazione stessa. Sostituisce le informazioni salvate nel proprio database con quelle ricevute dalla redazione. Object Message Object Message Object Message Una redazione Direzione Numeri pubblicati e identificativi dei loro articoli Nuovo articolo Recupera dal proprio databse gli articoli precedentemente inviati e li rispedisce alla direzione. Sostituisce le informazioni salvate nel proprio database con quelle ricevute dalla direzione. Sostituisce le informazioni salvate nel proprio database con quelle ricevute dalla direzione. Sostituisce le informazioni salvate nel proprio database con quelle ricevute dalla direzione. Salva l’articolo nel proprio database. Sostituisce le informazioni salvate nel proprio database con quelle ricevute dalla redazione. Sostituisce le informazioni salvate nel proprio database con quelle ricevute dalla redazione. Riassunto degli strumenti di supporto necessari per le varie applicazioni APPLICAZIONE Direzione Redazione Cliente STRUMENTI RICHIESTI Java 1.5 o successivo, Message Queue 3, JDOM 1.0, MySQL 5 o successivo Java 1.5 o successivo, Message Queue 3, JDOM 1.0, MySQL 5 o successivo Java 1.5 o successivo, Message Queue 3, JDOM 1.0 CONCLUSIONI E EVENTUALI SVILUPPI L’utilizzo del middleware a messaggi che implementa la specifica JMS ha permesso di realizzare una applicazione le cui parti lavorano in modo estremamente disaccoppiato l’una dall’altra. Questo fatto, insieme alla bassa frequenza di interazioni tra le parti, ha permesso di ridurre al minimo la replicazione funzionale del sistema. E’ stata inoltre scoperta la possibilità di combinare le API JDOM per l’utilizzo di XML e i messaggi del MOM JMS per alleggerire il carico di lavoro delle applicazioni. Il sistema complessivo nasce per essere utilizzato in un ambito completamente Java. Nel caso di un forte aumento del numero di clienti che si vogliono iscrivere, potrebbe risultare necessario ripensare il nodo di Direzione in modo da aumentare la certezza della sua disponibilità in ogni momento. L’utilizzo, come implementazione JMS, del Message Queue della Sun, che è normalmente integrato anche nei server J2EE, apre alla prospettiva di ripensare le applicazioni in termini di componenti J2EE.