Qu'est-ce que le middleware orienté message ? Comment ça fonctionne ?

Les entreprises, les institutions et les technologies changent constamment, donc les systèmes logiciels qui les servent doivent s'y adapter.

Les systèmes modernes fonctionnent dans des environnements complexes avec plusieurs langages de programmation, plateformes matérielles et systèmes d'exploitation. Avec une évolution continue, les entreprises ont besoin de déploiements dynamiques et agiles avec une fiabilité 24/7, des performances élevées et de la sécurité.

La manière la plus simple d'intégrer des composants logiciels disparates n'est pas de les rendre tous identiques, mais de fournir une couche qui leur permet de communiquer malgré leurs différences. Cette couche, connue sous le nom de middleware, permet l'interaction de composants développés indépendamment qui fonctionnent sur différentes plateformes en réseau.

Un type de middleware qui est bénéfique pour le passage de messages est le middleware orienté messages (MOM). Le MOM fournit un mécanisme indépendant de la plateforme pour que les applications échangent des messages en utilisant un logiciel de file d'attente de messages de manière asynchrone. Cela signifie que les applications peuvent communiquer qu'elles fonctionnent sur les mêmes systèmes ou sur des systèmes différents.

Le traitement piloté par les messages est nécessaire pour une configuration client/serveur utilisant une application de courtier de messages unique. Un client envoie un message au courtier de messages, qui gère plusieurs messages de divers clients et les transmet à l'application serveur concernée. Le middleware établit une couche de connectivité qui protège les développeurs des complexités de multiples systèmes d'exploitation et technologies de réseau.

Le MOM permet la communication asynchrone en passant des messages entre les applications au lieu d'appeler directement. Cela présente plusieurs avantages, notamment le découplage des applications pour qu'elles ne dépendent pas les unes des autres, l'augmentation de la fiabilité et de l'évolutivité, et la réduction de la complexité.

Importance du middleware orienté messages

Le MOM est particulièrement utile lorsque des changements massifs se produisent dans une entreprise, comme l'introduction de différents systèmes et composants. Reconstruire l'infrastructure informatique et s'assurer que tous les anciens et nouveaux services fonctionnent de manière transparente est chronophage et demande beaucoup de ressources.

Le MOM répond à ces défis et améliore la communication entre plusieurs systèmes et applications sans réorganiser l'infrastructure informatique de l'organisation.

Les entreprises qui lancent un nouveau service, s'abonnent à un nouveau service ou traversent une acquisition ou une fusion peuvent se tourner vers des solutions MOM pour créer des systèmes cohérents sans affecter d'autres composants de leurs réseaux.

En bref, le middleware orienté messages permet une messagerie asynchrone rapide et fiable et la livraison de messages, y compris les alertes de réception et les contrôles de transaction. Le MOM est une solution commerciale appropriée si les systèmes distribués d'une organisation sont dispersés, ont une connectivité réseau inadéquate ou ont des exigences strictes en matière de flexibilité, d'évolutivité et de fiabilité.

Les systèmes MOM sont un excellent moyen d'accommoder des déploiements dispersés car ils sont flexibles et durables.

Comment fonctionne le middleware orienté messages ?

Le middleware de messagerie améliore la communication entre les composants pour les systèmes informatiques complexes et facilite le développement dans un environnement distribué.

La file d'attente de messages est un composant crucial dans les plateformes de middleware orienté messages. La mise en file d'attente des messages aide les systèmes basés sur le MOM à conserver les messages dans l'architecture. Avec l'aide des files d'attente, une architecture de middleware orienté messages peut envoyer et recevoir des données.

Les files d'attente sont également nécessaires pour développer une communication asynchrone dans une architecture de middleware orienté messages. La file d'attente stocke les messages dans un ordre particulier en utilisant la norme premier entré, premier sorti (FIFO). Le message envoyé initialement à la file d'attente sera le premier à être récupéré de la file d'attente en utilisant le FIFO.

L'identité d'une file d'attente, sa taille, son seuil de sauvegarde, son mécanisme de filtrage des messages et d'autres propriétés sont toutes configurables. Dans la plupart des cas, chaque application a sa propre file d'attente ; cependant, dans certains cas, la configuration permet de partager des files d'attente. Les systèmes de middleware orienté messages peuvent prendre en charge une gamme de files d'attente.

Les modèles de messagerie les plus populaires dans les architectures de middleware orienté messages sont les modèles publication/abonnement (pub/sub) et point à point (P2P). Ces deux approches reposent sur l'échange de messages via une file d'attente. Un système typique combine ces approches pour atteindre divers objectifs et buts de messagerie.

