Tecniche di Enterprise Application Integration in un contesto di ...

Tecniche di Enterprise Application Integration in
un contesto di eGovernment: UniGeINT
Francesco Di Cerbo 1 , Marco Scotto 1 , Alberto Sillitti 2 , Giancarlo Succi 2 ,
Tullio Vernazza 1
1
: Dist – Universita' degli studi di Genova
2 : Libera Universita' di Bolzano
{nome.cognome}@unige.it || {nome.cognome}@unibz.it
La finalita' di questo articolo e' quella di presentare UniGeINT -
University of Genoa Integration Tool -, un framework ideato per
fornire servizi di integrazione tra le applicazioni web e non, con i
databases e data repositories utilizzati nell'ambito amministrativo
dell'Universita'. Tale progetto e' stato realizzato coinvolgendo
software Open Source, al fine di beneficiare delle caratteristiche di
riduzione dei costi di sviluppo e di mantenimento a lungo termine.
Inoltre, sono state adottate soluzioni allo stato dell'arte nell'ambito
dell' Enterprise Application Integration, utilizzando design patterns ad
hoc per meglio interagire con l' infrastruttura esistente.
1 INTRODUZIONE
Il progetto nasce da una convergenza di esigenze, da parte dell'Universita' di
Genova, legate alla propria struttura IT. Durante gli anni, il susseguirsi degli
aggiornamenti tecnologici, associato ad un processo di potenziamento dei
servizi forniti, ha portato ad una creazione di diverse “isole di automazione”
[1][2], con un livello di cooperazione relativo tra aree diverse.
In questo scenario, quindi, nuove adozioni quali le suite di groupware o di
elearning integrate con i sistemi di accounting esistenti, e correlate ai
meccanismi di gestione delle attivita' didattiche, avrebbero richiesto per la loro
entrata in produzione un overhead in termini di costi indiretti cospiquo.
Concentrandoci quindi sull'idea base dell'integrazione, il progetto e' stato
nominato “UniGeINT”: si tratta di un middleware framework SOAP-based, che
sfrutta le caratteristiche del modello a web services.
2 TECNOLOGIE IMPIEGATE
2.1 SOAP
Il Simple Object Access Protocol (SOAP)[4] e' un paradigma di comunicazione
a messaggi, stateless e unidirezionale.
I ruoli principali in uno scenario SOAP sono assunti da un trasmettitore ed un
ricevitore , o, per maggiore precisione, un server ed un client SOAP.

SOAP e' quindi essenzialmente un framework per lo scambio di messaggi
che permette la comunicazione di informazioni specifiche per le applicazioni di
riferimento, in maniera estensibile ed incapsulate in tipi di dati protetti. [6]
2.2 XSL & XSLT
eXtensible Stylesheet Language (XSL) e' un gruppo di raccomandazioni che
definiscono come effettuare trasformazioni sui documenti XML, altresi'
delineandone le forme di presentazione.
eXtensible Stylesheet Language: Transformations (XSLT) e' un linguaggio che,
specificamente, definisce le regole per trasformare un albero XML di partenza
in uno destinazione. Tale passaggio e' ottenuto mediante un processore XSLT.
[7][8]
3 ARCHITETTURA
Il nostro obiettivo era quello di creare un middleware layer di comunicazione,
per permettere alle applicazioni della struttura, anche se nativamente non
cooperative le une con le altre, l'interscambio informativo.
Tenendo quindi la reliability come primo requisito essenziale, abbiamo
previsto l'esistenza di un gateway centrale per lo scambio messaggi, un “centro
stella”, mantenendo quindi un controllo centrale utile per il logging ed il
debugging.
Per realizzare queste indicazioni, il design pattern di Application Integration che
abbiamo utilizzato e' stato il “Message Broker” [9] (si veda Fig. 2), di fatto
lievemente modificato per dare al Broker stesso quelle funzionalita' di alto livello
precentemente introdotte.
Giunti al termine del percorso di design, abbiamo deciso di riferirci a questo
componente come all' “engine”.
Abbiamo poi scelto, al fine di fornire le funzionalita' SOAP a software
sprovvisti, il pattern “message gateway” [10]. Tale pattern prevede lo sviluppo
delle primitive SOAP in un modulo software separato dall'applicazione che ne e'
sprovvista, per preservare completamente la sua integrita'.
Per questo processo, abbiamo implementato due diverse interfacce, la prima
orientata alla comunicazione, l'altra all'interazione con il programma.
Ci siamo riferiti a questi moduli di interazione come a “plugin” (si veda Fig. 3).
Da un punto di vista piu' tecnico, abbiamo implementato un server SOAP per
le operazioni esterne del plugin, in modo che possa venire utilizzato dal client
contenuto nell'engine oppure da applicazioni di terze parti. E' stato quindi
previsto, a livello di protocollo, una prima verifica sintattica mediante la
definizione di un XML Schema ad-hoc, estendibile da ogni plugin, per la
validazione del payload.
Per un esempio della struttura del plugin, illustreremo quello sviluppato per

