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.