Funzioni di Service Broker

Conversazioni

Service Broker è progettato in relazione alle funzioni di base di invio e ricezione di messaggi. Ogni messaggio fa parte di una conversazione. Ogni conversazione è un canale di comunicazione affidabile e permanente. Ogni messaggio e ogni conversazione hanno un tipo specifico imposto da Service Broker per agevolare gli sviluppatori nella scrittura di applicazioni affidabili.

Le nuove istruzioni Transact-SQL consentono alle applicazioni di inviare e ricevere messaggi in modo affidabile. Un'applicazione invia messaggi a un servizio, costituito da un insieme di attività correlate e riceve i messaggi da una coda, costituita da una vista di una tabella interna.

I messaggi relativi alla stessa attività fanno parte della stessa conversazione. In ogni conversazione il compito di Service Broker è quello di garantire che un'applicazione riceva i messaggi una sola volta e rispettando l'ordine di invio. Il programma che implementa un servizio può associare le conversazioni correlate per lo stesso servizio in un gruppo di conversazioni, come illustrato in Vantaggi di Service Broker.

La protezione basata su certificati consente di proteggere i messaggi riservati e controllare l'accesso ai servizi. È possibile pensare a Service Broker come un servizio postale. Una conversazione con un collega lontano può avvenire tramite l'invio di lettere attraverso il servizio postale. Il servizio postale ordina e recapita le lettere. Le persone coinvolte nella conversazione recuperano quindi le lettere dalle cassette postali, le leggono, scrivono le risposte e inviano nuove lettere, fino alla conclusione della conversazione. Il recapito delle lettere avviene in modo asincrono, ovvero mentre le persone coinvolte nella conversazione sono impegnate in altre attività.

I programmi possono utilizzare Service Broker come un servizio postale per supportare le conversazioni asincrone con altri programmi. I messaggi di Service Broker funzionano come lettere. Un servizio di Service Broker è l'indirizzo al quale l'ufficio postale recapita le lettere. Le code corrispondono alle cassette postali che contengono le lettere recapitate. Le applicazioni ricevono i messaggi, eseguono le operazioni appropriate e inviano le risposte.

Quando un'applicazione invia un messaggio a un servizio di Service Broker, è isolata dai dettagli di implementazione dell'applicazione all'altro lato della conversazione. L'applicazione ricevente può essere riconfigurata dinamicamente o sostituita con il nuovo codice senza influire sull'applicazione mittente. L'applicazione ricevente può anche essere chiusa temporaneamente. In questo caso, Service Broker continua ad aggiungere nuovi messaggi alla coda fino al riavvio dell'applicazione ricevente.

Ordinamento e coordinamento dei messaggi

La gestione dell'accodamento, una tecnica comune di programmazione di database, da parte di Service Broker si differenzia rispetto ai prodotti tradizionali per due aspetti fondamentali:

• Le code di Service Broker sono integrate nel database.

• Le code coordinano e ordinano i messaggi correlati.

L'accodamento integrato implica l'inclusione di Service Broker nelle normali operazioni di manutenzione e amministrazione del database. In genere, un amministratore non svolge attività di manutenzione di routine relative a Service Broker.

Il framework di Service Broker combina una semplice interfaccia Transact-SQL per l'invio e la ricezione di messaggi con un insieme di garanzie avanzate per il recapito e l'elaborazione dei messaggi. Service Broker garantisce che un programma riceva ciascun messaggio di una conversazione una sola volta, in base all'ordine di invio, anziché in base all'ordine di inserimento nella coda. I prodotti di accodamento tradizionali recapitano i messaggi in base all'ordine con cui sono stati inseriti nella coda, lasciando all'applicazione il compito di determinare l'ordine e il raggruppamento dei messaggi. Service Broker garantisce che i messaggi di una stessa conversazione o di uno stesso gruppo di conversazioni correlate non vengano elaborati contemporaneamente da due strumenti di lettura coda.

Ogni conversazione di Service Broker è costituita da due lati. Il lato che avvia la conversazione è denominato Initiator, l'altro lato rappresenta la destinazione (Target). Su ogni lato è presente un servizio: il servizio Initiator e il servizio Target. A ogni servizio è associata una coda di messaggi.

Di seguito è illustrato lo scambio di messaggi in una conversazione di dialogo tipica:

• Nell'Initiator:

  • Un programma avvia la conversazione.

  • Il programma crea un messaggio contenente i dati necessari per eseguire un'attività.

  • Il programma invia il messaggio al servizio Target.

• Nella destinazione:

  • Il messaggio viene inserito nella coda associata al servizio Target.

  • Un programma riceve il messaggio dalla coda ed esegue il lavoro.

  • Il programma risponde inviando un messaggio al servizio Initiator.

• Nell'Initiator:

  • Il messaggio di risposta viene inserito nella coda associata al servizio Initiator.

  • Un programma riceve la risposta e la elabora.

Questo ciclo si ripete fino a quando l'Initiator non termina la conversazione in quanto non vi sono più richieste da inviare alla destinazione.

