Sempre più spesso è necessario integrare applicazioni diverse in modo che - ad esempio - ci sia un'unica tabella di anagrafica utenti di riferimento, sulla quale vengano fatto tutte le operazioni di aggiornamento, inserimento e rimozione che poi saranno opportunamente replicate su "n" altri database di altre applicazioni, in modo da avere una consistenza logica dei dati ovunque sia necessario accedere a tali informazioni.
In pratica sto parlando di "Master Data Management".
Un'esperienza che voglio condividere con tutti è l'applicazione di questa metodologia (che non è davvero nulla di nuovo come potete ben vedere) al sito UGISS. Stiamo parlando di un piccolo esempio, è ovvio, ma credo che sia molto significativo e sicuramente istruttivo.
Dopo la messa online del nuovo sito di UGISS è stato necessario far si che ogni volta che un nuovo utente si iscrive al sito http://www.ugiss.org i suoi dati devono essere passati a CommunityServer per far si che l'utente sia automaticamente registrato anche su http://community.ugiss.org.
Un modo standard e consolidato per far ciò è quello di fare un bel batch ed eseguirlo ogni "tot" minuti.
Siccome però siamo nel 2008 e persolmente non riesco più a tollerare tutti quei servizi che mi fanno aspettare anche una sola ora per poter aver accesso alle funzionalità protette, ho deciso di voler fare tutto in tempo reale.
Ho subito scartato la possibilità offerta da CommunityServer perchè si basa sull'uso di un accrocchio fatto in .NET e la mia esigenza è quella di essere trasparente rispetto alle applicazioni, altrimenti mi legherei mani e piedi ad esse. Questa cosa non è desiderabile in quanto troppo limitate per gli sviluppi futuri: ho bisogno di qualcosa che lavori a livello di database in modo che tutte le applicazioni che ci metterò sopra (ora ed in futuro) potranno funzionare senza dover essere modificate, ed inoltre ho la necessità di avere i dati COME VOGLIO IO (e quindi entra in gioco il Master Data Management) non come me li trovo nei database delle applicazioni che uso.
Per poter far tutto in tempo reale ho deciso di utilizzare il Service Broker di SQL Server 2005. Ecco come funziona il tutto.
- Ogni volta che un utente si registra al sito di UGISS vengono registrato tutti i dati che servono e viene invito un messaggio XML che contiene un subset di questi dati (quelli necessari a CommunityServer) ad un servizio esposto dal Service Broker.
- Appena il broker riceve il messaggio manda in esecuzione una stored procedure che si occupa di prendere i contenuti del messaggio e fare tutte le operazioni necessarie (e sono tante) per creare correttamente l'account su http://community.ugiss.org.
- Se tutto è andato bene, la procedura manda un messaggio di riuscita dell'operazione e la procedura viene conclusa.
Grazie al Service Broker il tutto avviene in maniera asincrona e molto scalabile. Questo approccio permette di tenere le diverse applicazioni totalmente disaccoppiate, fornendo un strato di comunicazione ed integrazione fatto solamente da servizi che utilizzano XML come mezzo di comunicazione (e validazione dei dati trasmessi).
Per far tutto c'è voluto più o meno mezza giornata, ed ora ho un sistema che è altamente scalabile e funzionante in tempo reale 
. Il tutto è stato ottenuto - e questo è l'importante - solamente lavorando a livello di database, senza dover mettere mano ad alcuna applicazione, ed assicurandomi cosi che in qualiasi modo un domani le mie applicazioni aggiungeranno nuovi utenti, questi saranno correttamente replicati ovunque serva. In modo asincrono, of course.