Avantages de Service Broker
Les fonctionnalités de Service Broker présentent un certain nombre d'atouts majeurs pour les applications de base de données. Ces fonctionnalités et avantages incluent :
l'intégration à la base de données, qui améliore les performances de l'application et simplifie l'administration ;
le classement et la coordination des messages, qui permettent de simplifier le développement de l'application ;
le faible couplage des applications, qui fournit une souplesse au niveau de la charge de travail ;
le verrouillage des messages connexes, qui permet à plusieurs instances d'une application de traiter des messages depuis la même file d'attente sans qu'une véritable synchronisation soit nécessaire ;
l'activation automatique, qui permet aux applications de s'adapter au volume des messages.
Intégration à la base de données
La conception intégrée de Service Broker fournit des avantages tant au niveau des performances que de l'administration d'une application.
L'intégration à SQL Server permet l'utilisation d'une messagerie transactionnelle sans la surcharge ni la complexité supplémentaire d'un coordinateur externe pour les transactions distribuées. Une application reçoit un ou plusieurs messages, procède au traitement du ou des messages reçus et envoie un message de réponse dans une transaction de base de données unique. Si la transaction échoue, tout le travail est restauré et les messages reçus sont renvoyés vers la file d'attente pour qu'une nouvelle tentative de traitement soit effectuée. Aucune action n'est entreprise tant que l'application n'a pas validé la transaction. L'application demeure cohérente.
L'administration est plus facile lorsque les données, les messages et la logique d'application se trouvent réunis dans la même base de données : l'administration de l'application (récupération d'urgence, sécurité, sauvegarde, etc.) fait alors partie de l'administration courante de la base de données et l'administrateur ne se retrouve pas obligé de gérer trois ou quatre composants distincts.
Dans les systèmes de messagerie classiques, la banque de messages et la base de données peuvent devenir incohérentes. Par conséquent, lorsqu'un composant est restauré à partir d'une sauvegarde, tout autre composant doit être également restauré à partir d'une sauvegarde effectuée au même moment ou les informations contenues dans la banque de messages ne correspondront plus aux informations de la base de données. Puisque Service Broker conserve les messages et les données dans la même base de données, les problèmes d'incohérence n'existent pas.
Un environnement de développement commun représente également un avantage propre à l'intégration dans la base de données. La partie messagerie et la partie données d'une application peuvent utiliser les mêmes outils et langages SQL Server dans une application Service Broker, ce qui permet de tirer parti de la connaissance du développeur en matière de techniques de programmation des bases de données pour la programmation basée sur les messages. Les procédures stockées qui implémentent un service de Service Broker peuvent être écrites indifféremment en Transact-SQL ou dans un langage CLR (Common Language Runtime). Les programmes situés en dehors de la base de données utilisent Transact-SQL et des interfaces de programmation de base de données habituelles, telles qu'ADO.NET.
Par ailleurs, l'intégration à la base de données permet de gérer les ressources automatiquement. Service Broker s'exécute dans le contexte de l'instance SQL Server et peut donc surveiller tous les messages prêts à être transmis depuis toutes les bases de données de l'instance. Ainsi, chaque base de données est en mesure de gérer ses propres files d'attente tout en aidant Service Broker à organiser l'exploitation des ressources dans l'instance SQL Server toute entière.
Classement et coordination des messages
Dans les systèmes de messagerie traditionnels, l'application est responsable du classement et de la coordination des messages susceptibles d'arriver dans le désordre. Prenons un exemple : l'application A envoie les messages 1, 2 et 3. L'application B reçoit et accuse réception des messages 1 et 3 tandis qu'une erreur se produit sur le message 2. L'application A renvoie le message 2 qui est reçu après les messages 1 et 3. Le développeur disposait auparavant de deux solutions pour pallier cet inconvénient : écrire l'application pour que l'ordre des messages soit ignoré ou mettre temporairement en cache le message 3 jusqu'à ce que le message 2 arrive et que l'application puisse enfin procéder au traitement des messages dans l'ordre correct. Aucune de ces solutions n'était simple, ni facile à mettre en œuvre.
La remise des messages en double représente un autre problème des systèmes traditionnels. Dans l'exemple précédent, si l'application B reçoit le message 2, mais que son accusé de réception se perd avant d'arriver jusqu'à l'application A, l'application A renvoie le message 2 que l'application B reçoit une deuxième fois. Jusqu'à maintenant, le code de l'application devait être en mesure soit d'identifier et d'ignorer le doublon, soit de procéder une nouvelle fois au traitement du message-doublon sans entraîner de conséquences négatives. Là encore, la mise en œuvre de ces deux solutions s'avérait complexe.
La coordination des messages constitue depuis toujours un problème délicat à maîtriser. En effet, une application peut soumettre des centaines, voire des milliers de demandes à un service. Le service traite les demandes en parallèle et renvoie une réponse à la fin de chaque traitement. Chaque demande ayant une durée de traitement différente, l'application reçoit les réponses dans un ordre différent de celui qui a été suivi lors de l'envoi des messages. Cependant, pour procéder correctement au traitement des réponses, l'application doit associer chaque réponse au message sortant qui lui correspond. Dans les systèmes de messagerie traditionnels, chaque application gérait cette association, ce qui augmentait le coût et la complexité du développement de l'application.
Aujourd'hui, Service Broker apporte une solution à ces problèmes en gérant automatiquement l'ordre des messages, la remise unique et l'identification des conversations. Dès qu'une conversation est instaurée entre deux points de terminaison Service Broker, l'application concernée reçoit chaque message une seule fois, dans l'ordre d'envoi qui a été suivi. Votre application traite les messages une seule et unique fois, dans l'ordre et sans code supplémentaire. Enfin, Service Broker incorpore automatiquement un identificateur à chaque message. L'application est donc toujours en mesure de savoir à quelle conversation appartient un message particulier.
Couplage faible et souplesse de la charge de travail
Service Broker propose un couplage léger entre l'application prenant l'initiative de la conversation et l'application cible. Une application peut donc envoyer un message dans une file d'attente, poursuivre son traitement d'application en laissant le soin à Service Broker de veiller à la bonne remise du message. Cette liberté de manœuvre fournit une souplesse au niveau de l'organisation. L'initiateur peut envoyer plusieurs messages tandis que plusieurs services cibles s'occupent de leur traitement en parallèle. Chacun de ces services traite les messages à son propre rythme, en fonction de la charge de travail active.
Grâce à la mise en file d'attente, les systèmes peuvent répartir plus équitablement la charge de traitement et ainsi diminuer la capacité maximale requise par un serveur. La capacité de traitement totale et les performances générales peuvent se trouver améliorées dans les applications de base de données. Il est par exemple avéré que de nombreuses applications de base de données enregistrent une brusque augmentation du nombre de transactions à certains moments de la journée, ce qui a pour conséquence d'accroître la consommation des ressources et d'allonger les temps de réponse. Avec Service Broker, ces applications ne gèrent plus obligatoirement l'intégralité du traitement d'une transaction d'entreprise lorsque celui-ci leur est soumis. Elles utilisent plutôt Service Broker pour envoyer des informations sur la transaction aux applications qui effectuent le traitement en arrière-plan. Ces applications traitent les transactions comme il se doit, dans le temps imparti, pendant que l'application d'entrée principale continue de recevoir de nouvelles transactions d'entreprise.
Si la destination n'est pas immédiatement disponible, le message demeure dans la file d'attente de transmission de la base de données d'envoi. Service Broker effectue de nouvelles tentatives jusqu'à ce que le message soit correctement envoyé, ou que la durée de vie de la conversation expire, ce qui permet à une conversation fiable de se poursuivre entre deux services, même si l'un de ces services est temporairement indisponible à un moment donné de la conversation. Les messages placés dans la file d'attente de transmission font partie de la base de données : Service Broker remet donc le message, même si l'instance bascule ou redémarre.
Verrouillage des messages connexes
L'une des opérations les plus difficiles à réaliser dans une application de messagerie classique est de réussir la lecture en parallèle de plusieurs programmes depuis la même file d'attente. Dans ces systèmes, les messages peuvent être traités dans le désordre lorsque plusieurs programmes, ou différents threads, lisent sur la même file d'attente. Service Broker évite cet inconvénient grâce au verrouillage des groupes de conversations.
Prenez une application de traitement des commandes classique. Le message A, contenant les instructions relatives à la création de l'en-tête de la commande et le message B, contenant les instructions relatives à la création des articles de la commande, sont tous les deux intégrés à la file d'attente. Si ces deux messages sont retirés de la file d'attente par des instances de l'application distinctes pour être traités en même temps, la transaction des articles de la commande peut être validée la première pour ensuite connaître un échec, puisque la commande n'existe pas encore. L'échec, à son tour, provoque la restauration de la transaction, le replacement du message dans la file d'attente pour une nouvelle tentative de traitement, ce qui représente un gaspillage des ressources. En règle générale, les programmeurs résolvent ce problème en combinant les informations des messages A et B dans un seul et même message. Cette solution, simple et facile pour deux messages, devient difficile à mettre en œuvre sur des systèmes impliquant la coordination de dizaines ou de centaines de messages.
Service Broker résout ce problème en associant des conversations connexes au sein d'un groupe de conversations. L'infrastructure verrouille automatiquement tous les messages d'un même groupe de conversations pour qu'ils puissent être reçus et traités exclusivement par une seule instance de l'application. Pendant ce temps, les autres instances peuvent continuer à retirer et à traiter des messages dans d'autres groupes de conversations. Cette solution permet à plusieurs instances de l'application de travailler parallèlement, en toute efficacité et de façon fiable, sans avoir recours à un code de verrouillage compliqué au niveau de l'application.
Activation automatique
L'une des fonctionnalités les plus utiles de Service Broker se nomme l'activation. L'activation permet à une application d'évoluer dynamiquement afin de faire face au volume de messages qui se présente dans la file d'attente. Service Broker fournit les fonctions permettant aux programmes qui s'exécutent à l'intérieur comme à l'extérieur de la base de données de bénéficier des avantages de cette fonctionnalité. Service Broker n'exige cependant pas l'utilisation de la fonction d'activation par une application.
Service Broker analyse l'activité d'une file d'attente pour déterminer si une application reçoit des messages pour toutes les conversations disposant de messages disponibles. La fonction d'activation de Service Broker lance un nouveau lecteur de file d'attente lorsque du travail se présente pour ce lecteur. Pour savoir à quel moment ce travail survient, Service Broker contrôle l'activité sur la file d'attente. Ainsi, lorsque le nombre des lecteurs de file d'attente correspond au trafic entrant, la file d'attente se retrouve régulièrement vide ou elle contient des messages appartenant à une conversation traitée par un autre lecteur Si une file d'attente tarde à afficher cet état, Service Broker active une autre instance de l'application.
Les applications utilisent des méthodes d'activation différentes selon que les programmes s'exécutent à l'intérieur ou à l'extérieur de la base de données. Pour les programmes à l'intérieur de la base de données, Service Broker démarre une autre copie de la procédure stockée spécifiée par la file d'attente. Pour les programmes exécutés à l'extérieur de la base de données, Service Broker génère un événement d'activation. Dans ce dernier cas, le programme surveille l'événement pour déterminer le moment où un autre lecteur de file d'attente s'avérera nécessaire.
Service Broker n'arrête pas un programme démarré au moyen de la fonction d'activation. Les applications activées sont plutôt écrites pour s'arrêter automatiquement au bout d'un certain temps si aucun message à réceptionner ne se présente. Une application conçue de cette façon permet au nombre d'instances de l'application de fluctuer dynamiquement en fonction des variations du trafic vers le service. Par ailleurs, si le système s'arrête ou est redémarré, les applications sont automatiquement lancées pour lire, au redémarrage du système, les messages dans la file d'attente.
Les systèmes de messagerie ordinaires ne bénéficient pas d'une telle possibilité, ils finissent souvent par utiliser trop ou trop peu de ressources sur une file d'attente particulière à un moment donné.
Voir aussi