Vantaggi di Service Broker

Integrazione con i database

La struttura integrata di Service Broker consente di ottenere vantaggi a livello di prestazioni e amministrazione delle applicazioni.

L'integrazione con SQL Server consente l'utilizzo di messaggistica transazionale senza l'overhead e la complessità di un DTC (Distributed Transaction Coordinator) esterno. Un'applicazione riceve uno o più messaggi, li elabora e quindi invia un messaggio di risposta in un'unica transazione di database. Se la transazione non è possibile, viene eseguito il rollback di tutto il lavoro e il messaggio ricevuto viene restituito alla coda in modo da consentire un ulteriore tentativo di elaborazione. Nessuna azione viene resa effettiva finché l'applicazione non esegue il commit della transazione. L'applicazione rimane in uno stato consistente.

Quando i dati, i messaggi e la logica dell'applicazione sono tutti inclusi nel database, l'amministrazione dell'applicazione (ripristino di emergenza, protezione, backup e così via) è più semplice poiché rientra nella normale attività di amministrazione del database, evitando la gestione di tre o quattro componenti separati.

Con i sistemi di messaggistica tradizionali possono nascere inconsistenza tra l'archivio dei messaggi e il database. Quando, ad esempio, un componente viene ripristinato da un backup, deve essere ripristinato anche l'altro componente dallo stesso backup creato contemporaneamente. In caso contrario le informazioni nell'archivio dei messaggi non corrispondono alle informazioni contenute nel database. Con Service Broker non si creano problemi di inconsistenza poiché i messaggi e i dati si trovano nello stesso database.

L'ambiente di sviluppo comune costituisce un ulteriore vantaggio dell'integrazione con i database. In un'applicazione di Service Broker la parte relativa alla messaggistica e la parte relativa ai dati dell'applicazione possono utilizzare gli stessi linguaggi e strumenti di SQL Server e usufruire della conoscenza delle tecniche di programmazione di database dello sviluppatore per la programmazione basata sui messaggi. È possibile scrivere le stored procedure che implementano un servizio di Service Broker in Transact-SQL o in un linguaggio CLR (Common Language Runtime). I programmi esterni al database utilizzano Transact-SQL e interfacce di programmazione di database familiari, ad esempio ADO.NET.

L'integrazione con i database consente inoltre la gestione automatica delle risorse. Service Broker viene eseguito nel contesto dell'istanza di SQL Server e pertanto esegue il monitoraggio di tutti i messaggi pronti per la trasmissione da tutti i database nell'istanza. In questo modo ogni database è in grado di gestire le proprie code e consentire a Service Broker la gestione dell'utilizzo delle risorse nell'intera istanza di SQL Server.

Ordinamento e coordinamento dei messaggi

Nei sistemi di messaggistica tradizionali l'applicazione ordina e coordina i messaggi il cui ordine non è corretto. Ad esempio, l'applicazione A invia i messaggi 1, 2 e 3. L'applicazione B riceve e invia un acknowledgment per i messaggi 1 e 3 mentre per il messaggio 2 si verifica un errore. L'applicazione A invia di nuovo il messaggio 2 che viene ricevuto dopo i messaggi 1 e 3. In precedenza l'applicazione doveva essere scritta in modo da ignorare l'ordine dei messaggi oppure memorizzare temporaneamente il messaggio 3 nella cache fino all'arrivo del messaggio 2 per consentire l'elaborazione dei messaggi nell'ordine corretto. Nessuna delle due soluzioni è diretta o semplice.

Un ulteriore problema dei sistemi tradizionali è costituito dal recapito duplicato. Nell'esempio precedente, se l'applicazione B riceve il messaggio 2 ma il messaggio di acknowledgement restituito all'applicazione A viene perso, l'applicazione A invia di nuovo il messaggio 2 e, di conseguenza, l'applicazione B riceve il messaggio 2 due volte. Il codice dell'applicazione deve quindi essere in grado di identificare ed eliminare il messaggio duplicato o di rielaborarlo senza effetti negativi. Anche in questo caso l'implementazione dell'uno o dell'altro approccio non è semplice.