Moodle.
Fig. 2: Pattern Message Gateway, immagine da [13]
Fig. 1: Pattern Message Broker ,
immagine da [12]
3.1 MOODLE PLUGIN
Lo scopo di questo plugin e' quello di dotare Moodle, una suite di e-learning
Open Source – che e' adottata correntemente in tutto il mondo da universita',
scuole e servizi di formazione – di una estensione della propria interfaccia
applicativa, esponendo tali servizi con chiamate SOAP.
Il nostro plugin quindi e' orientato ad implementare un'interfaccia SOAP in
grado di rendere possibile amministrare le impostazioni dei corsi di studio e
degli studenti iscritti alla suite
attraverso un approccio XMLbased.
E' stato utilizzato, come
linguaggio implementativo
PHP, nella versione 5, per
motivi prestazionali, sia legati
alla gestione dei messaggi
SOAP, supportati in maniera
nativa, sia per i benefici
connessi all'adozione delle
libXML2 nel core del motore
Zend.
4.1.1 Importazione
Questa parte dell'interfaccia e'
Fig. 5: Diagramma Engine – SOAP Layer
composta da tre metodi, che
permettono a Moodle di effettuare importazioni massive di utenti, studenti o
categorie, attraverso il framework SOAP. A questo scopo, e' stato definito un
XML Schema nel quale abbiamo definito i tipi di dati e le strutture funzionali
all'acquisizione XML: abbiamo quindi estrapolato dal database MySQL di
Moodle i campi di interesse.
Quindi, abbiamo previsto, in ordine temporale, le procedure client-server per le
attivita' di gestione della deincapsulazione delle informazioni nei payload SOAP
, del parsing del documento WSDL di riferimento, della sua validazione e
finalmente della effettiva raccolta dati per l'inserimento.

Cio' che risulta da rimarcare e' la non intrusivita' di tali funzionalita' all'interno
dell'ambiente operativo originale: sono state infatti utilizzate le stesse API
fornite da Moodle nella propria libreria di data management.
4.1.2 Esportazione
Nonostante esista la possibilita' di effettuare backup in formato XML per
Moodle, non abbiamo trovato alcun metodo altrettanto incluso per la validazione
di tali informazioni, e comunque il livello di customizzazione fornito non era
adeguata alle nostre esigenze.
Abbiamo quindi stabilito di utilizzare lo stesso schema utilizzato per
l'importazione, quindi sempre facendo riferimento alle API di Moodle ed ai
metodi di incapsulazione – decapsulazione XML.
Queste operazioni sono ottenute impededo ogni possibilita' di perdita
informativa, attraverso la diretta validazione con l'XML Schema sia per il
messaggio SOAP che per il suo payload, operazione ripetuta anche in
ricezione.
4 CONCLUSIONI
Il lavoro svolto, ha raggiunto come primo risultato, una forte contrazione dei
costi di mantenimento di Moodle, permettendo semplici integrazioni con
l'infrastruttura esistente ed altre soluzioni commerciali in esercizio. Inoltre, tale
attivita' ha portato un beneficio concreto per la comunita' Open Source
associata a Moodle, fornendo una estensione a tutto vantaggio degli utilizzatori
inseriti in ambienti professionali, quali scuole, universita' ed enti di formazione.
5 RIFERIMENTI
[1] Fenves S.J, “The penetration of information technologies into civil and structural engineering design: state-ofthe-art
and directions toward the future”, 1996.
[2] Hannus M., “Islands of Automation in Construction”, Construction on the information highway, 1996.
[3] XML Schema Part 0: Primer Second Edition (W3C Recommendation 28 October 2004),
http://www.w3.org/TR/xmlschema-0.
[4] Web Services Architecture (W3C Working Group Note 11 February 2004),
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211.
[5] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language (W3C Working Draft 3
August 2004), http://www.w3.org/TR/wsdl20.
[6] SOAP Version 1.2 Part 0: Primer (W3C Recommendation 24 June
2003),http://www.w3.org/TR/2003/REC-soap12-part0-20030624.
[7] XSL Transformations (XSLT) Version 1.0 (W3C Recommendation 16 November 1999),
http://www.w3.org/TR/xslt.
[8] M. Kay, XSLT Prgrammer's Reference, Wrox Press Ltd (UK), 2000.
[9] G. Hohpe and B. Woolf, Message Broker, Enterprise Integration Patterns, Addison-Wesley Professional, 2003.
[10] G. Hohpe and B. Woolf, Messaging Gateway, Enterprise Integration Patterns, Addison-Wesley Professional,
2003.