Scelta di una strategia di avvio
In questo argomento vengono descritte le opzioni per l'attivazione di Service Broker.
Service Broker supporta soluzioni di messaggistica asincrona con l'utilizzo di code. Poiché le conversazioni possono durare giorni, mesi o anni, molte applicazioni utilizzano l'attivazione per il ridimensionamento dinamico. In questa sezione vengono descritte alcune strategie comuni per l'avvio di un'applicazione che utilizza Service Broker.
Strategie di avvio
Le strategie per l'avvio di un'applicazione rientrano in quattro ampie categorie:
Attivazione interna
Attivazione basata su eventi
Attività pianificata.
Attività di avvio
A ogni strategia di attivazione sono associati vantaggi diversi e un'applicazione può combinare tali strategie. Un'applicazione può utilizzare ad esempio l'attivazione interna con un numero ridotto agenti di lettura coda durante la maggior parte del tempo, ma può avviare più agenti di lettura coda in ore specifiche del giorno.
Attivazione interna
Nell'attivazione interna di Service Broker un monitor di coda di Service Broker attiva direttamente una stored procedure quando è necessario. Questo approccio è spesso quello più semplice, poiché tramite l'attivazione diretta di una stored procedure non è necessario scrivere codice aggiuntivo nell'applicazione per gestire l'attivazione. Per utilizzare l'attivazione interna tuttavia è necessario che l'applicazione venga scritta come una stored procedure di SQL Server. Quando si utilizza l'attivazione interna, scrivere l'applicazione in modo da uscire quando non sono più presenti messaggi da elaborare.
Attivazione basata su eventi
Alcune applicazioni vengono eseguite in risposta a un evento specifico. È possibile ad esempio eseguire un'applicazione quando la percentuale di utilizzo della CPU nel computer è minore di un livello specifico oppure è possibile eseguire un'applicazione per la registrazione quando viene creata una nuova tabella.
L'attivazione esterna di Service Broker costituisce un caso speciale dell'attivazione basata su eventi. Nell'attivazione esterna l'applicazione viene avviata in risposta all'evento QUEUE_ACTIVATION.
Per eventi che possono essere attivati dalle notifiche, l'attivazione basata su eventi può essere combinata con l'attivazione interna di Service Broker. In questo caso, utilizzare l'attivazione interna sulla coda che riceve la notifica degli eventi. La stored procedure di attivazione riceve il messaggio di notifica e avvia l'applicazione.
Per altri eventi, è possibile utilizzare SQL Server Agent per avviare processi nello stesso computer in cui SQL Server è in esecuzione. È possibile scrivere un'applicazione che esegue il monitoraggio di eventi WMI da un computer remoto. L'applicazione può avviare un'attività quando si verifica un evento WMI nel computer che esegue SQL Server.
Quando si utilizza l'attivazione basata su eventi, si esce in genere da un'applicazione quando non sono più presenti messaggi da elaborare.
Attività pianificata.
Se si utilizza l'attività pianificata, un'applicazione viene attivata in base a una pianificazione impostata. Questa strategia è conveniente per le applicazioni di elaborazione batch. È possibile uscire da un'applicazione in esecuzione come attività pianificata non sono più presenti messaggi da elaborare oppure in un momento specifico.
Un'applicazione che elabora ordini per un fornitore ad esempio può archiviare i messaggi durante il giorno, quindi elaborarli durante la notte per creare un unico ordine per il fornitore. In questo caso, l'applicazione può utilizzare un processo di SQL Server Agent per avviare l'applicazione a un'ora specifica ogni notte.
Attività di avvio
Alcune applicazioni vengono solo una volta, in genere all'avvio del computer o di SQL Server. Esempi di queste attività sono costituiti da una stored procedure di avvio in SQL Server, da un'applicazione nel gruppo di avvio di Windows o da un servizio Windows. In questo caso, l'applicazione rimane in esecuzione ed elabora i messaggi man mano che arrivano. Per un'applicazione continuamente in esecuzione non è necessario il tempo di avvio quando un messaggio arriva nella coda. Poiché non è possibile uscire dall'applicazione quando non sono presenti messaggi, il programma tuttavia utilizza risorse anche quando non sono presenti operazioni da eseguire.
Questa strategia può risultare utile per un'applicazione che elabora un flusso costante di messaggi e che utilizza un numero relativamente elevato di risorse durante l'avvio.
Vedere anche