Il coordinamento dei messaggi costituisce un ulteriore aspetto da sempre difficile da gestire. È possibile, ad esempio, che un'applicazione invii centinaia o migliaia di messaggi a un servizio che elabora le richieste in parallelo e restituisce una risposta subito dopo aver completato l'elaborazione della richiesta. Per ogni richiesta è necessario un tempo di elaborazione diverso. L'applicazione quindi riceve le risposte in un ordine diverso rispetto all'ordine di invio dei messaggi in uscita. Per la corretta elaborazione delle risposte, tuttavia, l'applicazione deve associare ogni risposta con il messaggio in uscita corretto. Nei sistemi di messaggistica tradizionali sono le applicazioni a gestire tale associazione, con il conseguente aumento dei costi e della complessità correlati allo sviluppo applicativo.

Service Broker risolve questi problemi mediante la gestione automatica dell'ordine dei messaggi, del recapito univoco e dell'identificazione della conversazione. Dopo aver stabilito la conversazione tra due endpoint di Service Broker, l'applicazione riceve ogni messaggio una sola volta e nell'ordine in cui è stato inviato. L'applicazione può quindi elaborare i messaggi una sola volta, nell'ordine corretto e senza codice aggiuntivo. Service Broker infine include automaticamente un identificatore in ogni messaggio, in modo che l'applicazione sia sempre in grado di identificare la conversazione alla quale appartiene un messaggio specifico.

Regime di controllo libero e flessibilità del carico di lavoro

Service Broker supporta il regime di controllo libero tra l'applicazione di origine e quella di destinazione. Un'applicazione può inviare un messaggio a una coda e continuare l'attività di elaborazione mentre Service Broker verifica che il messaggio raggiunga la destinazione. Questo regime di controllo libero consente una maggiore flessibilità di pianificazione. L'initiator può inviare più messaggi e più servizi di destinazione possono elaborarli in parallelo. Ogni servizio di destinazione elabora i messaggi in base ai propri tempi a seconda del carico di lavoro corrente.

L'accodamento inoltre consente ai sistemi di distribuire l'elaborazione più uniformemente e di ridurre la capacità massima richiesta da un server. Questo può contribuire al miglioramento complessivo della velocità effettiva e delle prestazioni delle applicazioni di database. In molte applicazioni di database, ad esempio, si verifica un picco delle transazioni in ore particolari della giornata, con il conseguente aumento del consumo di risorse e il rallentamento dei tempi di risposta. Con Service Broker queste applicazioni non devono eseguire tutta l'attività di elaborazione relativa a una transazione aziendale inviata all'applicazione. Al contrario, l'applicazione utilizza Service Broker per inviare informazioni sulla transazione alle applicazioni che eseguono l'elaborazione in background delle transazioni in maniera affidabile e per il tempo necessario, mentre l'applicazione di immissione principale continua a ricevere nuove transazioni aziendali.

Se la destinazione non è immediatamente disponibile, il messaggio rimane nella coda di trasmissione del database di invio. Service Broker ripete il tentativo di invio finché il messaggio non viene inviato correttamente o finché non scade la durata della conversazione, in modo da consentire la continuazione affidabile di una conversazione tra due servizi anche se uno di questi non è temporaneamente disponibile in un momento qualsiasi della conversazione. I messaggi nella coda di trasmissione costituiscono una parte del database. Per tale motivi Service Broker recapita il messaggio anche se si verifica un errore o viene eseguito il riavvio dell'istanza.

Blocco dei messaggi correlati

Uno dei risultati più difficili da ottenere in un'applicazione di messaggistica tradizionale è la lettura in parallelo dalla stessa coda da parte di più programmi. Nei sistemi di messaggistica tradizionali, quando la stessa coda viene letta da più programmi o thread, l'elaborazione dei messaggi può avvenire in ordine non corretto. Service Broker impedisce che si verifichi tale situazione mediante il blocco del gruppo di conversazioni.