Service Broker supporta l'impostazione di livelli di priorità da 10 (elevata) a 1 (bassa) per ogni conversazione. Questo garantisce che le operazioni con priorità bassa non blocchino quelle con priorità più elevata. I sistemi Service Broker possono essere configurati per offrire diversi livelli di servizio. Per ulteriori informazioni, vedere Priorità di conversazione.

Service Broker gestisce le attività più complesse necessarie per la creazione di applicazioni di messaggistica. Queste attività includono coordinamento dei messaggi, recapito affidabile dei messaggi, blocco e avvio degli strumenti di lettura coda. In questo modo, gli sviluppatori di database possono concentrarsi sulla risoluzione dei problemi aziendali.

Programmazione asincrona transazionale

Nell'infrastruttura di Service Broker il recapito dei messaggi tra le applicazioni è transazionale e asincrono. Poiché la messaggistica di Service Broker è transazionale, se viene eseguito il rollback di una transazione, viene eseguito il rollback di tutte le operazioni di Service Broker nella transazione, incluse le operazioni di invio e ricezione. Con il recapito asincrono, il Motore di database gestisce il recapito durante la normale esecuzione dell'applicazione. Per consentire una scalabilità migliore, Service Broker dispone di meccanismi per l'avvio automatico dei programmi di elaborazione di una coda quando questi sono necessari per eseguire operazioni utili. Per ulteriori informazioni, vedere Attivazione di Service Broker.

La programmazione asincrona consente agli sviluppatori di scrivere applicazioni che utilizzano l'accodamento. In molte applicazioni di database sono presenti tabelle che svolgono la funzione di code di lavoro da evadere in base alla disponibilità delle risorse. Le code possono offrire due vantaggi alle applicazioni di database:

• Un'applicazione può rispondere a un utente interattivo immediatamente dopo l'inserimento della richiesta di lavoro in una coda. L'applicazione non deve attendere il completamento di tutto il lavoro associato alla richiesta prima di rispondere. La richiesta in coda viene elaborata quando le risorse sono disponibili. In questo modo, il database può continuare a rispondere agli utenti interattivi e ottimizzare l'utilizzo delle risorse disponibili.

• Il lavoro previsto in una singola richiesta può a volte essere suddiviso in più unità di lavoro elaborate come transazioni separate. In questo caso, un'applicazione di database può avviare ogni unità di lavoro inserendo una richiesta in una coda. In Service Broker questa idea viene estesa, consentendo alle applicazioni di distribuire il lavoro tra più istanze di Service Broker in computer separati.

La scrittura di codice per le applicazioni che consenta di ordinare ed elaborare correttamente gli elementi di una coda è spesso un'operazione complessa. Gli sviluppatori possono utilizzare la funzionalità di Service Broker incorporata nel Motore di database per semplificare la creazione di codice che consenta di implementare correttamente le code di database.

Supporto di applicazioni a regime di controllo libero

Service Broker supporta le applicazioni a regime di controllo libero ("loosely-coupled"). Tali applicazioni sono composte da più programmi che inviano e ricevono messaggi in modo indipendente tra loro e devono contenere le stesse definizioni per i messaggi scambiati, nonché definire la stessa struttura generale per l'interazione tra i servizi. Non è tuttavia necessario che le applicazioni vengano eseguite contemporaneamente o nella stessa istanza di SQL Server oppure che condividano i dettagli di implementazione. Per un'applicazione non è necessario conoscere la posizione fisica o l'implementazione dell'altro partecipante alla conversazione.

Componenti di Service Broker

Service Broker include tre tipi di componenti:

• Componenti di conversazione. Gruppi di conversazioni, conversazioni e messaggi costituiscono la struttura di run-time di un'applicazione di Service Broker. Le applicazioni scambiano messaggi nel contesto di una conversazione. Ogni conversazione fa parte di un gruppo di conversazioni, ognuno dei quali può contenere più conversazioni. Ogni conversazione di Service Broker rappresenta un dialogo. Una dialogo è una conversazione in cui esattamente due partecipanti scambiano messaggi. Per ulteriori informazioni sui componenti di conversazione, vedere Architettura delle conversazioni.

• Componenti di definizione dei servizi. Si tratta di componenti della modalità progettazione che specificano la struttura di base delle conversazioni utilizzata dall'applicazione. Definiscono i tipi di messaggi, il flusso della conversazione e l'archiviazione nel database per l'applicazione. Per ulteriori informazioni sui componenti di definizione dei servizi, vedere Architettura dei servizi.

• Componenti di rete e di protezione. Questi componenti definiscono l'infrastruttura utilizzata per scambiare messaggi tra istanze del Motore di database. Per agevolare la gestione di ambienti soggetti a cambiamenti, Service Broker consente agli amministratori di database di configurare questi componenti in modo indipendente dal codice dell'applicazione. Per ulteriori informazioni sui componenti di rete e di protezione, vedere funzionalità di rete e sicurezza remota.

I componenti di definizione dei servizi, i componenti di rete e i componenti di protezione fanno parte dei metadati per il database e l'istanza di SQL Server. Gruppi di conversazioni, conversazioni e messaggi fanno parte dei dati contenuti nel database.

Vedere anche

Concetti

Altre risorse