Nemesi Creazione e pubblicazione di una rivista online tramite l’utilizzo di Java Message Service

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

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

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

5 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

6 Schema delle interazioni

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

8 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

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

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

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

12 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

13 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”