Modèle Messaging Bridge

Cet article décrit le modèle Messaging Bridge qui est une technique que vous pouvez utiliser pour intégrer différents systèmes créés sur diverses infrastructures de messagerie.

Contexte et problème

De nombreuses organisations et charges de travail peuvent disposer par inadvertance de systèmes informatiques qui utilisent plusieurs infrastructures de messagerie telles que Microsoft Message Queuing (MSMQ), RabbitMQ, Azure Service Bus et Amazon SQS. Ce problème peut survenir en raison de fusions, d’acquisitions ou de l’extension des systèmes locaux actuels à des composants hébergés sur le cloud pour une question de rentabilité et une facilité de la maintenance.

Il est possible que les développeurs relèvent ce défi en modifiant les systèmes en cours d’intégration pour qu’ils communiquent en utilisant des services web HTTP. Cette approche présente toutefois des inconvénients, notamment :

• Les systèmes doivent être modifiés en ajoutant un client HTTP d’un côté et un gestionnaire de requêtes HTTP de l’autre. Les systèmes doivent ensuite être retestés et redéployés.
• Des points de terminaison HTTP doivent être hébergés, ce qui augmente le niveau de complexité lorsque vous rendez des services web sécurisés et hautement disponibles.
• Des problèmes fréquents de connectivité réseau qui nécessitent des mécanismes de nouvelle tentative personnalisés.

Solution

Si les systèmes en cours d’intégration comprennent des composants qui communiquent via l’échange de messages, le modèle Messaging Bridge améliore l’intégration et réduit les inconvénients.

Dans ce scénario, chaque système se connecte à une infrastructure de messagerie. Pour intégrer sur différentes infrastructures de messagerie, introduisez un composant de pont qui se connecte à au moins deux infrastructures de messagerie en même temps. Le pont extrait les messages de l’une et les envoie (push) à l’autre sans changer de charge utile.

Les systèmes en cours d’intégration n’ont pas besoin de reconnaître les autres ou le pont. Le système d’expéditeur est configuré pour envoyer des messages spécifiques vers une file d’attente désignée sur son infrastructure de messagerie native. Le pont récupère ces messages et les envoie vers une autre file d’attente dans une infrastructure de messagerie différente où le système récepteur les collecte.

Avantages

• Les systèmes en cours d’intégration via le Messaging Bridge ne doivent pas faire l’objet d’une modification. Dans l’idéal, les points de terminaison ne sont pas informés que les messages sont reliés par un pont.
• L’intégration est plus efficace par rapport à l’alternative HTTP en raison de la garantie de mécanisme de remise de messages au moins une fois.
• Les scénarios de migration peuvent être plus flexibles. Par exemple, vous pouvez migrer des points de terminaison d’une infrastructure de messagerie à une autre dès que la planification le permet plutôt que toutes en une fois.

Inconvénients

• Il est possible que les fonctionnalités avancées d’une ou des deux technologies de messagerie ne soient pas disponibles sur la route reliée par un pont.
• La route reliée par un pont doit tenir compte des limitations des deux technologies. Par exemple, la taille maximale du message doit être de 4 Mo dans MSMQ, mais uniquement de 64 Ko dans des files d’attente Stockage Azure.

Problèmes et considérations

Lorsque vous implémentez le modèle Messaging Bridge, considérez les points suivants :

• Si l’un des systèmes intégrés s’appuie sur des transactions distribuées, par exemple Microsoft Distributed Transaction Coordinator (DTC), vous devez implémenter un mécanisme de déduplication dans le pont pour vérifier l’exactitude.

• Si l’un des systèmes en cours d’intégration n’utilise aucune infrastructure de messagerie et qu’il ne peut pas être modifié, vous pouvez générer le Messaging Bridge entre l’infrastructure utilisée par l’autre système et une file d’attente émulée par SQL Server. Le système hérité peut envoyer des messages en utilisant la fonctionnalité capture des changements de données pour SQL Server afin d’envoyer (push) ses modifications vers une table de file d’attente dédiée. Le pont peut transférer ces messages vers l’infrastructure de messagerie actuelle.

• Vous pouvez utiliser une seule file d’attente dans chaque infrastructure de messagerie désignée comme file d’attente de pontage. Dans cette topologie, configurez le système de messagerie pour utiliser cette file d’attente spécifique comme destination des types de message envoyés vers l’autre système. Vous pouvez également utiliser plusieurs paires de files d’attente dans chaque infrastructure de messagerie pour que l’expéditeur n’ait pas connaissance du pont. Une file d’attente de mise en mémoire fantôme est créée pour chaque file d’attente de destination dans l’infrastructure de messagerie du système de destination. Le pont transfère des messages entre les files d’attente de mise en mémoire fantôme et leurs contreparties.

• Afin de respecter les Contrats de niveau de service (SLA) de disponibilité souhaitée, il est possible que vous deviez effectuer un scale-out de Messaging Bridge en utilisant l’approche des Consommateurs concurrents.

