Introduzione a SQL 2005 Service Broker
Il servizio, nativo in SQL Server 2005, consente di gestire messaggi asincroni all’interno di un database, fra istanze diverse di database o fra SQL Server diversi su macchine separate. Il modello di funzionamento è simile a altri prodotti di gestione messaggi basata su code (Microsoft Message Queue ad esempio). L’obiettivo è semplice: aumentare il livello di scalabilità delle applicazioni front-end rimandando al back-end il grosso del lavoro. Proviamo a spiegarci con un esempio classico: su un sito di commercio elettronico, a fronte di un acquisto, deve partire un processo di generazione dell’ordine che sicuramente comporta operazioni sul magazzino, la generazione delle informazioni sulla spedizione, il controllo della disponibilità finanziaria del cliente e probabilmente varie altre operazioni. Se queste operazioni sono eseguite dalla pagina di check-out viene bloccato un thread dell’applicazione ASP.NET per tutta la durata del processo e vengono eseguiti dei lock sulle varie tabelle che possono rallentare altri ordini da processare; inoltre, tutte le risorse coinvolte devono essere disponibili al momento dell’acquisto; non ultimo la comunicazione fra l’applicazione e le risorse deve essere molto efficiente per non rallentare appunto l’intero front-end. In ASP.NET 2.0, tramite l’attributo Async è possibile semplicare il lavoro da fare (nel codice per la versione 1.x) per liberare il thread e renderlo disponibile per le successive richieste. Per una panoramica sulla problematica relativa a thread e thread pool si veda http://blogs.devleap.com/articolidevleap/archive/2006/01/12/6505.aspx.
Attributo Async a parte, spostare il lavoro sul back-end libera il front-end dall’onere di processare un acquisto. L’idea è molto semplice: quando si deve processare un acquisto, il front-end esegue il minor lavoro possibile inserendo le informazioni inerenti in un database; il front-end analizzerà queste informazioni e procederà con il processo di generazione “vero” dell’ordine. Dove sta la novità? Da sempre possiamo creare strutture (tabelle) che accolgano queste informazioni e applicazioni che leggono tali tabelle per eseguire dietro le quinte il processo relativo.
L’obiettivo di SQL 2005 Service Broker è fornire tutta l’infrastruttura necessaria per gestire questo flusso. Il prodotto mette a disposizione, direttamente nel database, i servizi necessari e le instruzioni T-SQL per creare i messaggi che contengono le informazioni per il processo da eseguire, le code che accettano tali messaggi, i servizi per garantire l’arrivo e l’ordine di arrivo dei messaggi, i servizi per garantire la transazionalità delle operazioni fra code e tabelle tradizionali. In pratica il prodotto elimina la necessità di creare le strutture e soprattutto i processi che garantiscono affidabilità alla soluzione. Il prodotto può essere visto come rivale di MSMQ (che fornisce le stesse funzionalità come servizio Windows): quale scegliere ? Dipende dall’applicazione e dal contesto: avere il supporto interno al database rende più semplice l’amministrazione, il backup e restore (i messaggi e le strutture fanno parte del db quindi rientrano nel backup), la manutenzione in quanto tutto è residente in un database e sicuramente non implica la conoscenza di prodotti esterni. D’altro canto MSMQ è utilizzabile in contesti dove non viene impiegato SQL Server 2005, è integrabile con prodotti di terze parti come MQSeries di IBM, è utilizzabile da client Windows CE dove per adesso SQL 2005 Mobile Edition non offre tali servizi.
Articolo tratto da week.it del 12/2/2006.