XML e le architetture Message Oriented

Descrizione

Il formato XML si è ormai affermato come "lingua franca" per lo scambio e la condivisione di informazioni, platform-independent e vendor-independent. La maggior parte dei produttori di software già adotta XML nei propri prodotti: il caso tipico è la possibilità di esportare/importare informazioni.
Allo stesso tempo i consorzi di standardizzazione producono ogni giorno formati e specifiche basati su XML, rendendo possibile l'interoperabilità tra le varie applicazioni. A supporto di questa attività troviamo formalismi come i DTD (Document Type Definition) o gli XML Schema.
Ma definire gli standard di rappresentazione dati per la comunicazione non è sufficiente: i dati XML devono integrarsi con le applicazioni e con il business, devono poter essere elaborati da vari linguaggi e da più piattaforme. Approccio interessante, ma non troppo diffuso, per lo scambio e il trattamento di dati in formato XML sono le architetture "Message Oriented Middleware" (MOM).

Introduzione a MOM

I sistemi per la comunicazione tra componenti distribuiti sono di vario genere, tra i più diffusi troviamo RPC (Remote Procedure Call) e MOM ( Message Oriented Middleware). Il primo è un approccio tipicamente client/server, dove il server espone dei metodi invocabili tramite un messaggio sincrono da parte del client. Nelle architetture MOM, invece, il messaggio non è usato per l'invocazione di un metodo, ma viene trattato come un evento verso un'infrastruttura.

Figura 1

Le caratteristiche fondamentali dell'architettura sono: disaccoppiamento spinto tra le componenti, messaggi event-oriented e comunicazione asincrona. I modelli di comunicazione tipicamente utilizzati dalle architetture MOM sono di 2 tipi: Point-to-Point (PtP) e Publish-Subscribe (P&S). Nel primo caso il client indirizza un messaggio verso un componente specifico, mentre nel secondo caso il client indirizza il messaggio verso un "topic", indipendentemente dal numero di componenti interessati.
Le implementazioni MOM esistenti spaziano dal semplice dispatcher/listener tra oggetti, fino a sistemi a code con features come: asynchronous messages, guaranteed delivery, security, cross-platform data marshalling, scalability, etc.

Un'architettura per XML

Invece che utilizzare un'applicazione monolitica per manipolare dati in formato XML, la programmazione orientata ai componenti permettere agli sviluppatori di creare funzionalità elementari riutilizzabili, assemblabili poi in applicazioni più grandi. Se si unisce, poi, questo paradigma alle architetture MOM si ottiene un'architettura component-based per applicazioni XML distribuite.
In figura è rappresentato una modello semplificato di architettura MOM per XML basata su una catena di componenti.

Figura 2

Il modello, seppur semplice, è più che sufficiente per gli obbiettivi dell'articolo. Il primo componente della catena, "XML Data Producer", solitamente genera informazioni in formato XML ricavandole da sorgenti dati come database, file, applicazioni e altro. Il risultato viene passato in sequenza ai successivi componenti in grado di elaborare, trasformare, memorizzare o presentare l'informazione XML.

Una semplice implementazione

Cerchiamo ora di realizzare il modello appena descritto utilizzando Java e i componenti JavaBeans.

Figura 3

Come si può notare dal diagramma UML, l'implementazione del modello è volutamente semplice e a solo scopo didattico, ma risulterà utile successivamente per meglio comprendere le considerazioni finali.
Le informazioni XML vengono incapsulate nella classe DocumentMessage secondo lo standard DOM, qualsiasi componente voglia accedere a queste informazioni dovrà usare il metodo getDocument e manipolarle utilizzando le API Java-DOM.
I componenti per il trattamento delle informazioni XML sono rappresentati rispettivamente dalle interfacce DocumentSource e DocumentListener. La prima ha il compito di "trasformare" una qualsiasi sorgente di informazioni (database, file, etc) in una struttura DOM, mentre la seconda riceve un oggetto di tipo DocumentMessage e ne elabora il contenuto.
Dispatcher del messaggio XML e coordinatore dei componenti per la manipolazione DOM è la classe Channel istanziata tramite la factory ChannelFactory: ogni canale viene referenziato, attraverso la factory tramite un nome. Compito principale di Channel è il "routing" del messaggio, generato da un eventuale sorgente, attraverso una sequenza di componenti ad esso registrati. Nel caso specifico si tratta di registrare tramite i metodi setSource e addListener rispettivamente una singola istanza di DocumentSource e una sequenza di DocumentListener.

Definite le interfacce e le classi principali, possiamo passare all'implementazione dei componenti. Nel nostro caso abbiamo creato 3 semplici componenti:

• SampleSource: genera un documento XML elementare, lo trasforma in una struttura DOM e lo ritorna all'architettura.
• SampleTransformer: riceve un messaggio XML-DOM, ricava l'elemento root e ne aggiunge un attributo.
• SampleOutput: riceve un messaggio XML-DOM e lo visualizza su standard output.

Di seguito uno screen-shot dei risultati:

Figura 4

Maggiori dettagli sull'implementazione possono essere trovati nei sorgenti completamente documentati.

Vantaggi architettura XML-MOM

• Semplice: in un applicazione orientata ai messaggi, il numero di interfacce da conoscere per interagire con il sistema è limitato.
• Generico: essendo il sistema basato solamente su scambio di messaggi, la medesima architettura può essere riutilizzata per più applicazioni.
• Disaccoppiato: le componenti dell'eventuale applicazione non sono strettamente accoppiate, l'accoppiamento è dato dall'informazione contenuta nel messaggio.
• Flessibile: l'inserimento, la rimozione o l'aggregazione delle funzionalità di un'applicazione nelle varie componenti può avvenire in qualsiasi momento, senza comprometterne la funzionalità.
• Distribuito: utilizzando tecnologie come JMS al posto del semplice "dispatcher" descritto nell'articolo, è possibile ottenere in modo abbastanza semplice un sistema a componenti distribuiti.

Svantaggi architettura XML-MOM

• Generica: la genericità per alcuni tipi di applicazione può essere uno svantaggio, infatti ogni componente deve sempre comprendere il messaggio che riceve, validarne il contenuto, elaborarlo e rispedirlo all'architettura.
• Troppo semplice: per alcune applicazioni l'approccio può risultare troppo semplice, ad esempio l'utilizzo di concetti come le interfacce diminuisce drasticamente e attività come la documentazione e il refactoring possono risultare più difficoltose.
• Poco diffuso: non è un approccio molto diffuso, pertanto gran parte delle applicazioni e/o librerie disponibili devono essere adattate.
• Marshalling: non esiste uno standard per il marshall/unmarshall delle informazioni.

Conclusioni

In questo articolo è stato descritto uno dei tanti approcci per l'elaborazione di informazioni in formato XML, senza aver la pretesa di implementare un'architettura per un sistema enterprise. Le architetture orientate ai messaggi possono risultare molto flessibili, ma un loro utilizzo esteso in alcuni ambiti può risultare addirittura controproducente.

Informazioni sull'autore

Stefano Maniero, diplomato in Elettronica, con diversi anni di esperienza nello sviluppo prevalentemente in ambienti UNIX (Linux e Solaris) con linguaggi come C, Java, C++, Perl, PHP, Python, ...

È possibile consultare l'elenco degli articoli scritti da Stefano Maniero.

Altri articoli sul tema Linguaggi.

Risorse

1. Sorgenti applicazione di esempio
   http://www.siforge.org/articles/2005/01/xml_mom/xml_mom.zip (7Kb)