• Des composants normaux de traitement de messages utiliser le modèle Nouvelle tentative pour gérer des défaillances temporaires. La limite du compteur de nouvelles tentatives active des composants pour détecter des messages incohérents et les supprimer de la file d’attente pour débloquer le traitement. Il est possible que le pont nécessite une autre stratégie de nouvelles tentatives pour empêcher l’identification de façon erronée de messages comme étant incohérents si une défaillance d’infrastructure se produit. Vous pouvez utiliser le modèle Disjoncteur pour suspendre un transfert.

Quand utiliser ce modèle

Utilisez le modèle Messaging Bridge si vous devez :

• Intégrer des systèmes existants avec des besoins minimaux en matière de modification.
• Intégrer des applications dédiées qui ne peuvent pas utiliser d’autres technologies de messagerie.
• Étendre des applications locales existantes avec des composants hébergés dans le cloud.
• Connecter des systèmes géo-distribués lorsque la connexion Internet n’est pas stable.
• Migrer un seul système distribué d’une infrastructure de messagerie à une autre de manière incrémentielle sans être obligé de migrer le système entier d’un seul coup.

Il est possible que ce modèle ne convienne pas si :

• Au moins un des systèmes impliqués s’appuie sur une fonctionnalité d’infrastructure de messagerie qui est absente dans l’autre.
• Une intégration est synchrone par nature et le système de lancement nécessite une réponse immédiate.
• Une intégration a des exigences fonctionnelles spécifiques ou non fonctionnelles, telles que des préoccupations liées à la sécurité ou à la confidentialité.
• Le volume de données pour l’intégration est supérieur à la capacité du système de messagerie ou rend la solution de messagerie coûteuse pour le problème.

Conception de la charge de travail

Un architecte doit évaluer comment le modèle de Pont de Messagerie peut être utilisé dans la conception de leur charge de travail pour répondre aux objectifs et principes couverts par les piliers d’Azure Well-Architected Framework. Par exemple :

Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.

Exemple

Il existe une application écrite dans une infrastructure .NET pour la gestion de la planification des employés qui est hébergée localement. L’application est bien structurée, avec des composants qui communiquent via MSMQ. L’application fonctionne et l’équipe de charge de travail n’a pas l’intention de la réécrire. Un nouveau consommateur des données de planification doit être généré pour répondre à un besoin d’entreprise et la stratégie informatique exige la génération d’un nouveau logiciel en tant qu’applications natives Cloud afin d’optimiser les coûts et le délai de remise.

L’architecture basée sur une file d’attente asynchrone a fonctionné dans le passé pour l’équipe de charge de travail et elle va utiliser la même approche architecturale, mais avec la technologie moderne de Service Bus. L’équipe de charge de travail ne souhaite pas introduire une communication synchrone entre le déploiement local et le cloud pour atténuer la latence ou l’indisponibilité de l’un affectant l’autre.

L’équipe décide d’utiliser le modèle Messaging Bridge pour connecter les deux systèmes. Le modèle comprend deux parties. Une partie reçoit des messages de la file d’attente MSMQ existante et les transfère vers le Service Bus. L’autre partie récupère des messages à partir de Service Bus et les transfère vers la file d’attente MSM existante.

Lorsque l’équipe d’implémentation utilise cette approche, elle fait usage de l’infrastructure existante dans l’application actuelle à intégrer aux nouveaux composants. L’application existante n’a pas connaissance des nouveaux composants hébergés dans Azure. Parallèlement, les nouveaux composants communiquent avec l’application héritée de la même façon qu’ils communiquent entre eux en envoyant des messages Service Bus. Le pont transfère des messages entre les deux systèmes.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Rob Bagby | Principal Architecture Content Lead
• Kyle Baley | Ingénieur logiciel
• Udi Dahan | Fondateur et PDG de Particular Software
• Chad Kittel | Ingénieur logiciel principal
• Bryan Lamos | Relations des développeurs
• Szymon Pobiega | Ingénieur

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Description du modèle Messaging Bridge à partir de la communauté des modèles d’intégration d’entreprise.
• Découvrez comment implémenter un Messaging Bridge dans l’infrastructure Spring Java.
• Vous pouvez utiliser un pont QPid pour relier par un pont des technologies de messagerie avec AMQP.
• Le Messaging Bridge NServiceBus est une implémentation .NET de pont entre files d’attente qui prend en charge un éventail d’infrastructures de messagerie, notamment MSMQ, Service Bus et Stockage File d’attente Azure.
• NServiceBus.Router est un projet open source qui implémente le modèle Messaging Bridge. Il permet également le pontage de plus de deux technologies dans une seule instance et dispose de fonctionnalités avancées de routage des messages.

Ressources associées

• Le modèle Consommateurs concurrents veille à ce que l’implémentation de Messaging Bridge puisse gérer la charge.
• Le modèle Nouvelle tentative permet à Messaging Bridge de gérer des défaillances temporaires.
• Le modèle Disjoncteur conserve des ressources lorsque l’un des côtés du pont fait face à un temps d’arrêt.