Caractéristiques du middleware orienté messages

Le middleware orienté messages est un excellent moyen de faciliter la communication entre différents composants logiciels. Il est indépendant de la plateforme et permet une forme polyvalente d'échange de messages. Certaines des caractéristiques clés du middleware orienté messages sont les suivantes :

• Messagerie asynchrone : Lorsqu'une application cible est déconnectée ou occupée, le système enregistre temporairement les files d'attente de messages avec cette fonctionnalité. La plupart des systèmes asynchrones offrent un stockage pour la sauvegarde des files d'attente de messages, permettant aux expéditeurs et aux récepteurs de se connecter aux réseaux simultanément. Il résout également les problèmes causés par la connectivité intermittente.
• Livraison de message assurée : Les applications d'envoi de messages n'ont pas besoin de se connecter au réseau simultanément. Le MOM assure la livraison des messages lorsque les connexions sont établies et que l'application réceptrice émet une requête pour les messages transmis.
• Routage : Les files d'attente de messages sont utilisées dans de nombreux systèmes MOM pour le routage. Lorsqu'elles sont activées, certaines permettent à la couche de message de fournir une logique de routage. En revanche, d'autres dépendent des applications clientes pour fournir des informations de routage, et certaines nécessitent un hybride des deux approches.
• Transformation : Les plateformes MOM avec intelligence intégrée peuvent modifier et acheminer les informations pour répondre aux exigences de la source ou du destinataire. De plus, de nombreuses solutions basées sur le MOM offrent des capacités de transformation de messages puissantes qui permettent aux programmeurs de définir des règles pour des actions GUI faciles à glisser-déposer.
• Support des transactions : Le MOM fournit un support des transactions et est intimement lié aux services de transaction. Lorsque les services de transaction sont disponibles, ils peuvent participer à une transaction MOM.
• Services de notification : Bien que le MOM permette la transmission asynchrone de messages, l'application expéditrice pourrait vouloir connaître le statut de livraison du message dans certains cas. En conséquence, le MOM donne à l'expéditeur le choix de revoir les réponses, de laisser un autre service les gérer ou de les ignorer complètement. Certains systèmes MOM peuvent également journaliser les messages pour offrir des pistes d'audit.
• Caractéristiques supplémentaires : D'autres aspects que la plupart des systèmes MOM fournissent incluent la provision et la surveillance, la messagerie unifiée, la mise à l'échelle dynamique, la communication sécurisée, les outils de gestion et de contrôle, la qualité de service flexible et l'interaction avec d'autres appareils.

Types de middleware

Le middleware est la couche qui permet à différents composants logiciels d'interagir entre eux, mais quels sont les différents types de middleware ? Et quelles sont les raisons de choisir chacun d'eux ? Discutons-en ci-dessous.

• Middleware orienté messages est une architecture qui permet la réception et la transmission de messages entre les composants d'application. Il prend en charge le déploiement de logiciels sur plusieurs plateformes et simplifie le processus de développement d'applications qui s'étendent sur plusieurs systèmes d'exploitation et protocoles réseau. Il présente plusieurs avantages par rapport à d'autres options de middleware (comme la logique de codage en dur) et est l'une des formes de middleware les plus largement utilisées.
• Middleware objet, également connu sous le nom de courtier de requêtes d'objets, permet aux applications d'échanger des objets et d'accéder à des services via un système orienté objet. En un mot, il contrôle la communication des objets dans un système informatique distribué.
• Middleware d'appel de procédure à distance (RPC), ou middleware basé sur RPC, permet aux procédures d'une application d'invoquer des procédures dans d'autres applications comme s'il s'agissait d'appels locaux. Ce middleware inclut un mécanisme de liaison qui localise les opérations distantes et les rend disponibles de manière transparente pour les clients. Le middleware basé sur RPC gérait historiquement les systèmes basés sur des procédures, mais il intègre maintenant des composants basés sur des objets.
• Middleware de traitement des transactions (TP) inclut des systèmes tels que les moniteurs de traitement des transactions et les serveurs d'applications web. Son objectif est de créer un environnement pour développer et déployer diverses applications.
• Middleware de base de données permet un accès direct à la base de données. Il aide à établir une interaction directe avec les bases de données et inclut plusieurs passerelles de base de données et options de connexion.
• Middleware embarqué, ou middleware d'intégration, aide les entreprises à développer et à fournir un meilleur cadre d'intégration via un programme ou une interface matérielle. Il sert de pont entre les applications embarquées et le système d'exploitation en temps réel.
• Portails, également connus sous le nom de portails d'entreprise, ne sont pas techniquement des middleware. Cependant, ils sont classés comme middleware car ils permettent l'intégration frontale et favorisent l'interaction entre une machine cliente et des plateformes dorsales.
• Middleware centré sur le contenu acquiert du contenu via une abstraction fournisseur-consommateur et est largement appliqué dans les systèmes basés sur le contenu. Il est comparable au middleware de publication/abonnement, un autre logiciel fréquemment utilisé comme composant d'applications web.

