Name: Java Spring Le socle technique des applications Jakarta EE (5e édition)
Rating: 4 (1 reviews)

Introduction

Les intergiciels à messages, ou middleware de messagerie, en anglais Message-Oriented Middleware ou son abréviation MOM, sont des technologies logicielles qui facilitent l’échange de messages entre différentes applications, services ou systèmes. Ces intergiciels agissent comme des intermédiaires pour transmettre les messages de manière fiable et sécurisée, souvent dans des architectures distribuées ou microservices.

1. Fonctionnalités de base

Routage des messages : transmettre les messages d’une application ou d’un service à un autre.
Découplage : les producteurs et consommateurs de messages sont isolés les uns des autres, ce qui améliore la maintenabilité et l’évolutivité.
Fiabilité : assurer la livraison des messages même en cas de défaillance temporaire d’une partie du système.
Gestion de la charge : équilibrer la charge entre les services en distribuant les messages.

2. Exemples de middlewares de messagerie

Nous avons Apache Kafka qui est un système de messagerie distribué qui gère efficacement les flux de données en temps réel. Il est utilisé pour construire des pipelines de données en temps réel et pour gérer les flux de messages dans les applications de traitement d’événements.

Nous avons aussi RabbitMQ qui est un courtier de messages (message broker) qui implémente le protocole AMQP (Advanced Message Queuing Protocol). Il permet la communication asynchrone entre les microservices, l’équilibrage de charge et la résilience du système.

Nous avons également ActiveMQ qui est un autre courtier de messages populaire, également basé sur le protocole AMQP, ainsi que sur d’autres protocoles tels que STOMP, MQTT, etc. Il permet une intégration d’applications hétérogènes, de distribution de messages dans les systèmes d’entreprise.

Nous avons aussi AWS SQS (Simple Queue Service) qui est un service de messagerie en file d’attente entièrement géré dans le cloud offert par Amazon Web Services. Il est utilisé pour déconnecter les composants d’une application cloud, gérer les pics...

Implémentations open source

Protocole	Nom du fournisseur
ActiveMQ	Apache Software Foundation
HornetMQ	JBoss
JBoss Messaging	JBoss
Kafka	Apache Software Foundation
RabbitMQ	AMQP
ZeroMQ	Imatix

Bien que les implémentations des systèmes de messagerie soient souvent disponibles gratuitement, elles nécessitent une gestion interne pour le support et les adaptations spécifiques. Si des problèmes surviennent, il est de la responsabilité de l’équipe interne de les résoudre. Bien que ces systèmes soient relativement simples à développer, ils peuvent poser des défis majeurs lors de la mise en production et du passage à l’échelle. Pour surmonter ces difficultés, des entreprises spécialisées offrent des services d’amélioration des implémentations existantes et de support dédié, tant pour le développement que pour la production.

Ces entreprises peuvent également personnaliser les implémentations pour les adapter aux besoins spécifiques d’un client, optimisant certains aspects en fonction de l’utilisation prévue.

L’intervention d’experts en produits, bien qu’elle puisse sembler coûteuse initialement, peut souvent se révéler très bénéfique. L’expertise externe permet non seulement de gagner un temps précieux...

Implémentations propriétaires

Protocole	Nom du fournisseur
IBM WebSphere MQ	IBM
MSMQ	Tibco Software
TIBCO Rendezvous	JBoss
Synchrony Messaging	Axway

Ces implémentations sont souvent couplées avec d’autres outils dans un ensemble cohérent. Elles sont souvent onéreuses, mais il y a du support et des garanties. Elles apportent aussi des solutions « sur étagères » et sont parfois bien adaptées dans certains contextes.

Cas d’utilisation

Il existe aujourd’hui une multitude de protocoles et d’API comme JMS, STOMP, MQTT, AMQP, XMPP… et des outils qui se basent sur les messages comme Flume, Logstash, Syslog…

Dans ce chapitre, nous verrons quelques exemples d’utilisation avec Spring pour ActiveMQ (JMS), Redis et RabbitMQ pour l’utilisation pure MOM en abordant le contexte d’utilisation.

ActiveMQ est la réponse par défaut pour faire du MOM. Les outils Kafka, RabbitMG ont des patterns d’architectures différents pour répondre aux problèmes d’envoi et de réception de messages.

