Routage Service Broker
Cette rubrique explique dans les détails la façon dont Service Broker achemine les messages. Pour obtenir une vue d'ensemble, consultez Itinéraires.
Une utilisation simple du routage Service Broker se révèle satisfaisante pour la plupart des applications. Il suffit d'indiquer, dans chaque base de données contenant un service, un itinéraire pour les services externes avec lesquels le service communique. Cependant, Service Broker constitue également un système de routage perfectionné qui permet de gérer les comportements plus élaborés qui sont requis au niveau des applications. Pour obtenir des exemples sur ce processus de routage, consultez Exemples de routage Service Broker.
Description du processus de routage
SQL Server gère deux niveaux distincts d'informations de routage. Chaque base de données contient une table de routage locale, sys.routes, pour les conversations entamées en interne. Pour les conversations engagées dans l'instance de SQL Server, SQL Server recherche la table de routage dans la base de données qui a créé la conversation. Pour les conversations provenant de l'extérieur de l'instance, SQL Server recherche dans msdb.sys.routes.
Le processus de concordance est le même à la base, que la conversation démarre à l'intérieur ou à l'extérieur de l'instance. Il ignore les itinéraires qui ont expiré. Le processus de routage est composé de trois étapes distinctes :
Recherche des itinéraires correspondants. Service Broker constitue un ensemble d'itinéraires praticables en trouvant le nom du service qui correspond à l'identificateur Service Broker.
Choix d'un itinéraire. Service Broker sélectionne un itinéraire parmi la série d'itinéraires praticables.
Recherche du service de destination. Lorsque l'itinéraire choisi indique 'LOCAL' comme adresse réseau, Service Broker trouve le service dans l'instance. Si ce service n'existe pas, Service Broker peut retourner à l'étape précédente pour choisir un autre itinéraire.
Lorsqu'un message est envoyé du service initiateur vers le service cible et qu'un message d'accusé de réception provenant de la cible est reçu par l'initiateur, cet initiateur utilise l'identificateur Service Broker du message d'accusé de réception pour acheminer les messages suivants vers la même cible. Service Broker gère les messages d'accusés de réception, sachant que le processus est transparent pour une application qui utilise Service Broker. Pour plus d'informations sur les messages d'accusés de réception, consultez Protocoles de communication Service Broker.
Messages de réponse à partir d'un service cible
Lorsqu'un message extérieur à l'instance provient d'un service cible, SQL Server vérifie si l'instance actuelle contient l'identificateur Service Broker dans le message. Si tel est le cas, le message est remis dans l'instance actuelle, comme décrit dans la section « Recherche du service de destination ». Sinon, SQL Server suit le processus de concordance standard.
Recherche des itinéraires correspondants
La procédure suivante décrit la façon dont SQL Server fait concorder les itinéraires. À chaque étape, si un ou plusieurs itinéraires correspondent, le processus de concordance s'achève et Service Broker choisit un des itinéraires possibles suivants :
Si la conversation spécifie un identificateur Service Broker, trouvez un itinéraire présentant une correspondance parfaite à la fois pour le nom du service et pour l'identificateur Service Broker.
Trouvez une correspondance parfaite pour le nom du service parmi les itinéraires qui ne spécifient aucun identificateur Service Broker.
Si la conversation ne précise aucun identificateur Service Broker, trouvez une correspondance parfaite pour le nom du service parmi les itinéraires qui spécifient un identificateur Service Broker. Si la table de routage contient des itinéraires qui correspondent au nom du service et qui ont des identificateurs Service Broker différents, choisissez arbitrairement un identificateur Service Broker. Faites ensuite correspondre uniquement les itinéraires utilisant cet identificateur Service Broker.
Si un itinéraire menant à un service de routage dynamique est présent et qu'aucune demande d'itinéraire vers ce service n'est en attente, marquez la conversation comme étant retardée et demandez des informations sur le routage auprès de ce service.
Trouvez un itinéraire qui ne spécifie ni le nom du service ni l'identificateur Service Broker.
Si la conversation spécifie un identificateur Service Broker et si l'instance contient une ou plusieurs bases de données comportant des services dont les noms correspondent au nom spécifié dans la conversation, acheminez la conversation comme si la table de routage contenait un itinéraire avec le nom du service et l'adresse réseau 'LOCAL'.
Marquez la conversation comme étant retardée.
Lorsqu'un retard est signalé pour une conversation, Service Broker exécute de nouveau le processus de concordance après un délai d'attente. Remarquez que l'échec de la recherche d'un itinéraire correspondant n'est pas considéré comme une erreur.
Choix d'un itinéraire
Si le processus de concordance trouve plusieurs itinéraires appropriés, Service Broker en choisit un parmi ceux qui sont répertoriés. Ainsi, les itinéraires possédant le même identificateur Service Broker, le même nom de service et la même adresse réseau sont considérés comme identiques. Service Broker utilise la procédure suivante pour choisir le bon itinéraire. À la fin de chaque étape, le processus se poursuit à l'étape suivante si aucun itinéraire correspondant aux caractéristiques de l'adresse n'est trouvé.
Choisissez un itinéraire parmi ceux qui spécifient une adresse miroir.
Choisissez un itinéraire parmi ceux qui spécifient 'LOCAL' comme adresse réseau. Si cette instance de SQL Server ne contient aucun service correspondant au nom spécifié dans la conversation, passez à l'étape 3.
Choisissez un itinéraire parmi ceux qui spécifient une adresse réseau.
Choisissez un itinéraire parmi ceux qui spécifient 'TRANSPORT' comme adresse réseau.
Si la fonction de transfert de Service Broker n'est pas activée, le message est supprimé lorsque la conversation n'est pas originaire de l'instance active et que l'adresse de l'itinéraire choisi n'est pas 'LOCAL'.
Recherche du service de destination
Comme décrit auparavant, Service Broker effectue la remise des messages à un service situé dans l'instance active lorsque l'itinéraire correspondant précise 'LOCAL' comme adresse réseau. Pour les messages dont l'origine se trouve à l'extérieur de l'instance, l'itinéraire doit être dans msdb.sys.routes. Pour les messages dont l'origine se trouve à l'intérieur de l'instance, l'itinéraire correspondant doit se trouver dans la table sys.routes de la base de données qui engage la conversation.
Lorsqu'il a établi la présence du service recherché pour le message dans l'instance actuelle, Service Broker cherche à localiser ce service. Si un identificateur Service Broker de la conversation existe dans la conversation ou dans l'itinéraire, Service Broker remet les messages à la base de données repérée grâce à cet identificateur.
Sinon, Service Broker localise le service en commençant par effectuer une recherche sur le nom du service dans la base de données qui contient la conversation. Il recherche ensuite le nom du service dans les autres bases de données dans l'instance. Service Broker remet le message au premier service localisé. Remarquez, toutefois, que l'ordre suivant lequel Service Broker effectue ses recherches dans les autres bases de données d'une instance n'est ni spécifié, ni garanti comme systématique d'une conversation à l'autre. Autrement dit, s'il existe plusieurs exemplaires du service cible dans l'instance, Service Broker choisit de façon aléatoire le service à cibler.
Autres points à considérer
Pour renforcer sa fiabilité, le routage Service Broker comprend des dispositifs de protection contre les boucles de routage. Il sait reconnaître la mise en miroir des bases de données et est capable de rediriger les conversations vers le serveur partenaire actif d'une base de données en miroir.
Boucles de routage
La fonctionnalité de transfert des messages de Service Broker comptabilise le nombre de fois qu'un message est transféré afin d'éviter les boucles de routage interminables. Pour plus d'informations, consultez Transfert de messages Service Broker.
Si l'itinéraire correspondant contient une adresse réseau qui se résout sur l'instance actuelle, SQL Server traite la conversation comme si elle avait été engagée à l'extérieur de l'instance. Service Broker achemine les messages de la conversation via les itinéraires présents dans msdb.sys.routes. Le routage de ces messages est identique au routage des messages qui proviennent de l'extérieur de l'instance. À noter, le transfert de messages doit être activé pour que Service Broker fasse suivre le message sur une adresse réseau différente de 'LOCAL'.
Adresses miroir
Les itinéraires indiquant des adresses miroir jouissent de la plus haute priorité au moment où un itinéraire est choisi dans l'ensemble des itinéraires répertoriés au départ. Toutefois, Service Broker n'accorde aucune attention particulière aux adresses miroir lorsqu'il recherche des itinéraires correspondants pour une conversation.
Lorsque Service Broker choisit un itinéraire spécifiant une adresse miroir alors qu'aucune remise de messages n'a encore été effectuée via cet itinéraire, il envoie une demande aux deux adresses afin de déterminer quelle instance constitue, à ce moment-là, l'instance principale. Une fois l'instance identifiée, Service Broker achemine tous les messages via l'itinéraire menant à l'instance principale sans contacter l'instance miroir. Si l'instance principale est inaccessible, ou si elle signale ne plus être l'instance principale, Service Broker achemine les messages vers l'autre adresse, à condition que l'instance de SQL Server de cette deuxième adresse précise être la nouvelle instance principale.
Si Service Broker n'arrive pas à joindre l'instance principale et que l'instance partenaire ne revendique aucune priorité, aucun message n'est envoyé à l'instance partenaire. Service Broker effectue de nouvelles tentatives sur les deux adresses jusqu'à ce que l'instance principale soit accessible ou que l'instance partenaire se déclare l'instance principale. En adoptant cette méthode, la remise des messages effectuée par Service Broker est fiable lorsque l'instance principale et l'instance partenaire peuvent communiquer, mais que l'instance qui envoie le message ne peut pas joindre l'instance principale.