Routage des messages : mettre en œuvre les Enterprise Integration Patterns grâce à des pipelines flexibles

Xbus propose un système de déclaration de pipelines pour configurer le parcours des messages. Comment cela fonctionne-t-il ?

Il existe plusieurs manières de configurer le parcours des messages. Certaines impliquent d’attribuer à chaque application émettrice un profil d’émetteur associé à un type d’événement, puis de configurer chaque application réceptrice (consommatrice) et chaque worker pour définir quel(s) type(s) d’événement ils peuvent recevoir. Cela implique de réaliser une configuration par acteur (worker ou consommateur).

Le système adopté pour Xbus, basé sur des pipelines déclaratifs qui modélisent les flux, permet davantage de souplesse. Un même pipeline décrit l’ensemble des communications en un seul fichier (au format YAML). Un pipeline est composé de plusieurs nœuds (nodes), qui constituent les étapes du parcours des messages (émetteurs, workers modifiant les données, consommateurs les recevant). Chaque nœud peut comporter plusieurs portes d’entrée (input) et de sortie (output). Un input correspond à un flux entrant destiné à un acteur tandis qu’un output constitue un flux sortant généré par l’acteur à destination du pipeline.

À travers un même pipeline, il est possible de créer un flux qui se divise en plusieurs branches, c’est-à-dire de rediriger un même type de message vers différents récepteurs en fonction de critères donnés. Ce mécanisme permet d’assurer le routage des messages. Il facilite la mise en œuvre de certains Enterprise Integration Patterns (EIP), comme évoqué dans le livre de Gregor Hohpe et de Bobby Woolf, Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions et sur le site web dédié.
Le mécanisme de routage a notamment permis la réalisation des EIP suivants :

Message Router : possibilité d’envoyer un message vers un récepteur ou un autre selon certaines conditions,

Content-Based Router : Message Router qui achemine les messages vers un récepteur ou un autre en fonction d’éléments de contenu (inspectés par un worker), par exemple d’un code pays. Cet aiguillage est rendu possible grâce au système d’output qu’un worker peut transmettre au pipeline.

Process Manager : composant, présent au sein de Xbus, qui gère le parcours des messages, en particulier le passage d’un récepteur à l’autre en fonction de certaines conditions.

Le système de déclaration de pipelines apporte également de la flexibilité à la configuration. Un même pipeline peut être appliqué à plusieurs solutions différentes même si elles ne sont pas encore enregistrées, et ce grâce à l’attribution de rôles (identifiants permettant de regrouper plusieurs acteurs).

La prise en charge du routage par Xbus permet de soulager l’application émettrice et d’éviter le couplage entre émetteurs et récepteurs, ce qui s’inscrit dans une logique d’urbanisation. La structure des pipelines et des nœuds facilite le développement de routeurs spécifiques. CloudCrane réalise cette prestation pour les sociétés utilisatrices qui le souhaitent.

Par exemple, pour l’un de nos clients, un routeur spécifique (le pattern Content-Based Router) a été développé au niveau de Xbus afin de diriger les flux issus d’un logiciel-source vers l’un des logiciels-cibles concernés. Les logiciels-cibles n’étant pas gérés par le même organisme que le logiciel-source, il n’aurait pas été pertinent que le routage soit effectué au niveau de celui-ci. Un tableau de correspondance mettant en regard les identifiants clients (transmis par le logiciel-source) et les logiciels-cibles est donc associé au routeur. Ce mécanisme garantit l’indépendance entre émetteurs et récepteurs, et donc le maintien d’un système d’information urbanisé.

Grâce à l’exposition d’une API par Xbus, les utilisateurs qui le souhaitent peuvent développer leur propre routeur. Xbus est disponible en Open Source sur Bitbucket.

Documentation sur le routage dans Xbus : création et gestion des pipelines.


Crédit image d’entête : Freepik sur www.flaticon.com licence CC 3.0 BY