Gestion des états
Une application qui gère l'état stocke généralement cet état dans des tables de base de données. Dans la mesure où chaque groupe de conversations possède un identificateur unique, cet identificateur est généralement utilisé comme clé pour la table d'état. Service Broker assure également la rétention des messages pour les applications qui doivent conserver les messages précis qui ont été envoyés et reçus.
Pour de nombreuses applications, les informations d'état ne sont pas nécessaires. En général, une application gère l'état si la tâche implique plusieurs messages et si certaines informations concernant la tâche ne peuvent pas être stockées dans les tables existantes de la base de données.
Par exemple, une application qui recherche et retourne des informations client ne requiert pas d'état, et elle n'utilise pas de table d'état. En revanche, une application qui gère l'exécution des commandes génère des demandes destinées à d'autres services. Un programme qui coordonne les demandes destinées à d'autres services emploie souvent une table d'état pour assurer le suivi des demandes. L'application met à jour les tables de données et efface la table d'état lorsque toutes les demandes ont été correctement traitées. Si une demande retourne une erreur, l'application renvoie la demande ou utilise la table d'état pour envoyer une demande de compensation.
Une application peut également utiliser une table d'état à des fins d'audit ou de consignation. L'application enregistre dans la table d'état les informations importantes concernant chaque requête. Dans ce cas, l'application ne supprime pas les informations de la table d'état lorsqu'une conversation prend fin.
Certaines applications ont parfois besoin d'un enregistrement précis des messages envoyés et reçus lorsque la conversation est active. Pour ce cas de figure, Service Broker assure la rétention des messages.
Voir aussi