Conversations de dialogue
Tous les messages envoyés par Service Broker font partie intégrante d'une conversation. Un dialogue est une conversation entre deux services. Un dialogue est un flux de messages bidirectionnel permanent et sûr entre deux services.
Les dialogues assurent la remise de messages EOIO (Exactly-Once In-Order Delivery). Ils utilisent l'identificateur de conversation et le numéro de séquence contenus dans chaque message pour identifier les messages apparentés et les livrer dans l'ordre correct. Un dialogue est un flux de messages permanent et sûr entre deux services.
Une conversation de dialogue sous-entend deux participants. L'initiateur lance la conversation. La cible accepte la conversation entamée par l'initiateur. Le fait qu'un participant lance une conversation détermine les messages qu'il peut envoyer, comme spécifié dans le contrat de la conversation. Le schéma suivant illustre le flux de messages d'un dialogue :
.gif "Flux de messages entre initiateur et cible")
Les applications échangent des messages dans le cadre d'un dialogue. Un message destiné à un dialogue qui est reçu par SQL Server est placé dans la file d'attente de ce dialogue. L'application reçoit donc le message par le biais de la file d'attente et traite le message comme il se doit. Au cours de ce traitement, l'application peut envoyer des messages à l'autre participant du dialogue.
Remise fiable
Les dialogues comprennent des accusés de réception de messages automatiques pour garantir la fiabilité de la livraison. Service Broker conserve chaque message sortant dans la file d'attente de transmission jusqu'à ce que le service distant en accuse réception. Ces avis de réception automatiques économisent temps et ressources car la notification formelle d'arrivée de chaque message qui est effectuée par les applications n'est plus nécessaire. Chaque fois que cela est possible, les messages d'accusés de réception sont intégrés dans les messages de retour du dialogue.
Notes
Service Broker gère les accusés de réception en interne. Ils n'apparaissent donc pas dans une file d'attente et ne sont pas remis à l'application concernée.
L'indisponibilité d'un service distant n'est pas considérée comme une erreur par Service Broker. Ainsi, lorsqu'un service distant ne peut être joint, Service Broker conserve les messages destinés à ce service jusqu'à ce qu'il soit de nouveau disponible ou que la durée de vie du dialogue ait expiré.
Durée de vie du dialogue
Les applications peuvent échanger des messages le temps que dure le dialogue. La durée de vie d'un dialogue s'étend entre le moment où l'instance SQL Server locale crée le dialogue et celui où une application met fin à ce dialogue de façon explicite ou reçoit un message d'erreur associé au dialogue. Chaque participant doit conclure officiellement la conversation lorsque l'application reçoit un message signalant une erreur ou la fin de la conversation. Dans la plupart des services, un participant est chargé de signaler la fin d'une conversation réussie en achevant la conversation sans produire d'erreur. L'objet de la conversation détermine celui des deux participants, l'initiateur ou la cible, qui sera responsable de cette tâche.
Au niveau local, Service Broker crée un point de terminaison de conversation pour le dialogue que l'application a entamé à l'origine. Il crée également un point de terminaison de conversation pour l'application cible, lorsque l'instance reçoit le premier message du dialogue.
Les dialogues peuvent également garantir que la durée de vie d'une conversation ne dépassera pas la limite spécifiée. Ainsi, l'application sollicitant le dialogue peut éventuellement indiquer une durée de vie maximale pour ce dialogue. Service Broker contrôle cette durée de vie tant au niveau local qu'au niveau distant. Lorsqu'un dialogue atteint la durée maximale et demeure actif, chaque participant engagé dans la conversation place un message d'erreur de délai d'expiration dans la file d'attente du service et refuse tout nouveau message pour le dialogue. Les conversations ne dépassent jamais la durée de vie maximale qui est définie au moment où la conversation est engagée. Il est intéressant de remarquer qu'une application peut toujours recevoir des messages pour une conversation terminée, sans qu'un seul nouveau message n'arrive pour cette conversation ; l'application est également dans l'incapacité d'envoyer des messages se rapportant à cette conversation.
Les applications sont tenues de signaler qu'elles mettent fin à un dialogue en concluant celui-ci de façon explicite. Service Broker n'achève jamais un dialogue automatiquement, celui-ci demeure dans la base de données jusqu'à ce que l'application mette explicitement un terme à la conversation. Ainsi, le dialogue peut dépasser la durée qui lui est impartie ou Service Broker signaler une erreur, chaque participant engagé dans la conversation doit publier officiellement l'instruction END CONVERSATION.
Minuteur de conversation
Un minuteur de conversation permet à une application de recevoir un message à un moment précis. Lorsque le minuteur arrive à expiration, SQL Server insère un message pour la conversation dans la file d'attente de cette conversation, au point de terminaison qui a déclenché le minuteur de conversation. L'utilisation d'un minuteur de conversation par une application est infinie : il sert habituellement à répondre aux retards des réponses provenant du service distant. Une autre utilisation courante consiste à créer un service qui envoie des messages à intervalles réguliers au service distant. Un service peut, par exemple, utiliser un minuteur de conversation pour donner des informations sur l'état de SQL Server toutes les deux ou trois minutes. Des applications peuvent également utiliser ce minuteur pour une procédure stockée à un moment donné. Service Broker est donc en mesure de prendre en charge des activités planifiées.
Chaque participant engagé dans une conversation peut définir un minuteur par conversation. Le minuteur n'est pas partagé avec l'autre participant, il ne présente aucune incidence sur la durée de vie de la conversation. Lorsque le minuteur expire, Service Broker intervient localement en ajoutant un message de délai d'expiration à la file d'attente du service local. Le nom de ce type de message est le suivant https://schemas.microsoft.com/SQL/ServiceBroker/DialogTimer