Choix d'une stratégie de démarrage
Cette rubrique décrit des options de l'activation de Service Broker.
Service Broker prend en charge la messagerie asynchrone, en file d'attente. Étant donné que les conversations peuvent durer des jours, des mois ou des années, nombre d'applications utilisent l'activation pour évoluer dynamiquement. Cette section décrit quelques stratégies courantes de démarrage d'une application qui utilise Service Broker.
Stratégies de démarrage
Les stratégies de démarrage d'une application se décomposent en quatre grandes catégories :
Activation interne
Activation basée sur des événements
Tâche planifiée
Tâche de démarrage
Chaque stratégie d'activation comporte des avantages. Une application peut associer ces différentes stratégies. Par exemple, une application peut, la plupart du temps, utiliser l'activation interne avec un petit nombre de lecteurs de file d'attente. Cependant, à certains moments de la journée, elle peut démarrer un nombre plus élevé de lecteurs de file d'attente.
Activation interne
Avec l'activation interne de Service Broker, un moniteur de file d'attente Service Broker active directement une procédure stockée lorsque cela est nécessaire. Il s'agit souvent de l'approche la plus simple. Lorsque vous employez l'activation directe d'une procédure stockée, il n'est pas nécessaire d'écrire du code supplémentaire dans l'application pour gérer l'activation. Toutefois, l'application doit être écrite en tant que procédure stockée SQL Server. Avec l'activation interne, vous écrivez l'application de sorte qu'elle se ferme lorsqu'il n'y a plus de messages à traiter.
Activation basée sur des événements
Certaines applications s'exécutent en réponse à un événement spécifique. Par exemple, vous pouvez exécuter une application lorsque le niveau d'utilisation de l'UC de l'ordinateur tombe en dessous d'un certain seuil. Vous pouvez aussi exécuter une application d'enregistrement lorsqu'une table est créée.
L'activation externe de Service Broker est un cas spécial d'activation basée sur des événements. Pour l'activation externe, l'application démarre en réponse à l'événement QUEUE_ACTIVATION.
Pour les événements susceptibles d'être déclenchés par des notifications d'événements, l'activation basée sur des événements peut être associée à l'activation interne de Service Broker. Dans ce cas, vous utilisez l'activation interne sur la file d'attente qui reçoit la notification d'événement. La procédure stockée d'activation reçoit le message de notification et démarre l'application.
Pour d'autres événements, vous pouvez utiliser l'Agent SQL Server pour démarrer des travaux sur l'ordinateur sur lequel SQL Server s'exécute. Vous pouvez écrire une application qui surveille les événements WMI (Windows Management Instrumentation) à partir d'un ordinateur distant. L'application peut démarrer une tâche lorsqu'un événement WMI se produit sur l'ordinateur qui exécute SQL Server.
Dans le contexte de l'activation basée sur des événements, une application se ferme en principe lorsqu'il n'y a plus de messages à traiter.
Tâche planifiée
Avec une tâche planifiée, une application est activée suivant une planification définie. Cette stratégie est pratique pour les applications de traitement par lots. Une application qui s'exécute en tant que tâche planifiée peut se fermer lorsqu'il n'y a plus de messages à traiter, ou le programme peut se fermer à un moment précis.
Par exemple, une application qui traite des commandes pour un fournisseur peut stocker les messages dans la journée puis traiter les messages la nuit pour générer une commande unique pour le fournisseur. Dans ce cas, l'application peut utiliser un travail de l'Agent SQL Server pour démarrer l'application à une heure spécifique chaque nuit.
Tâche de démarrage
Certaines applications démarrent une fois, généralement lorsque l'ordinateur démarre ou lors du démarrage de SQL Server. Une procédure stockée de démarrage dans SQL Server, une application du groupe de démarrage de Windows ou un service Windows constituent des exemples de tâches de démarrage. Dans ce cas, l'application s'exécute sans interruption et traite les messages au fur et à mesure qu'ils arrivent. Une application qui s'exécute continuellement ne requiert pas de temps de démarrage lorsqu'un message arrive dans la file d'attente. Toutefois, du fait que l'application ne se ferme pas si aucun message ne lui parvient, le programme consomme des ressources même lorsqu'il n'a aucune tâche à exécuter.
Cette stratégie peut être utile pour une application qui traite un flux de messages constant et qui consomme une quantité relativement importante de ressources au démarrage.
Voir aussi