Pour le développement, nous devons choisir l’implémentation en fonction du contexte d’utilisation. Parfois, nous ne connaissons pas encore toutes les contraintes futures et nous ne savons pas comment l’application va évoluer. Il faut donc séparer dans le code l’implémentation de la fourniture et la consommation des messages du code métier de façon à pouvoir changer relativement facilement de MOM. Il s’agit de l’approche d’architecture hexagonale. Pour la partie technique du code, nous nous adaptons au mieux au MOM utilisé et Spring offre énormément d’aide sur ce point avec ses couches d’abstraction.

En effet, nous migrerons nos applications pour prendre en compte les préoccupations les plus importantes :

facilité d’utilisation au niveau codage ;
facilité pour les tests ;
mise à...

JMS et ActiveMQ

JMS (Java Messaging Service) est une interface de programmation qui permet d’échanger des messages de façon asynchrone (et plus rarement synchrone en mode point à point) entre applications Java.

Tous les serveurs Jakarta EE fournissent un service JMS lié avec le JCA (Java Connector Architecture).

JMS s’appuie sur un intergiciel (middleware) pour l’implémentation.

Il y a historiquement plusieurs versions de JMS :

Versions	Dates	Compléments
1.0.2b	juin 2001
1.1	mars 2002
2.0	mars 2013	JSR 343
2.1	Septembre 2017	JSR 368 retirée

JSR 343 : JMS (Java Message Service) 2.0

JSR 368 : JavaTM Message Service 2.1

JMS n’est plus prioritaire pour Java EE 8.

Il faut un fournisseur de service pour JMS.

Voici une liste de fournisseurs open source :

Librairie	Fournisseur
ActiveMQ	Apache
OpenJMS	Collectif
JBoss Messaging	JBoss
HornetQ	JBoss
JORAM/OW2	ObjectWeb
Open Message Queue	Sun Microsystem

Il y a aussi des implémentations propriétaires comme BEA Weblogic et Oracle AQ d’Oracle, WebSphere MQ d’IBM et SAP NetWeaver de SAP qui ont leur utilité dans des contextes d’utilisation adaptés.

Pour les exemples illustrant JMS, nous utiliserons ActiveMQ d’Apache (http://activemq.apache.org/) qui supporte JMS depuis la version 1.1 et J2EE 1.4.

La version 6.0.1 d’Active MQ apporte le support de JMS. Cette version supporte aussi AMQP v1.0 et MQTT. Elle fonctionne avec Spring 6, Log4j. Active MQ peut être monté en mémoire pour les tests JUnit. Son exploitation avec Spring est très simple via l’utilisation des classes JmsInvokerServiceExporter et JmsInvokerProxyFactoryBean.

Utilisation...

RabbitMQ

RabbitMQ est basé sur AMQP et a été créé par Pivotal. Il est sous licence Mozilla Public License. Il prend le relais d’ActiveMQ.

1. Spring AMQP et RabbitMQ

Dans le monde des échanges de messages asynchrones, on découple les parties producteur et consommateur. Un producteur produit un message sur une zone logique appelée un Exchange. Nous publions un message via le routing key. La queue est déterminée par cette routing key, mais le producteur ne sait pas quelle queue sera utilisée pour véhiculer son message.

Le consommateur déclare une queue, il s’inscrit par rapport à un exchange et définit une binding key qui indique la règle de routage qui permet de transférer le message jusqu’à lui.

Cela lui permet de filtrer les messages qu’il souhaite recevoir dans la zone Exchange.

On type les exchanges de deux façons :

Fanout : on envoie les messages en broadcast sans règles de routing.
Direct : correspondance entre la routing key et la binding key.
Topic : pour une routing key, possibilité d’utiliser des jokers (wildcards) dans les binding key.

On peut modéliser ainsi :

Élément	Pattern	Remarques
Exchange	Business domain
Queue	Service	Consomme les messages
Routing key	Type d’événement envoyé
Binding key	Agrégateur d’événements pour un service

Par exemple, dans une application microservice, on sépare les préoccupations et on propage des événements dans différents « noyaux »...

Points clés

Points à retenir :

Les MOM sont très pratiques pour faire communiquer des microservices ou des applications monolithiques.
Il n’y a pas beaucoup de différences au niveau du code entre les différentes solutions de MOM.
Il faut garder à l’esprit que l’architecture peut évoluer.
Les MOM permettent de retirer de la tension dans certains goulots d’étranglement en lissant la charge sur les appels.

Les intergiciels à messages (MOM)