Ricezione di notifiche
Molte applicazioni non devono necessariamente contenere codice per la ricezione o l'elaborazione di notifiche delle query. Se la sottoscrizione di notifica viene gestita da un oggetto SqlDependency, tale oggetto esegue automaticamente il monitoraggio della sottoscrizione. Quando arriva un messaggio di notifica, l'oggetto SqlDependency chiama il gestore dell'evento registrato nell'oggetto stesso. In tal modo, non sono necessarie operazioni speciali per ricevere la notifica. Un'applicazione che utilizza l'oggetto SqlDependency non deve necessariamente ricevere o elaborare i messaggi di notifica.
Se invece l'applicazione utilizza una richiesta di notifica, deve monitorare la coda e rispondere al messaggio di notifica. In tal caso, è necessario creare un'applicazione che elabora messaggi per il servizio che riceve le notifiche. L'applicazione che richiede la notifica può essere la stessa che elabora il messaggio. In alternativa, è possibile creare un'altra applicazione per ricevere il messaggio di notifica della query e rispondere a tale messaggio.
SQL Server tiene traccia delle sottoscrizioni di notifica utilizzando l'ID di notifica e la query effettiva inoltrata. Se un'applicazione richiede una notifica per due query diverse utilizzando lo stesso ID di notifica, SQL Server crea due sottoscrizioni con lo stesso ID di notifica. Se invece un'applicazione richiede due volte una notifica per la stessa query con lo stesso ID di notifica, SQL Server crea un singola sottoscrizione con il timeout specificato nella seconda richiesta.
In genere, le applicazioni eseguite nel database sono stored procedure attivate dalla coda all'arrivo di un messaggio. È possibile creare tali stored procedure utilizzando Transact-SQL o uno dei linguaggi .NET. Più raramente, l'applicazione viene eseguita come un processo pianificato oppure viene utilizzata un'attività di avvio per eseguire continuamente una stored procedure in background.
Le applicazioni eseguite al di fuori del database utilizzano in genere per la ricezione dei messaggi uno degli approcci seguenti:
L'applicazione può eseguire periodicamente il polling della coda per verificare se è arrivato un messaggio.
L'applicazione può utilizzare la clausola WAITFOR dell'istruzione RECEIVE per bloccare l'esecuzione di un batch o di una stored procedure in un'istruzione RECEIVE fino a quando l'istruzione restituisce almeno una riga.
L'applicazione può creare una notifica per l'evento QUEUE_ACTIVATION nella coda che riceve la notifica. L'applicazione può quindi monitorare il servizio che riceve l'evento di attivazione mediante una delle due strategie precedenti.
Più raramente, viene utilizzato il monitoraggio dell'attivazione della coda tramite WMI o viene creata una stored procedure CLR (Common Language Runtime) che esegue alcune azioni esterne in risposta a un messaggio.
Poiché i dialoghi di notifica delle query contengono sempre un singolo messaggio di notifica, un'applicazione che elabora le notifiche delle query deve terminare la conversazione dopo la ricezione di un messaggio. In caso contrario, si verifica infine il timeout del dialogo. Quando si verifica il timeout di un dialogo di notifica delle query, SQL Server registra l'errore di timeout del dialogo nel log degli errori di SQL Server.
Per ulteriori informazioni sulla creazione di un'applicazione che utilizza Service Broker, vedere Vantaggi della programmazione con Service Broker. Per ulteriori informazioni sull'avvio di un'applicazione che utilizza Service Broker, vedere Scelta di una strategia di avvio.