MOM vs. RPC

Le mécanisme de communication que nous employons pour lier les différents composants d'une application distribuée est une considération importante lors de sa conception. Certains systèmes de middleware, tels que les services web, prennent en charge deux cadres de communication clés : middleware orienté messages (MOM) et appel de procédure à distance (RPC).

Avec le middleware orienté messages, les consommateurs de services peuvent se détacher physiquement et temporellement des fournisseurs de services. Les interactions entre les fournisseurs et les consommateurs sont asynchrones, car ils échangent des messages à partir de files d'attente de messages définies.

Les exemples d'implémentation de MOM incluent IBM Web Sphere MQ et Microsoft Message Queuing (MSMQ). Les systèmes de messagerie asynchrone éliminent le besoin pour l'application d'attendre la réponse - elle transmet simplement le message et exécute ses activités asynchrones.

Une autre caractéristique du MOM est son mode hors ligne, qui permet au client et au fournisseur de services de se déconnecter à tout moment sans perdre de messages dans la file d'attente.

Ils peuvent récupérer tous les messages en attente une fois qu'ils sont de nouveau en ligne. De plus, le MOM prend en charge une architecture pilotée par les événements ; l'administrateur peut classer les clients en fonction de leur accord de niveau de service (SLA) et demander des niveaux de qualité de service (QoS) variés. Cependant, cela rend les systèmes MOM exigeants en ressources, notamment en termes de mémoire, pour conserver des files d'attente continues de messages reçus mais non encore traités.

En revanche, le RPC fournit une communication synchrone entre les composants pour demander l'exécution de services distants. Les consommateurs doivent arrêter d'utiliser le service jusqu'à ce qu'ils reçoivent une réponse de la source.

Le MOM et le RPC ont tous deux des avantages et des inconvénients. Les systèmes MOM sont plus résilients aux pannes que les systèmes RPC, permettant aux demandeurs de services de continuer à traiter pendant que les fournisseurs de services agissent sur leurs demandes. Développer des applications basées sur le MOM est plus difficile car la distribution n'est pas aussi claire pour le développeur qu'avec les RPC.

Normes du MOM

Historiquement, il y a eu une rareté de réglementations régissant la mise en œuvre du middleware orienté messages ; cela a posé des problèmes. La plupart des principaux fournisseurs ont des versions avec des interfaces de programmation d'applications (API) et des outils d'administration.

La spécification XATMI du groupe X/Open est l'une des directives de longue date pour les applications basées sur le MOM. Elle définit clairement les API pour les interactions inter-processus. Les implémentations connues incluent le middleware Enduro/X d'ATR Baltic et Oracle Tuxedo.

Le protocole avancé de mise en file d'attente de messages (AMQP) est une référence qui décrit les protocoles et formats utilisés par les éléments logiciels participants pour assurer l'interopérabilité. L'AMQP utilise des schémas de routage flexibles, y compris les paradigmes de messagerie point à point, en éventail, publication/abonnement et demande-réponse. L'AMQP offre la gestion des transactions, la mise en file d'attente, la sécurité, l'administration, le clustering, la fédération et le support multi-plateforme hétérogène.

L'architecture de haut niveau (HLA IEEE 1516) est une norme d'interopérabilité de simulation développée par l'Institute of Electrical and Electronics Engineers (IEEE). Elle spécifie une gamme de services accessibles via une API en C++ ou Java.

La norme définit les échanges d'informations basés sur la publication/abonnement. Les échanges de données synchronisés, les installations d'avancement du temps et les points de synchronisation sont également basés sur le temps de simulation logique. Les services supplémentaires incluent l'optimisation de la distribution des données, le transfert de propriété et la gestion et la surveillance des systèmes participants.

L'environnement de programmation Java offre une API standard appelée Java Message Service (JMS) pour envoyer et recevoir des messages de manière indépendante du fournisseur en utilisant le langage de programmation Java. L'API JMS réduit l'expertise en messagerie d'entreprise nécessaire pour qu'un développeur Java construise des applications de messagerie étendues tout en conservant une certaine portabilité entre les implémentations de fournisseurs JMS.