Si consideri, ad esempio, un'applicazione di elaborazione degli ordini tradizionale. Il messaggio A, che contiene istruzioni sulla creazione dell'intestazione dell'ordine, e il messaggio B, che contiene istruzioni sulla creazione degli articoli dell'ordine, vengono entrambi inviati nella coda. Se per entrambi i messaggi l'accodamento viene annullato da istanze distinte dell'applicazione e i messaggi vengono elaborati contemporaneamente, è possibile che la transazione relativa agli articoli dell'ordine tenti di eseguire il commit per prima senza riuscirvi, poiché l'ordine non esiste ancora. L'errore causa, a sua volta, il rollback della transazione. Il messaggio viene reinserito nella coda e quindi rielaborato con un inutile consumo di risorse. Per risolvere questo problema, i programmatori combinano le informazioni del messaggio A e del messaggio B in un unico messaggio. Questo rappresenta un approccio semplice per due messaggi ma non è adatto ai sistemi che comportano il coordinamento di decine o centinaia di messaggi.

Service Broker consente di risolvere il problema mediante l'associazione di conversazioni correlate in un gruppo di conversazioni. Tutti i messaggi nello stesso gruppo di conversazioni vengono bloccati automaticamente per consentire la ricezione e l'elaborazione da parte di un'unica istanza dell'applicazione. Nel frattempo altre istanze dell'applicazione possono continuare ad annullare l'accodamento dei messaggi in altri gruppi di conversazioni e a eseguirne l'elaborazione. In questo modo è possibile utilizzare più istanze dell'applicazione in parallelo in modo affidabile ed efficiente senza alcuna necessità di aggiungere parti complesse di codice all'interno dell'applicazione per consentire la funzionalità di blocco.

Attivazione automatica

Una delle funzionalità più utili di Service Broker è costituita dall'attivazione, che consente la scalabilità dinamica di un'applicazione in base al volume dei messaggi che arrivano nella coda. Le funzionalità di Service Broker consentono di sfruttare i vantaggi dell'attivazione ai programmi eseguiti sia all'interno che all'esterno del database. L'utilizzo dell'attivazione da parte di un'applicazione, tuttavia, non è obbligatorio.

Service Broker esegue il monitoraggio dell'attività in una coda per determinare se un'applicazione riceve i messaggi per tutte le conversazioni per le quali vi sono messaggi disponibili. La funzionalità di attivazione di Service Broker avvia un nuovo lettore di coda ogni volta che è necessario. Per determinare quando è necessario l'avvio di un lettore di coda, viene monitorata l'attività della coda. Quando il numero di lettori di coda corrisponde al traffico in entrata, la coda raggiunge periodicamente uno stato in base al quale la coda risulta vuota o tutti i messaggi nella coda appartengono a una conversazione elaborata da un altro lettore di coda. Se la coda non raggiunge questo stato per un determinato intervallo di tempo, Service Broker attiva un'altra istanza dell'applicazione.

Le applicazioni utilizzano approcci di attivazione diversi per i programmi eseguiti all'interno e all'esterno del database. Per i programmi all'interno del database, Service Broker avvia un'altra copia della stored procedure specificata dalla coda. Per i programmi eseguiti all'esterno del database, Service Broker genera un evento di attivazione. Questo evento viene monitorato per determinare quando è necessario un lettore di coda ulteriore.

Service Broker non interrompe un programma avviato mediante l'attivazione. Le applicazioni attivate vengono sviluppate in modo da chiudersi automaticamente dopo un determinato intervallo di tempo senza l'arrivo di messaggi da inoltrare. Un'applicazione progettata in questo modo può consentire l'aumento e la diminuzione in modo dinamico del numero delle proprie istanze in base al volume di traffico per il servizio. Inoltre, in caso di arresto o riavvio del sistema, le applicazioni vengono avviate automaticamente per consentire la lettura dei messaggi nella coda al riavvio del sistema.

Nei sistemi di messaggistica tradizionali questa funzionalità non è disponibile e spesso vengono dedicate troppe o troppo poche risorse a una coda specifica in un determinato momento.

Vedere anche

Altre risorse