Condividi tramite

Che cosa fa Service Broker?

Si applica a: SQL Server Istanza gestita di SQL di Azure

Service Broker consente agli sviluppatori di compilare applicazioni asincrone a regime di controllo libero in cui componenti indipendenti collaborano per completare un'attività. Questi componenti dell'applicazione scambiano messaggi che contengono le informazioni necessarie per completare l'attività. Questo argomento descrive gli aspetti seguenti di Service Broker:

  • Conversazioni

  • Ordinamento e coordinamento dei messaggi

  • Programmazione asincrona transazionale

  • Supporto per applicazioni ad accoppiamento libero

  • Componenti 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 persistente. 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, ovvero un nome per un set di attività correlate. Un'applicazione riceve messaggi da una coda, ovvero una visualizzazione di una tabella interna.

I messaggi per la stessa attività fanno parte della stessa conversazione. In ogni conversazione il compito di Service Broker è quello di garantire che un'applicazione riceva i messaggi esattamente una 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.

La sicurezza basata su certificati consente di proteggere i messaggi sensibili e controllare l'accesso ai servizi. È possibile pensare a Service Broker come un servizio postale. Per tenere una conversazione con un collega distante, è possibile inviare lettere tramite il servizio postale. Il servizio postale ordina e recapita le lettere. L'utente e il collega recuperano quindi le lettere dalle cassette postali, le leggono, scrivono risposte e inviano nuove lettere fino al termine della conversazione. Il recapito delle lettere viene eseguito in modo asincrono mentre l'utente e il collega gestiscono altre attività.

Due utenti si scambiano posta tramite un servizio postale.

I programmi possono usare 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 sono le cassette postali che contengono le lettere dopo il recapito. Le applicazioni ricevono i messaggi, agiscono sui messaggi e inviano risposte.

Quando un'applicazione invia un messaggio a un servizio di Service Broker, è isolata dai dettagli di implementazione dell'applicazione sull'altro lato della conversazione. L'applicazione ricevente può essere riconfigurata in modo dinamico o sostituita con un nuovo codice senza influire sull'applicazione di invio. 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 offre una semplice interfaccia Transact-SQL per l'invio e la ricezione di messaggi combinata con un set di garanzie avanzate per il recapito e l'elaborazione dei messaggi. Service Broker garantisce che un programma riceva ogni messaggio in una conversazione esattamente una volta e nell'ordine di invio del messaggio, non nell'ordine in cui il messaggio è stato inserito nella coda. I prodotti di accodamento tradizionali forniscono messaggi nell'ordine in cui i messaggi sono arrivati 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 ha due lati. Il lato che avvia la conversazione viene chiamato iniziatore mentre l'altro lato è detto destinazione. Ogni lato ha un servizio: servizio iniziatore e servizio di destinazione. Ogni servizio ha una coda di messaggi associata.

Di seguito viene illustrato lo scambio di messaggi in una tipica conversazione di interazione:

  • Lato iniziatore:

  • Un programma inizia la conversazione.

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

  • Il programma invia il messaggio al servizio di destinazione.

  • Lato destinazione:

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

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

    • Il programma risponde inviando un messaggio al servizio iniziatore.

  • Lato iniziatore:

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

    • Un programma riceve la risposta e la elabora.

Questo ciclo si ripete fino a quando l'iniziatore termina la conversazione perché non ha più richieste di invio per la destinazione.

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

Service Broker gestisce le attività più complesse necessarie per la creazione di applicazioni di messaggistica. Queste attività difficili includono il coordinamento dei messaggi, il recapito affidabile dei messaggi, il blocco e l'avvio dei lettori della coda. Ciò consente agli sviluppatori di database di concentrarsi su come risolvere i 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, Questa operazione include le operazioni di invio e ricezione. Con il recapito asincrono, il motore di database gestisce il recapito durante la normale esecuzione dell'applicazione. Per migliorare la scalabilità, 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 altre informazioni, vedere Attivazione di Service Broker.

La programmazione asincrona consente agli sviluppatori di scrivere applicazioni che usano l'accodamento. Molte applicazioni di database includono tabelle che funzionano come code di lavoro da eseguire quando le risorse lo consentono. Le code possono offrire due vantaggi alle applicazioni di database:

  • Un'applicazione può rispondere a un utente interattivo immediatamente dopo aver inserito la richiesta di lavoro in una coda. L'applicazione non deve attendere il completamento di tutte le operazioni associate alla richiesta prima di rispondere. La richiesta in coda viene elaborata quando sono disponibili le risorse. In questo modo il database rimane reattivo per gli utenti interattivi e usa in modo efficiente le risorse disponibili.

  • Il lavoro coinvolto in una singola richiesta può talvolta 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 codifica delle applicazioni per sequenziare ed elaborare correttamente gli elementi nelle code è spesso complicata. Gli sviluppatori possono usare la funzionalità di Service Broker incorporata nel motore di database per semplificare la scrittura di codice che consenta di implementare correttamente le code di database.

Supporto per applicazioni ad accoppiamento libero

Service Broker supporta applicazioni a regime di controllo libero. Le applicazioni ad accoppiamento libero sono costituite da più programmi che inviano e ricevono messaggi indipendentemente l'uno dall'altro. Tali applicazioni devono contenere le stesse definizioni per i messaggi scambiati e devono definire la stessa struttura complessiva 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. Un'applicazione non deve conoscere la posizione fisica o l'implementazione dell'altro partecipante della conversazione.

Componenti di Service Broker

Service Broker include tre tipi di componenti:

  • Componenti della conversazione. Gruppi di conversazioni, conversazioni e messaggi costituiscono la struttura di run-time di un'applicazione di Service Broker. Le applicazioni si scambiano messaggi come parte di una conversazione. Ogni conversazione fa parte di un gruppo di conversazioni e un gruppo di conversazioni può contenere più conversazioni. Ogni conversazione di Service Broker è un dialogo. Una interazione è una conversazione in cui esattamente due partecipanti scambiano messaggi. Per altre informazioni sui componenti di conversazione, vedere Architettura della conversazione.

  • Componenti di definizione del servizio. Si tratta di componenti della fase di progettazione che specificano la struttura di base delle conversazioni usate dall'applicazione. Questi componenti definiscono i tipi di messaggio, il flusso di conversazione e l'archiviazione del database per l'applicazione. Per altre informazioni sui componenti di definizione dei servizi, vedere Architettura dei servizi.

  • Componenti di rete e sicurezza. Questi componenti definiscono l'infrastruttura usata per lo scambio di messaggi tra le istanze del motore di database. Per agevolare la gestione di ambienti in continua evoluzione, Service Broker onsente agli amministratori di database di configurare questi componenti in modo indipendente dal codice dell'applicazione. Per altre informazioni sui componenti di rete e di sicurezza, vedere Rete e sicurezza remota.

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

Vedi anche