Le protocole extensible de messagerie et de présence (XMPP) est un protocole de communication basé sur le langage de balisage extensible (XML) pour le middleware orienté messages. Le protocole, conçu pour être flexible, est également utilisé pour les systèmes de publication/abonnement, la signalisation pour la VoIP, le transfert de fichiers, la vidéo, les plateformes de réseaux sociaux et les applications de l'Internet des objets (IoT) telles que les réseaux intelligents.

Avantages du middleware orienté messages

Le logiciel de middleware orienté messages simplifie le développement d'applications qui s'étendent sur plusieurs packages logiciels et protocoles réseau. Il protège le développeur d'applications des spécificités des multiples systèmes d'exploitation et composants réseau.

Les MOM augmentent la flexibilité d'une architecture en offrant des versions d'API qui s'étendent de manière transparente sur plusieurs plateformes et réseaux. Cela permet aux programmes de communiquer librement sans savoir sur quel système ou processeur l'autre application fonctionne.

Voyons d'autres avantages de l'utilisation des MOM dans votre infrastructure.

• Simple et pratique : Les systèmes basés sur le MOM sont conviviaux, ce qui facilite le travail des développeurs et, par conséquent, augmente la productivité.
• Rationalise les opérations commerciales : Les systèmes MOM aident de nombreuses entreprises à améliorer l'efficacité et à rationaliser de nombreuses pratiques commerciales courantes.
• Adaptable : Les systèmes MOM s'intègrent et communiquent de manière transparente sur des plateformes diverses, même lorsque les applications individuelles fonctionnent séparément ou de manière asynchrone. Les applications sont maintenues indépendamment dans chaque environnement mais peuvent être mises à jour individuellement.
• Convivial pour les développeurs : Les MOM facilitent la tâche des développeurs pour concevoir de nombreux types de systèmes distribués.
• Indépendant du temps et du lieu : Étant donné que les MOM mettent en file d'attente les données même lorsque les abonnés sont hors ligne, l'expéditeur et le destinataire n'ont pas besoin d'être en ligne simultanément. De plus, les expéditeurs et les destinataires de messages sont séparés par la localisation et peuvent être déplacés d'un appareil à l'autre à l'exécution. La mise à jour des logiciels et du matériel depuis n'importe quel site signifie que les opérations commerciales peuvent se poursuivre sans interruption.
• Large gamme de systèmes logiciels : Le middleware orienté messages prend en charge une variété de structures logicielles, y compris le support des applications mobiles, les objets et composants distribués, et la communication orientée messages.
• Support des systèmes pilotés par les événements : Les solutions de middleware orienté messages permettent le développement d'applications dans une architecture pilotée par les événements.
• Évolutivité : Les systèmes MOM évoluent souvent efficacement en fonction du nombre de destinataires de messages. Par exemple, si de nombreux clients soumettent des demandes mais qu'un seul système les traite, vous pouvez augmenter la capacité de traitement des transactions en ajoutant plus de systèmes qui travaillent dans la même file d'attente.

Inconvénients du middleware orienté messages

L'utilisation du middleware orienté messages présente de nombreux avantages, mais il y a aussi quelques inconvénients.

• Les MOM nécessitent un élément architectural supplémentaire. L'existence d'un agent de transfert de messages ou d'un courtier est l'un des principaux inconvénients du middleware orienté messages. L'ajout de composants peut diminuer les performances d'un système, augmentant les coûts de maintenance et la complexité.
• Les MOM ont des coûts de développement élevés. De nombreuses organisations ne peuvent pas exploiter un système de middleware orienté messages en raison des coûts de développement élevés.
• Les MOM nécessitent des améliorations. De nombreux systèmes MOM ne sont toujours pas entièrement conçus pour des opérations optimales, ce qui peut menacer les performances en temps réel d'un système dans certaines conditions.

Le MOM à la rescousse

Si vous souhaitez améliorer la communication entre vos systèmes logiciels, le middleware orienté messages est une excellente option. Les systèmes basés sur le MOM peuvent gérer les pics de trafic tout en fournissant une solution flexible et résiliente pour les déploiements dispersés.

L'application appelante n'a pas besoin d'accéder aux systèmes distants pour envoyer un message. Un couplage lâche entre le client et le fournisseur permet aux systèmes agiles de s'étendre et de s'adapter en fonction de la demande.

Apprenez comment le logiciel d'analyse de flux peut aider votre entreprise à analyser les données en transfert entre les systèmes ou via des API.

Cet article a été publié à l'origine en 2022. Il a été mis à jour avec de nouvelles informations.