Groupes de conversations
Un groupe de conversations désigne un ensemble de conversations connexes. Ce type de groupe permet à une application de coordonner facilement les conversations impliquées dans une tâche d'entreprise spécifique.
Chaque conversation appartient à un seul groupe de conversations. Chaque groupe étant associé à un service spécifique, toutes les conversations du groupe sont des conversations en provenance ou à destination du service rattaché. Un groupe de conversations peut contenir un nombre illimité de conversations.
SQL Server utilise des groupes de conversations pour fournir un accès EOIO (Exactly-Once-In-Order) aux messages liés à une tâche d'entreprise particulière. Lorsqu'une application envoie ou reçoit un message, SQL Server verrouille le groupe de conversations auquel le message appartient. De cette façon, une seule session à la fois peut recevoir des messages pour le groupe de conversations. Le verrouillage du groupe de conversations garantit le traitement par une application des messages de chaque conversation une seule et unique fois, dans l'ordre de leur envoi. Étant donné qu'un groupe de conversations peut contenir plusieurs conversations, l'application se sert des groupes de conversations pour identifier les messages liés à une même tâche afin de les traiter ensemble.
Un groupe de conversations n'est pas partagé entre les participants d'une conversation. Par conséquent, chacun est libre d'associer la conversation en fonction de ses attentes. Une application peut gérer des interactions complexes parmi des services, sans pour autant requérir auprès d'eux une prise en charge spéciale.
Exemples de groupes de conversations
Une application de ressources humaines peut disposer d'un service GetEmployeeInformation qui combine des informations provenant d'un service de paie avec celles d'un service d'avantages sociaux. Le service GetEmployeeInformation engage une conversation avec chaque service et relie une conversation à l'autre dans le même groupe de conversations. Service Broker ajoute l'identificateur du groupe de conversations à chaque message entrant sur ces deux conversations, que le message provienne du service de la paie ou du service des avantages sociaux. Dans la mesure où les conversations se retrouvent dans le même groupe de conversations, Service Broker fournit toutes les informations nécessaires pour que le service GetEmployeeInformation fasse correspondre les informations sur les avantages sociaux avec celles de la paie, peu importe le nombre de demandes en cours dans le service GetEmployeeInformation.
Les messages envoyés au service de la paie et au service des avantages sociaux ne contiennent aucune information de groupe de conversations pour le groupe de conversations créé par GetEmployeeInformation. Chaque service fonctionne de façon autonome, seul le service GetEmployeeInformation gère les informations concernant l'ensemble de la tâche d'entreprise concernée. Le codage et la gestion de chaque service sont facilités en maintenant ces services indépendants l'un de l'autre. Cette caractéristique présente également un avantage puisqu'un service peut continuer de fonctionner tandis que l'autre est indisponible.
Organisation de l'état de l'application
L'un des avantages du groupe de conversations réside dans son identificateur, qui se révèle une clé pratique permettant d'identifier et de récupérer l'état de l'application. L'identificateur du groupe de conversations facilite la gestion de l'état de l'application dans la base de données. Si, avec le temps, l'accomplissement d'une tâche implique l'échange de nombreux messages, conserver une instance de l'application en cours d'exécution uniquement pour gérer l'état de cette application représente une solution peu efficace. Une application évolue mieux si, entre les messages, toute donnée associée à la tâche est stockée dans la base de données, puis récupérée lorsque le message suivant lié à cette tâche est reçu. L'identificateur du groupe de conversations peut être utilisé en guise de clé primaire, dans une table d'états fournie par un développeur d'applications, pour faciliter la récupération rapide de l'état associé à une tâche particulière. For more information about using the conversation group identifier to maintain state, see Gestion des états.
Chaque fois qu'une application envoie ou reçoit un message, SQL Server verrouille le groupe de conversations : une application n'a donc pas besoin d'empêcher explicitement un autre programme de mettre à jour les mêmes données d'état au même moment. Il lui suffit de verrouiller le groupe de conversations, restaurer l'état, traiter les messages, mettre l'état à jour, puis valider la transaction.
Pour plus de commodité, SQL Server permet à une application de verrouiller le prochain groupe de conversations disponible sans forcément recevoir de message. Grâce à l'instruction GET CONVERSATION GROUP, une application peut verrouiller un groupe de conversations et restaurer l'état avant le traitement des messages. Voir l'instruction GET CONVERSATION GROUP (Transact-SQL) pour plus d'informations.
Durée de vie du groupe de conversations
Service Broker gère la durée de vie du groupe de conversations. Il n'est pas nécessaire de créer ou de détruire explicitement un groupe de conversations. Service Broker crée un nouveau groupe de conversations dans les circonstances suivantes :
Une application engage une nouvelle conversation qui n'est apparentée à aucun groupe de conversations existant. Service Broker crée un nouveau groupe de conversations et attribue un nouvel identificateur à ce groupe.
Une application engage une conversation apparentée à un identificateur de groupe de conversations qui n'existe pas actuellement. Dans ce cas, Service Broker crée un nouveau groupe de conversations à l'aide de l'identificateur spécifié. Ceci signifie, entre autres, que vous pouvez attribuer la valeur de votre choix à un identificateur de groupe de conversations.
Service Broker reçoit le premier message d'une nouvelle conversation démarrée par un autre service. Dans ce cas, il utilise le nom du service et l'identificateur de l'instance du broker (le cas échéant) pour effectuer les opérations suivantes :
trouver la file d'attente appropriée ;
créer un nouveau groupe de conversations pour l'associer à la file d'attente ;
créer un nouveau handle de conversation pour l'ajouter au nouveau groupe de conversations ;
placer le message entrant dans la file d'attente.
Service Broker ajoute l'identificateur du groupe de conversations aux métadonnées de la conversation qui a créé le groupe de conversations. Chaque fois que Service Broker reçoit un message pour une conversation connexe au groupe de conversations, il ajoute l'identificateur du groupe de conversations à ce message avant de l'intégrer à la file d'attente.
Un identificateur de groupe de conversations est valide depuis le moment où Service Broker l'a créé jusqu'à la conclusion de toutes les conversations qui lui sont associées. Autrement dit, la validité de l'identificateur du groupe de conversations est garantie tant qu'une conversation demeure active dans le groupe.
Une application qui utilise l'identificateur du groupe de conversations pour gérer son état exploite une table d'états fournie par le développeur. L'application doit supprimer cet état à partir de la table utilisée lorsqu'elle détermine que l'état en question n'est plus nécessaire. Bien souvent, l'application supprime l'état une fois la tâche correctement effectuée ou après la notification d'erreurs indiquant que la tâche n'a pu être exécutée. Dans ces cas-là, l'application inclut généralement la commande de suppression de l'état dans la transaction qui envoie le dernier message de réponse et conclut la conversation. Cette stratégie permet de garantir une durée de vie identique à l'état de l'application et à l'identificateur du groupe de conversations. Si l'opération d'envoi échoue, l'opération de suppression est annulée. De même, si l'opération de suppression échoue, l'opération d'envoi est annulée et SQL Server n'envoie pas le message. Dans un cas comme dans l'autre, l'état de l'application et l'identificateur du groupe de conversations demeurent valides. Si les deux opérations se sont déroulées correctement, l'existence de l'identificateur du groupe de conversations s'achève au moment où l'état de l'application qui lui était associé est supprimé par le programme.
Voir aussi