Un courtier de messages est un logiciel qui permet aux applications, aux systèmes et aux services de communiquer entre eux et d'échanger des informations. Pour ce faire, le courtier de messages traduit les messages entre les protocoles de messagerie formels. Ainsi, des services interdépendants peuvent communiquer directement entre eux, même s'ils ont été écrits dans des langages différents ou mis en œuvre sur des plateformes différentes.
Les courtiers de messages sont des modules logiciels faisant partie de solutions basées sur un middleware de messagerie ou un middleware orienté message (MOM). Ce type de logiciel intermédiaire fournit aux développeurs un moyen normalisé de gérer le flux de données entre les composants d'une application, afin qu'ils puissent se concentrer sur sa logique centrale. Il peut servir de couche de communication distribuée qui permet aux applications qui couvrent plusieurs plateformes de communiquer entre elles en interne.
Les courtiers de messages peuvent valider, stocker, acheminer et distribuer les messages vers les destinations appropriées. Ils servent d'intermédiaires entre d'autres applications, permettant aux expéditeurs d'envoyer des messages sans savoir où se trouvent les destinataires, s'ils sont actifs ou non, ni connaître leur nombre, Ainsi, le découplage des processus et des services est plus simple dans les systèmes.
Afin de stocker de manière fiable les messages et de garantir leur distribution, les courtiers de messages utilisent une sous-structure ou un composant, appelé file d'attente de messages, qui stocke et organise les messages jusqu'à ce que les applications consommatrices puissent les traiter. Dans une file d'attente de messages, les messages sont stockés selon l'ordre exact dans lequel ils sont transmis et y restent jusqu'à la confirmation de leur réception.
Une messagerie asynchrone (15:11) fait référence au type de communication entre les applications que permettent les courtiers de messages. Elle évite la perte de données importantes et permet aux systèmes de continuer à fonctionner, même en cas de problèmes de connectivité intermittente ou de temps d'attente, fréquents sur les réseaux publics. Une messagerie asynchrone garantit que les messages sont distribués une seule (et unique fois) dans l'ordre correct par rapport aux autres messages.
Les courtiers de messages peuvent inclure des gestionnaires de files d'attente pour gérer les interactions entre plusieurs files d'attente de messages, ainsi que des services fournissant des fonctionnalités de routage de données, de conversion de messages, de persistance et de gestion de l'état des clients.
Les courtiers de messages offrent deux modèles de distribution de messages de base ou types de messagerie :
Messagerie point-à-point : Il s'agit du modèle de distribution utilisé dans les files d'attente de messages avec une relation un à un entre l'expéditeur et le destinataire du message. Chaque message de la file d'attente est envoyé à un seul destinataire et n'est utilisé qu'une seule fois. La messagerie point-à-point est utilisée lorsqu'un message ne doit être traité qu'une seule fois. Le traitement des salaires et des transactions financières sont des exemples d'utilisation pour ce style de messagerie. Dans ces systèmes, les expéditeurs et les destinataires doivent avoir la garantie que chaque paiement est envoyé une fois et une seule fois.
Messagerie de publication/d'abonnement : dans ce modèle de distribution des messages, souvent appelé « publication/abonnement », le créateur de chaque message le publie dans une rubrique, et plusieurs consommateurs de messages s'abonnent aux rubriques dont ils veulent recevoir les messages. Tous les messages publiés dans une rubrique sont distribués à toutes les applications qui y sont abonnées. Il s'agit d'une méthode de distribution de type diffusion, dans laquelle il existe une relation de type « un à plusieurs » entre le diffuseur du message et ses consommateurs. Par exemple lorsqu'une compagnie aérienne distribue des modifications de ses horaires d'atterrissage ou des durées des vols, de nombreux acteurs peuvent bénéficier de ces informations : le personnel au sol responsable des opérations d'entretien et de ravitaillement des avions, les bagagistes, le personnel navigant commercial et les pilotes qui préparent le vol suivant, ainsi que l'équipe chargée des panneaux d'affichage destinés au public. Un style de messagerie de publication/d'abonnement est adapté dans ce cas.
Les applications cloud natives ont pour vocation de tirer parti des avantages inhérents aux solutions de cloud computing, notamment de la flexibilité, de l'évolutivité et de la rapidité du déploiement. Ces applications sont conçues à partir de petits composants discrets et réutilisables appelés microservices. Chaque microservice est déployé et peut s'exécuter indépendamment des autres. Cela signifie que chacun d'entre eux peut être mis à jour, mis à l'échelle ou redémarré sans affecter les autres services du système. Généralement, placés dans des conteneurs, les microservices fonctionnent ensemble pour former une application complète, bien que chacun dispose de sa propre pile, y compris d'une base de données et d'un modèle de données qui peuvent être différents des autres.
Les microservices doivent avoir un moyen de communiquer entre eux, afin de fonctionner de concert. Les courtiers de messages sont l'un des mécanismes qu'ils utilisent pour créer cette dorsale de communication partagée.
Les courtiers de messages sont généralement utilisés pour gérer les communications entre les systèmes sur site et les composants cloud dans les environnements de cloud hybride. L'utilisation d'un courtier de messages permet de contrôler efficacement les communications interservices, en garantissant que les données sont envoyées de manière sûre, fiable et efficace entre les composants d'une application. Les courtiers de messages peuvent jouer un rôle similaire dans l'intégration d'environnements multiclouds, en permettant la communication entre les charges de travail et les environnements d'exécution résidant sur des plateformes différentes. Ils sont également bien adaptés aux environnements informatiques sans serveur dans lesquels des services individuels hébergés dans le cloud sont exécutés à la demande.
Des API REST sont couramment utilisées dans les communications entre les microservices. Le terme Representational State Transfer (REST) définit un ensemble de principes et de contraintes que les développeurs peuvent suivre lors de la création de services Web. Les services qui y adhèrent peuvent communiquer par le biais d'un ensemble d'opérateurs et de demandes sans état partagés et uniformes. L'interface de programme d'application (API) désigne le code sous-jacent qui, s'il est conforme aux règles REST, permet aux services de communiquer entre eux.
Les API REST utilisent le protocole HTTP pour communiquer. HTTP étant le protocole de transport standard de l'Internet public, les API REST sont largement connues, fréquemment utilisées et largement interopérables. Toutefois, HTTP est un protocole de demande/réponse. Il est donc préférable de l'utiliser dans des situations qui nécessitent une demande/réponse synchrone. Ainsi, les services qui effectuent des demandes par le biais d'API REST doivent être conçus pour attendre une réponse immédiate. Si le client qui reçoit la réponse est hors service, le service d'envoi est bloqué pendant qu'il attend la réponse. Une logique de basculement et de traitement des erreurs doit être intégrée dans les deux services.
Les courtiers de messages permettent des d'établir des communications asynchrones entre les services, de sorte que le service expéditeur n'a pas besoin d'attendre la réponse du service destinataire, ce qui améliore la tolérance aux pannes et la résilience des systèmes dans lesquels ils sont employés. En outre, l'utilisation de courtiers de messages facilite la mise à l'échelle des systèmes, car un modèle de messagerie de publication/d'abonnement peut facilement prendre en charge un nombre variable de services. Les courtiers de messages surveillent également les statuts des consommateurs.
Si les courtiers de messages peuvent prendre en charge au moins deux modèles de messagerie, y compris des files d'attente de messages et le modèle de publication/d'abonnement, les plateformes de diffusion d'événements en continu ne proposent que des modèles de distribution de type publication/abonnement. Conçues pour être utilisées avec de gros volumes de messages, les plateformes de diffusion d'événements en continu sont facilement évolutives. Elles sont capables d'organiser les flux d'enregistrements en catégories, appelées rubriques, et de les stocker pendant une durée prédéterminée. Toutefois, contrairement aux courtiers de messages, les plateformes de diffusion d'événements en continu ne peuvent pas garantir la distribution ni le suivi des messages ni savoir quels sont les consommateurs qui ont reçu les messages.
Les plateformes de diffusion d'événements en continu offrent une plus grande évolutivité que les courtiers de messages, mais moins de fonctions qui garantissent la tolérance aux pannes (comme le renvoi des messages), ainsi que des fonctionnalités plus limitées de routage et de mise en file d'attente des messages.
Découvrez-en plus sur l'architecture événementielle.
Un bus de service d'entreprise (ESB) est un modèle d'architecture parfois utilisé dans les architectures orientées service mises en œuvre dans les entreprises. Dans un bus ESB, une plateforme logicielle centralisée combine les protocoles de communication et les formats de données dans un « langage commun » que tous les services et applications de l'architecture peuvent partager. Il peut, par exemple, convertir les demandes qu'il reçoit d'un protocole (tel que XML) dans un autre (tel que JSON). Les bus ESB transforment les contenus de leurs messages à l'aide d'un processus automatisé. La plateforme logicielle centralisée gère également d'autres logiques d'orchestration, telles que la connectivité, le routage et le traitement des demandes.
Les infrastructures ESB sont cependant complexes, potentiellement difficiles à intégrer, et leur maintenance peut s'avérer coûteuse. Il est difficile de les dépanner lorsque des problèmes surviennent dans les environnements de production, leur mise à l'échelle n'est pas simple et leur mise à jour est fastidieuse.
Les courtiers de messages constituent une alternative « allégée » aux bus ESB et proposent une fonctionnalité similaire (un mécanisme de communication interservices), de manière simplifiée et à moindre coût. Ils conviennent bien aux architectures de microservices qui ont prospéré à mesure que les bus ESB perdaient leur attrait.
La mise en œuvre de courtiers de messages permet de répondre à une multitude de besoins métier dans tous les secteurs et dans divers environnements informatiques d'entreprise. Ils sont utiles quand et là où il est nécessaire de disposer d'une communication fiable entre des applications et de garantir la distribution des messages.
Les courtiers de messages sont généralement utilisés dans les cas suivants :
IBM MQ offre des fonctionnalités de messagerie qui répondent aux besoins des entreprises et déplacent les informations entre les applications aisément et de manière fiable.
Connectez les applications, les services et les données avec IBM Cloud Pak for Integration, la plateforme d'intégration la plus complète du marché.
Une file d'attente de messages est un composant de solutions middleware de messagerie qui permet à des applications et à des services indépendants d'échanger des informations.
Un middleware accélère le développement des applications distribuées en simplifiant la connectivité entre les applications, les composants d'application et les sources de données back-end.
iPaaS est une solution cloud qui normalise et simplifie l'intégration des applications dans les environnements sur site et clouds.