Nemesi
Creazione e pubblicazione di una
rivista online tramite l’utilizzo di
Java Message Service
Introduzione
Il progetto Nemesi nasce dal desiderio di creare un
sistema che permettesse la creazione, la pubblicazione
e la lettura di una rivista attraverso l’utilizzo della rete.
Fin dall’inizio si è deciso che fosse prioritario permettere
alle varie parti del sistema di lavorare in modo
indipendente le une dalle altre, per quanto possibile.
Tre sono le tipologie di utente che si è deciso di far
interagire col sistema:
Il direttore della rivista
I redattori della rivista
I clienti della rivista
Ognuno di questi tipi di utente ha a disposizione una
diversa applicazione per interagire col sistema.
2
Amministrazione e utenti
Due categorie di applicazioni compongono la parte
amministrativa di Nemesi: la Direzione e le varie
Redazioni
Questi nodi amministrativi formano una rete abbastanza statica
I nodi amministrativi nascono per essere usati da utenti che
hanno tutto l’interesse a far funzionare le applicazioni nel modo
migliore, e quindi sono probabilmente disposti a spendere un po’
di tempo e fatica per approntare tutti i supporti necessari per il
sistema
La terza applicazione è quella che viene utilizzata dai
clienti per accedere i contenuti della rivista
I clienti finali desidereranno probabilmente dover installare il
minor numero possibile di supporti per far funzionare il servizio
La rete dei clienti deve poter crescere in modo dinamico senza
che la parte amministrativa ne risenta.
3
Caratteristiche della comunicazione
Per ottenere un alto grado di indipendenza tra le
applicazioni, è necessario che le parti possano
comunicare con successo anche se non sono tutte
presenti all’atto della comunicazione.
Un supporto di comunicazione a messaggi si integra
molto bene con le caratteristiche di disaccoppiamento
cercate. In particolare, il supporto JMS
Permette di comunicare tramite DESTINAZIONI che non
richiedono la presenza contemporanea di mittente e destinatario
affinché la consegna avvenga con successo
Permette alle applicazioni di ricevere messaggi in modo
asincrono rispetto al flusso di esecuzione dell’applicazione
stessa.
4
Caratteristiche dei messaggi
Un messaggio JMS contiene:
Un HEADER, in cui si possono inserire proprietà che possono
essere sfruttate per l’elaborazione del messaggio
Un BODY opzionale, il cui contenuto varia in base al tipo del
messaggio
Tutti i messaggi scambiati nel sistema Nemesi sono stati
dotati di tre proprietà:
ACTION, il cui valore serve a identificare l’azione che la corretta
elaborazione di questo messaggio comporta;
CONTENT, per identificare il tipo di informazioni contenute
dell’eventuale Body del messaggio o a cui, comunque,
l’elaborazione richiesta da ACTION fa riferimento
SENDER, per identificare il mittente del messaggio
5
Schema delle interazioni
6
Persistenza delle informazioni
Tutte le applicazioni del sistema devono poter
memorizzare alcune informazioni in modo persistente
Direzione e Redazione
Per questi nodi, che sono gestiti “amministrativamente”, la
persistenza dei dati è realizzata tramite dei database, che
forniscono un supporto di controllo della consistenza dei dati
all’interno dello stesso database
Clienti
Per alleggerire il supporto necessario ai clienti, sui nodi degli
utenti finali le informazioni vengono salvate sotto forma di file
XML, formato che permette di mantenere un certo grado di
organizzazione dei dati pur nella forma di puro testo
Nel corso dello sviluppo del progetto, l’utilizzo di XML si è rivelato
interessante anche per la fase di comunicazione delle informazioni.
7
Direzione
Il nodo di Direzione svolge il ruolo centrale nel sistema
Riceve gli articoli dalle Redazioni
Effettua i controlli di consistenza delle informazioni
Permette ai clienti di abbonarsi alla rivista
Gli utenti che hanno il permesso di usare la Direzione
possono:
Leggere gli articoli ricevuti dalle Redazioni
Pubblicare nuovi numeri
Richiedere la rigenerazione delle informazioni del database della
Direzione
E’ prevista la presenza di un solo nodo di Direzione
8
Redazione
Ogni redazione può essere utilizzata
contemporanemanete da più utenti autorizzati. Ognuno
di loro potrà
Creare nuovi articoli
Modificare i propri articoli non ancora inviati
Inviare alla direzione gli articoli completati
Oltre a questo, ogni redazione riceve e salva in locale
informazioni dalla Direzione
Come per la Direzione, è possibile avviare manualmente
la rigenerazione delle informazioni del database della
redazione.
9
Cliente
Un cliente, per poter accedere alla rivista, deve
effettuare un “abbonamento” alla stessa:
Al primo accesso, ogni utente deve scegliere uno username che
identifichi il nuovo nodo cliente
La procedura di creazione di un nuovo cliente è l’unica fase di
comunicazione che richiede la presenza contemporanea di
mittente e destinatario per essere completata con successo.
Alla fine di uno scambio terminato con successo, i dati del
cliente vengono salvati su tutti i nodi del sistema.
Agli accessi successivi, l’applicazione cliente recupererà
i numeri della rivista pubblicati e li metterà a disposizione
del lettore, utente finale della rivista.
10
Guasti e provvedimenti
Vista la natura estremamente indipendente delle varie
applicazioni, che funzionano correttamente senza
bisogno di sapere se gli altri nodi sono presenti o meno,
non si è ritenuto necessario realizzare un meccanismo di
replicazione delle funzionalità. In generale, una
applicazione che voglia comunicare con un altro nodo
invia i messaggi che le competono, e poi continua ad
eseguire senza attendere risposta.
Questo non è vero, come detto, al momento dell’inserimento di
un nuovo cliente nel sistema. In quel caso l’inattività del nodo di
Direzione costringe il cliente a ritentare l’accesso in un secondo
momento. Questo scenario potrebbe però non essere più
accettabile nel caso il sistema volesse proporsi come strumento
di largo utilizzo.
11
Guasti e provvedimenti
Si è valutato che difficilmente possano essere inserite
nel sistema informazioni fittizie, mentre è molto più
probabile e dannoso che a causa di qualche guasto le
informazioni vengano perse o corrotte.
Si è quindi ritenuto fondamentale, soprattutto per i nodi
amministrativi, replicare le informazioni importanti, in
modo che un nodo (direzione o redazione) potesse
recuperare le informazioni perse comunicando con gli
altri nodi.
Le informazioni replicate sono:
Articoli inviati, presenti sulla redazione di origine e sulla
direzione
Clienti, numeri e articoli pubblicati, presenti su tutti i nodi
amministrativi
In caso di perdita dei dati di una redazione, gli articoli non
ancora completati vengono persi definitivamente
12
Conclusioni
Il sistema ottenuto ha un altissimo grado di
disaccoppiamento fra le parti, come desiderato
Si è realizzata una politica di replicazione delle
informazioni per ovviare a problemi di perdita o
corruzione dei dati
La presenza di un solo nodo di Direzione e una certa
staticità della struttura dei nodi amministrativi potrebbero
limitare la scalabilità del sistema
La scelta di utilizzare ambiente e strumenti
monolinguaggio ha portato a trovare interessanti
convergenze tra i vari supporti utilizzati
Possibile integrazione delle applicazioni stand-alone con
componenti “gemelli”
13