JMS ActiveMQ SpringBoot KAFKA v11 231220 202412

Middlewares Orientés Messages
Mise en œuvre de JMS

avec Spring Framework
ActiveMQ, RabbitMQ, KAFKA
Plan du cours
1. Architecture: Enterprise Application Integration(EAI)

1. EAI / Event Driven Architecture
2. Les MOM (Middleware Oriented Message)
3. Communication Distribuée Synchrone/Asynchrone
2. Java Message Service (JMS):

1. Les protocoles de communication
2. Le modèle de programmation JMS
3. L’architecture JMS
3. Brokers : Active MQ / Rabbit MQ / KAFKA

4. Spring Boot et JMS
Etude de cas : Swift (Society for Worldwide
Interbank Financial Telecommunication)
▪ Créée en 1973, SWIFT est une société privée belge qui offre une plate-forme de messagerie
sécurisée, des standards pour communiquer et un package de produits et de services autour
de cette messagerie.
▪ Ce réseau est principalement utilisé pour transmettre des informations pour réaliser des
virements bancaires.
▪ Plus de 11 000 organisations bancaires et de titres, infrastructures de marché et entreprises

en sont clientes dans plus de 200 pays et territoires.
▪ En 2022, SWIFT a transmis plus de 12 milliards d’ordres de paiement dans le monde, avec un
pic journalier à plus de 55 millions.
▪ SWIFT est un intermédiaire facilitant le transport des messages contenant des instructions de
paiement entre les institutions financières impliquées dans une transaction.
▪ Les messages financiers ont le format standard ISO 200222 MX, ces types de messages
s’expriment en utilisant la syntaxe XML.
Whatsap /
Etude de cas : Swift (Society for Worldwide
Interbank Financial Telecommunication)
Catégorie de
Exemple
message
▪ La plateforme Swift est basée sur les concepts : MT1xx MT103 Single customer credit transfer
MT202 General financial institution

▪ Les messages MT2xx
transfer
▪ La communication Asynchrone MT3xx MT300 Foreign exchange confirmation
▪ La fiabilité et la garantie de transmission des MT5xx Securities Markets

messages
MT6xx MT600 Precious metal trade
MT9xx MT950 Statement

Enterprise Application Integration(EAI)
▪ L'intégration d'applications d'entreprise ou IAE est une architecture « inter-
gicielle » permettant à des applications hétérogènes de gérer leurs échanges, en
implémentant les flux inter-applicatifs du système d'information.
▪ L’EAI est un framework d'intégration composé d'un ensemble de technologies et
de services qui forment un middleware pour permettre l'intégration de systèmes et
d'applications dans une entreprise. On le place dans la catégorie des technologies
d'intégration métier (business integration) et d'urbanisation.
▪ L’EAI permet d’éviter les situations de type « spaghetti », une allusion à
l'équivalent en programmation du « code spaghetti ».

EAI VS « Spaghettie » : point-to-point based-integration
EAI VS « Spaghettie » : Middleware Oriented Message(MOM)
Enterprise Application Integration(EAI)
▪ « Enterprise Integration Patterns » est un livre de Gregor Hohpe et Bobby Woolf et
décrit 65 patterns pour l'utilisation de l'intégration d'applications d'entreprise et du
middleware orienté message.
▪ Le livre distingue 4 types d’intégration majeurs de premier niveau:
1. Transfert de fichier
2. Base de données partagée
3. Invocation de procédure à distance
4. Messagerie :
1. Entête « Header » et corps/contenu « PayLoad »
2. Channel : point-to-point ou de type publish/subscriber
3. Envoi bloquant ou asynchrone

EAI : Middleware Oriented Message(MOM)
✓ Caractéristiques des MOM :
▪ Transport de messages: Les messages comportent deux parties: l’entête
technique, utilisée par le MOM et les données qui peuvent être dans
n'importe quel format.
▪ Communication asynchrone: La file d'attente reçoit le message de

l'application émettrice et le stocke jusqu'à ce que l'application réceptrice
vienne lire le message.
▪ Routage: Les messages peuvent être routés entre MOM(s).
▪ Transformation des données: Les MOM permettent de changer le format

des données contenues dans les messages pour les adapter à l'application
réceptrice.
✓ Caractéristiques des MOM :
▪ Persistance des messages: Les messages présents dans les files d'attente
peuvent être sauvegardés sur un support physique pour en assurer la
conservation en cas de panne.
▪ Fiabilité: Chaque message envoyé par une application fait l'objet d'un
accusé de réception par le MOM.
Chaque application qui consomme un message envoie un accusé de
réception au MOM.
Couplé avec la persistance, ce mécanisme permet de garantir qu'aucun
message ne sera perdu dans son transfert entre les applications.
✓ Principes de fonctionnement:
Les MOM ont deux modes de fonctionnement principaux :
1. Point à point : une application produit des messages et une application les
consomme. Les messages ne sont lus que par un seul consommateur. Une fois
qu'un message est lu, il est retiré de la file d'attente.
2. Publish-subscribe (par abonnement) : les applications consommatrices des
messages s'abonnent à un topic (sujet, catégorie de messages). Les messages
envoyés à ce topic restent dans la file d'attente jusqu'à ce que toutes les
applications abonnées aient lu le message.

✓ Normalisation: Dans le monde Java, l'API Java Message Service (JMS) est la norme pour
accéder aux fonctionnalités des MOM.
✓ Au niveau protocole :
▪ AMQP (Advanced Message Queuing Protocol) définit un protocole sécurisé, fiable et
ouvert pour les MOMs, développé initialement par la Banque multinationale JPMorgan.
Puis devenu un standard OASIS depuis Octobre 2012, approuvé par l'ISO depuis mai
2014.
Structure d’un message JMS
Structure d’un message AMQP

▪ MQTT (MQ Telemetry Transport) offre un protocole publish-
subscribe adapté à la communication dans un contexte M2M
et IoT où une faible empreinte et une économie de la bande
passante sont nécessaires. MQTT est un standard OASIS
depuis novembre 2014, approuvé par l'ISO depuis janvier
2016.
▪ STOMP (Streaming Text Oriented Message Protocol),
auparavant connu sous le nom de TTMP, est un protocole
textuel au-dessus de TCP, conçu pour permettre l'interaction
avec les MOM
✓ Liste de MOM (non exhaustive) :
Open-source Propriétaires
Open Message Queue (Open MQ) (GlassFish) * IBM WebSphere MQ
ActiveMQ (Apache Software Foundation) MSMQ de Microsoft
Kafka (Apache Software Foundation) TIBCO EMS de Tibco Software
RabbitMQ (AMQP) Synchrony Messaging d'Axway
JBoss Messaging (JBoss) SonicMQ de Progress Software
HornetMQ (Jboss) Oracle WebLogic Server
OpenJMS (OpenJMS Group) SAP NetWeaver

OpenAMQ (Imatix) webMethods Broker Server
webMethods Universal Messaging
JORAM (OW2) FioranoMQ de Fiorano
* Open Message Queue (Open MQ): représente l'implémentation de référence pour la

spécification JMS (Java Message Service) et du fournisseur JMS dans GlassFish.
Communication distribuée Synchrone
Communication distribuée Asynchrone
Java Message Service (JMS)
• https://www.oracle.com/java/technologies/java-message-service.html
• https://javaee.github.io/openmq/
L’API JMS
▪ L'API Jakarta Messaging (anciennement Java Message Service ou JMS API) est une
interface de programmation d'application (API) Java pour les middlewares orientés
messages.
▪ Elle fournit des modèles de messagerie génériques, capables de gérer les problèmes
de publish-subscriber, la communication Asynchrone, et la fiabilité de délivrance des
messages
▪ JMS fait partie de Jakarta EE à partir de la version 1.3 de JEE.
▪ JMS peut accéder aux différents MOM : Active MQ, KAFKA, Rabbit MQ, IBM MQ…
▪ Versions de l'API JMS:
▪ JMS 1.0.1 (October 5, 1998)
▪ JMS 1.1 (April 12, 2002)
▪ JMS 2.0 (May 21, 2013)
▪ JMS 2.0a (March 16, 2015)
L’API JMS : Les éléments JMS
1.JMS Provider: Une implémentation de l'interface JMS pour les (MOM). Les Providers
(fournisseurs) sont implémentés sous la forme d'une implémentation Java JMS.
2. JMS Client: Une application ou un processus qui produit et/ou reçoit des messages.
3. JMS Producer/Publisher: Un client JMS qui crée et envoie des messages.
4. JMS Consumer/Subscriber: Un client JMS qui reçoit des messages.
5. JMS Message : Objet qui contient les données transférées entre les clients JMS.
6. JMS Queue: Une zone de transfert qui contient les messages qui ont été envoyés et qui
attendent d'être lus (par un seul consommateur). Une file d'attente JMS garantit que chaque
message n'est traité qu'une seule fois.
▪ JMS Topic: Un mécanisme de distribution pour publier des messages envoyés à plusieurs
abonnés.
Les Protocoles de Communication
Le Protocole point-à-point (Queue)
• Ce protocole est basé sur le concept de Queue de Messages, d’émetteurs et de receveurs.

• Chaque message est adressé à une queue spécifique et les clients consomment leurs
messages.
• Ce protocole doit être utilisé pour s’assurer qu’un seul client consommera le message.
• Il est possible de filtrer les messages reçus d'une destination au moyen d'un sélecteur
(selector) via des expressions semblables à SQL. Le filtre se fait par le Broker.
• Le filtre ne peut s'appliquer que sur certaines données de l'en-tête : JMSDeliveryMode,
JMSPriority, JMSMessageID, JMSCorrelationID, JMSType et JMSTimestamp
• Le filtre peut aussi utiliser toutes les propriétés personnelles du message
messageConsumer consumer=session.createConsumer(destination,«myPropertie=‘XYZ'");
Le Protocole publish-subscriber (Topic)
• Le principe des filtres (selector) est valable pour les Topic également.
La consommation des messages
Le modèle de programmation JMS
• L’interface jakarta.jms.ConnectionFactory
• L’interface jakarta.jms.Connection
• L’interface jakarta.jms.Session
• L’interface jakarta.jms.MessageProducer
L’interface jakarta.jms.MessageConsumer
• Synthèse des principaux Interfaces de JMS :
• JMS 1.1
• JMS 2.0
1.jakarta.jms : Ce package et ses sous−packages contiennent plusieurs interfaces qui
définissent l’API: Factory, Connection, Session, Message, MessageProducer,
MessageListener
2. La fabrique de connexions Factory :
▪ Un objet de type Factory produit une connexion permettant l'accès au broker.
▪ Il existe deux types de fabriques : QueueConnectionFactory et TopicConnectionFactory

selon le type d'échange que l’on fait. Ce sont des interfaces que le broker de messages doit
implémenter pour fournir des objets.
▪ Pour obtenir un objet de ce type, il faut soit instancier directement un tel objet soit faire appel
à JNDI pour l'obtenir. Cette dernière solution est préférable car elle est plus portable.
▪ La fabrique de type ConnectionFactory permet d'obtenir une instance de l'interface

Connection.
▪ Chaque provider fournit sa propre solution pour gérer les objets contenus dans l'annuaire
JNDI.
3.L'interface Connection :
▪ Cette interface définit des méthodes pour la connexion au broker de messages.
▪ Cette connexion doit être établie en fonction du mode utilisé :

▪ l'interface QueueConnection pour le mode point à point
▪ l'interface TopicConnection pour le mode publication/abonnement
▪ Pour obtenir l'un ou l'autre, il faut utiliser un objet de type Factory correspondant au type
QueueConnectionFactory ou TopicConnectionFactory avec la méthode correspondante :
createQueueConnection() ou createTopicConnection().
▪ La classe qui implémente cette interface se charge du dialogue avec le broker de

messages.
▪ La méthode start() permet de démarrer la connexion : connection.start();
▪ La méthode stop() permet de suspendre temporairement la connexion.
▪ La méthode close() permet de fermer la connexion.

4. L'interface Session
▪ Représente un contexte transactionnel de réception et d'émission pour une connexion

donnée à partir d'un objet de type Connection que l'on crée.
▪ C'est à partir d'un objet session que l'on crée des messages et des objets à envoyer et à
recevoir.
▪ Comme pour la connexion, la création d'un objet de type Session dépend du mode de
fonctionnement. L'interface Session possède deux interfaces filles :
▪ l'interface QueueSession pour le mode point à point
▪ l'interface TopicSession pour le mode publication/abonnement
▪ Pour obtenir l'un ou l'autre, il faut utiliser un objet Connection correspondant de type
QueueConnection ou TopicConnection avec sa méthode associée : createQueueSession() ou
createTopicSession().
▪ Ces deux méthodes demandent deux paramètres : un booléen qui indique si la session gère
une transaction et une constante qui précise le mode d'accusé de réception des messages.
4. L'interface Session
▪ Les messages sont considérés comme traités par le MOM à la réception d'un accusé
de réception. Celui−ci est fourni au MOM selon le mode utilisé. Il existe trois modes
d'accusés de réception (trois constantes sont définies dans l'interface Session) :
▪ AUTO_ACKNOWLEDGE : l'accusé de réception est automatique, le MOM reçoit

l'accusé de réception à la réception du message que ce dernier soit traité ou non par
l'application
▪ CLIENT_ACKNOWLEDGE : le MOM reçoit explicitement l'acquittement de la part de

l'application, c'est le client qui envoie l'accusé grâce à l'appel de la méthode
acknowledge() du message
▪ DUPS_OK_ACKNOWLEDGE : ce mode permet d'indiquer au MOM qu'il peut envoyer

plusieurs fois le message à une même destination. Ce mode peut améliorer les
performances de certains MOM notamment avec un nombre de messages très
important.
• L'interface Session définit plusieurs méthodes dont les principales sont :

5. Les messages
▪ Les messages sont encapsulés dans un objet de type jakarta.jms.Message : ils doivent
obligatoirement implémenter l'interface Message ou l'une de ses sous−classes.
▪ Un message est constitué de trois parties :
1.L'en−tête (header) : contient des données techniques
2.Les propriétés (properties) : contient des données fonctionnelles
3.Le corps du message (body) : contient les données du message
▪ L'interface Session propose plusieurs méthodes createXXXMessage() pour créer des

messages contenant des données au format XXX.
▪ Il existe aussi pour chaque format des interfaces filles de l'interface Message :
5. L'envoi de messages
▪ L'interface MessageProducer est la super−interface des interfaces qui
définissent des méthodes pour l'envoi de messages.
▪ Il existe deux interfaces filles selon le mode de fonctionnement pour
envoyer un message : QueueSender et TopicPublisher.
▪ Ces objets sont créés à partir d'un objet représentant la session :
 la méthode createSender() pour obtenir un objet de type QueueSender
 la méthode createPublisher() pour obtenir un objet de type TopicPublisher

6. La réception de messages
▪ L'interface MessageConsumer est la super−interface des interfaces qui définissent des
méthodes pour la réception de messages.
▪ Il existe des interfaces selon le mode de fonctionnement pour recevoir un message

QueueReceiver et TopicSubscriber.
▪ La réception d'un message peut se faire avec deux modes :
 synchrone : dans ce cas, l'attente d'un message bloque l'exécution du reste du code
 asynchrone : dans ce cas, un thread est lancé qui attend le message et appelle une
méthode (callback) à son arrivée. L'exécution de l'application n'est pas bloquée.
▪ Pour obtenir un objet qui implémente l'interface QueueReceiver, il faut utiliser la méthode
createReceiver() d'un objet de type QueueSession.
▪ Pour obtenir un objet qui implémente l'interface TopicSubscriber, il faut utiliser la méthode
createSubscriber() d'un objet de type TopicSession.
6. La réception de messages
L'interface MessageConsumer définit plusieurs méthodes dont les principales sont :

Exemple de Code pour un Producer JMS
▪ Transactionnel ?
▪ Gestion des accusés de réception
Par défaut JMS est non persistent

Exemple de Code pour un Consumer JMS
Implémentation de JMS avec Spring
▪ Spring offre une abstraction pour faciliter la mise en œuvre de l'API JMS. Il propose une API
qui fournit une abstraction dans la mise en œuvre de JMS version 1.0.2 et 1.1.
▪ Les classes de Spring dédiées à la mise en œuvre de JMS sont dans le package
org.springframework.jms.
▪ Le package org.springframework.jms.core contient les classes et interfaces de base pour

utiliser JMS avec Spring. Il contient notamment un Template qui est un helper prenant en
charge la création et la libération des ressources.
▪ Le package org.springframework.jms.connection contient des classes pour la connexion et la

gestion des transactions avec JMS. Il fournit une implémentation de ConnectionFactory.
▪ Le package org.springframework.jms.support.converter contient des utilitaires pour convertir

des messages en objets. Il fournit notamment la classe MessageConverter pour convertir un
message JMS en objet Java.
▪ Le package org.springframework.jms.support.destination fournit plusieurs fonctionnalités pour

gérer les destinations JMS.
▪ JmsTemplate est la classe de base pour faciliter l'envoi et la réception de messages
JMS de façon synchrone. Cette classe se charge de gérer la création et la libération
des ressources utiles pour JMS.
▪ JmsTemplate propose des méthodes permettant d'envoyer un message, de

consommer un message de manière synchrone et de permettre un accès à la session
JMS et au message producer
▪ Une instance de JmsTemplate est utilisée pour recevoir les messages de
manière synchrone
▪ La méthode receive() attend un nouveau message sur la destination par
défaut de l'instance de JmsTemplate. Une autre surcharge de la méthode
receive() attend un nouveau message sur la destination fournie en
paramètre.
▪ La propriété receiveTimeout de la classe JmsTemplate permet de préciser
un timeout d'attente puisque la réception est synchrone.

▪ Remarque : La classe JmsTemplate peut être utilisée pour envoyer des messages mais elle
n'est pas recommandée pour en recevoir. Pour la réception d'un message, il est préférable
d'utiliser une solution asynchrone reposant sur un MessageListener de Spring.
▪ Utilisation de MessageListener pour la réception de message en mode asynchrone
▪ Remarque : on peut utiliser également @JmsListener

Créer son propre Broker Active MQ
Les protocoles supportés
▪ JMS supporte le protocole TCP.
▪ Les autres ont été ajoutés par les différents Brokers
▪ https://www.youtube.com/watch?v=j5qf5YDtOeA
Active MQ
https://activemq.apache.org/
https://activemq.apache.org/
Simple Producer JMS
Simple Producer JMS
Simple Producer JMS
KAFKA : une plateforme pour la gestion des flux
• Apache Kafka est une plateforme de streaming qui répond aux besoins et défis de la Big
Data en termes de traitement temps réel d’une grande quantité de données de manière
distribuée.
• Kafka bénéficie de trois fonctionnalités:

1. Permet de publier et souscrire à un flux d'enregistrements. Elle ressemble ainsi à une file
de message ou un système de messaging d'entreprise
2. Permet de stocker des flux d'enregistrements d'une façon tolérante aux pannes
3. Permet de traiter les enregistrements au fur et à mesure qu'ils arrivent « streaming »
• Les principaux avantages de Kafka sont:

1. La fiabilité: Kafka est distribué, partitionné, répliqué et tolérant aux pannes.
2. La scalabilité: Kafka se met à l'échelle facilement et sans temps d'arrêt.
3. La durabilité: Kafka utilise un commit log distribué, ce qui permet de stocker les messages
sur le disque le plus vite possible.
4. La performance: Kafka a un débit élevé pour la publication et l'abonnement.
Architecture KAFKA
• Ci-après les notions de base de Kafka :
1. Topic: Un flux de messages appartenant à une catégorie particulière. Les données sont
stockées dans des topics.
2. Partitions: Chaque topic est divisé en partitions. Pour chaque topic, Kafka conserve un
minimum d'une partition. Chaque partition contient des messages dans une séquence
ordonnée immuable. Une partition est implémentée comme un ensemble de segments de
tailles égales.
3. Offset: Les enregistrements d'une partition ont chacun un identifiant séquentiel appelé offset,
qui permet de l'identifier de manière unique dans la partition.
4. Répliques: Les répliques sont des backups d'une partition. Elles ne sont jamais lues ni
modifiées par les acteurs externes, elles servent uniquement à prévenir la perte de données.
5. Brokers: Les brokers (ou courtiers) sont des systèmes responsables de maintenir les données
publiées. Chaque nroker peut avoir zéro ou plusieurs partitions par topic. Si un topic admet N
partitions et N broker, chaque broker va avoir une seule partition. Si le nombre de brokers est
plus grand que celui des partitions, certains n'auront aucune partition de ce topic.
Architecture KAFKA
6. Cluster: Un système Kafka ayant plus qu'un seul Broker est appelé cluster Kafka. L'ajout de
nouveau brokers est fait de manière transparente sans temps d'arrêt.
7. Producers: Les producteurs sont les éditeurs de messages à un ou plusieurs topics Kafka. Ils
envoient des données aux brokers Kafka. Chaque fois qu'un producteur publie un message à
un broker, ce dernier rattache le message au dernier segment, ajouté ainsi à une partition. Un
producteur peut également envoyer un message à une partition particulière.
8. Consumers: Les consommateurs lisent les données à partir des brokers. Ils souscrivent à un
ou plusieurs topics, et consomment les messages publiés en extrayant les données à partir des
brokers.
9. Leaders: Le leader est le nœud responsable de toutes les lectures et écritures d'une partition
donnée. Chaque partition a un serveur jouant le rôle de leader.
10.Follower: C'est un nœud qui suit les instructions du leader. Si le leader tombe en panne, l'un
des followers deviendra automatiquement le nouveau leader
Architecture KAFKA
La figure suivante montre un exemple de flux entre les différentes parties d'un système Kafka:
Cluster Kafka
Offset « enrg_id1 »
Offset « enrg_id2 »
Architecture KAFKA
• Dans cet exemple, un topic est configuré en trois partitions.
• En supposant que, si le facteur de réplication du topic est de 3, alors Kafka va
créer trois répliques identiques de chaque partition et les placer dans le cluster
pour les rendre disponibles pour toutes les opérations.
• L'identifiant de la réplique est le même que l'identifiant du serveur qui l'héberge.
• Pour équilibrer la charge dans le cluster, chaque broker stocke une ou plusieurs
de ces partitions.
• Plusieurs producteurs et consommateurs peuvent publier et extraire les messages
au même moment.
KAFKA et ZooKeeper
• Zookeeper est un service centralisé permettant de maintenir l'information de
configuration, de nommage, de synchronisation et de services de groupe.
• Ces services sont utilisés par les applications distribuées en général, et par Kafka
en particulier. Pour éviter la complexité et difficulté de leur implémentation
manuelle, Zookeeper est utilisé.
KAFKA et ZooKeeper
• Un cluster Kafka consiste typiquement en plusieurs courtiers (Brokers) pour
maintenir la répartition de charge.
• Ces Brokers sont stateless, c'est pour cela qu'ils utilisent Zookeeper pour
maintenir l'état du cluster.
• Un broker peut gérer des centaines de milliers de lectures et écritures par

seconde, et chaque broker peut gérer des téra-octets de messages sans impact
sur la performance. Zookeeper est utilisé pour gérer et coordonner les courtiers
Kafka. Il permet de notifier les producteurs et consommateurs de messages de la
présence de tout nouveau courtier, ou de l'échec d'un courtier dans le cluster.
Annexe
Présentation de J2EE (1/3)
• J2EE est une plate-forme fortement orientée serveur pour le développement et
l'exécution d'applications distribuées. Elle est composée de deux parties
essentielles :
➢ un ensemble de spécifications pour une infrastructure dans laquelle

s'exécutent les composants écrits en Java : un tel environnement se nomme
serveur d'applications.
➢ un ensemble d'API qui peuvent être obtenues et utilisées séparément. Pour

être utilisées, certaines nécessitent une implémentation de la part d'un
fournisseur tiers.
Les API de J2EE
Les API de J2EE
Les API de J2EE
Les API de J2EE
version de l'API dans
API
1.2 1.3 1.4 5 6 7
Entreprise Java Bean (EJB) 1.1 2.0 2.1 3.0 3.1 3.2
Remote Method Invocation (RMI) et RMI-IIOP 1.0
Java Naming and Directory Interface (JNDI) 1.2 1.2 1.2.1
Java Database Connectivity (JDBC) 2.0 2.0 3.0
Java Transaction API (JTA) 1.0 1.0 1.0 1.1 1.1 1.2
Java Transaction Service (JTS)
Java Messaging service (JMS) 1.0 1.0 1.1 1.1 1.1 2.0
Servlets 2.2 2.3 2.4 2.5 3.0 3.1
Java Server Pages (JSP) 1.1 1.2 2.0 2.1 2.2 2.2
Java Server Faces (JSF) 1.2 2.0 2.2
Expression Language (EL) 2.2 3.0
Java Server Pages Standard Tag Libray (JSTL) 1.2 1.2 1.2

API
1.2 1.3 1.4 5 6 7
JavaMail 1.1 1.2 1.3 1.4 1.4 1.4
J2EE Connector Architecture (JCA) 1.0 1.5 1.5 1.6 1.6
Java API for XML Parsing (JAXP) 1.1 1.2
Java Authentication and Authorization Service
1.0
(JAAS)
JavaBeans Activation Framework 1.0.2 1.0.2
Java API for XML-based RPC (JAXP-RPC) 1.1 1.1 1.1 1.1
SOAP with Attachments API for Java (SAAJ) 1.2 1.3
Java API for XML Registries (JAXR) 1.0 1.0 1.0 1.0
Java Management Extensions (JMX) 1.2
Java Authorization Service Provider Contract
1.0 1.1 1.4 1.4
for Containers (JACC)
Java API for XML-Based Web Services (JAX-
2.0 2.2 2.2
WS)
Les API de J2EE
API
1.2 1.3 1.4 5 6 7
Java Architecture for XML Binding (JAXB) 2.0 2.2
Streaming API for XML (StAX) 1.0
Java Persistence API (JPA) 1.0 2.0 2.1
Java API for RESTful Web Services (JAX-RS) 1.1 2.0
Web Services 1.2 1.3 1.3

Web Services Metadata for the Java Platform 2.1 2.1
Java APIs for XML Messaging (JAXM) 1.3
Context and Dependency Injection (CDI) 1.0 1.1
Dependancy Injection (DI) 1.0
Bean Validation 1.0 1.1
Managed beans 1.0 1.0
API
1.2 1.3 1.4 5 6 7
Interceptors 1.1 1.1
Common Annotations 1.1 1.1
Java API for WebSocket 1.0
Java API for JSON 1.0
Concurrency Utilities for Java EE 1.0
Batch Applications for the Java Platform 1.0
Diagramme des composants Java SE (Standard Edition)
NB : Java SE est différent de Java EE

Communication par message: Synchrone vs. Asynchrone
1. Synchrone / bloquante : L’émetteur reste bloqué jusqu’à ce que le destinataire acquitte la
réception du message (« Acknowledgement »)
2. Asynchrone / non-bloquante (Fire and Forget) :

▪ L’émetteur continue de s’exécuter après avoir soumis le message pour la transmission
Besoins d’un couplage faible
▪ Le développeur veut éviter qu’un composant
dépende de l’interface des autres composants
ou même de « connaître » les autres composants
(Références directes)
Zoom sur l’API « JMS » : architecture des échanges
▪ Basée sur deux types d’objets : Queue et Topic

▪ Le Messaging Server est un MOM : Message Oriented Middleware
▪ Plusieurs MOM ou JMS provider existent sur le marché : Active MQ, Rabbit MQ …
Zoom sur l’API « JMS » : mode (1) Point To Point message
▪ Les messages de type P2P sont destinés a un seul destinataire

▪ Dans ce mode on utilise l’objet Queue
▪ La file d'attente (Queue) est chargée de retenir le message jusqu'à ce que le destinataire soit prêt
▪ Pas de dépendance temporelle entre émetteur et destinataire du message
▪ Le destinataire peut acquitter les messages reçus
Zoom sur l’API « JMS » : mode (1) Point To Point message
Exemple : envoie d'un message dans une queue
Fichier de paramétrage « jndi.properties »

Zoom sur l’API « JMS » : mode (2) Publish/Subscriber message
▪ Les messages de type P/S sont destinés a un plusieurs destinataires

▪ Dans ce mode on utilise l’objet Topic
▪ Dépendance temporelle : Un client ne peut lire un message qu’après s’être abonné à un topic
▪ Un client abonné à un topic doit continuer à être actif pour recevoir les message du topic.
Zoom sur l’API « JMS » : mode (2) Publish/Subscriber message
Grâce à la version 1.1 de JMS,
pour envoyer un message
dans le topic1, il suffit
simplement le remplacer le
nom JNDI de la destination
destination = (Destination)
context.lookup("topic1");
Exemple : envoie d'un message dans une Topic
Exemple : lecture d'un message dans une file d'attente

Les API de J2EE : Historique
La fondation Eclipse a pris en

charge J2EE 8 qui est devenu
par la suite JAKARTA EE
depuis 2018
Java EE 7 : Zoom sur l’API BATCH
• Les applications par lots (BATCH) fournissent un modèle de programmation pour les applications par
lots/étapes et un environnement d'exécution pour la planification et l'exécution des tâches.
• L'API Java BATCH définie dans JEE 7 (JSR 352) a pour vocation de permettre l'exécution de jobs (ou
traitements batch) dans le contexte d'une application JEE et donc d'un serveur d'application (Glassfish,
JBOSS,…)
• Elle permet entre autres de définir des checkpoints, de supporter les transactions, elle permet aussi de
morceler et paralléliser les traitements.
• Elle s'intègre à JEE et peut profiter, par exemple, des fonctionnalités des serveurs d'application : injection
de dépendances (CDI), gestion des transactions (JTA)…

Java EE 7 : Zoom sur l’API BATCH/ Architecture générale d'un batch
▪ Un Job définit des étapes (Step), qui peuvent suivre le modèle ItemReader/ ItemProcessor/ ItemWriter.
▪ L'instance de JobOperator propose une manière d'interagir avec un batch Job (il peut l'arrêter, le démarrer,
le redémarrer, etc.)
▪ Chacun des éléments JobOperator, Job et Step sont associés à un unique JobRepository qui contient les
métadonnées associées à l'exécution courante.
▪ La configuration se fait de façon déclarative dans un fichier XML (couramment appelés « job.xml »).
▪ Le package javax.batch contient les classes et interfaces nécessaires
Java EE 7 : Zoom sur l’API BATCH/ Exécution d'un job
▪ Dans le diagramme ci-dessus, pour chaque élément (Item) de l'étape (des lignes d'un fichier par exemple),
le Step invoque n fois le couple read()/process(). Une fois la liste d'éléments constituée, l'opération write est
appelée sur ces éléments pour, par exemple, les stocker en base, les enregistrer dans un fichier, les
envoyer vers un flux de sortie, etc.
▪ Nous présenterons ainsi les éléments step (batchlet et chunck), nous présenterons également les points de
sauvegarde (checkpoints), nous préciserons finalement comment l'API gère les erreurs lors de l'exécution
des traitements.
Java EE 7.0 : les serveurs
Java EE 7.0 Web Profile : les serveurs
RAPPEL
Apache Tomcat : c’est un Conteneur Web. Il permet d’exécuter uniquement les JSP/Servlet et
JSF. Apache Tomcat contient un serveur Web Apache. On l’appel le serveur web intégré.
Apache : C’est un Serveur Web qui répond aux requêtes HTTP/HTTPS et sert des ressources
statiques (html,js,jpg,css….). Pour que Apache sert des ressources dynamiques on lui ajoute la
notion de Plugin ( Plugin php, plugin ajp Apache Java Protocole pour servir des jsp/Servlet ….)
Exemple d’Architecture distribuée hautement disponible et Résiliente
Conteneur WEB Conteneur EJB
API-REST/JSON
REST over HTTP

API-SOAP/XML

JMS ActiveMQ SpringBoot KAFKA v11 231220 202412

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

JMS ActiveMQ SpringBoot KAFKA v11 231220 202412

Transféré par

Droits d'auteur :

Formats disponibles

Middlewares Orientés Messages

Mise en œuvre de JMS

1. Architecture: Enterprise Application Integration(EAI)

2. Java Message Service (JMS):

3. Brokers : Active MQ / Rabbit MQ / KAFKA

▪ Plus de 11 000 organisations bancaires et de titres, infrastructures de marché et entreprises

MT202 General financial institution

▪ La communication Asynchrone MT3xx MT300 Foreign exchange confirmation

▪ La fiabilité et la garantie de transmission des MT5xx Securities Markets

MT9xx MT950 Statement

▪ L'intégration d'applications d'entreprise ou IAE est une architecture « inter-

gicielle » permettant à des applications hétérogènes de gérer leurs échanges, en

implémentant les flux inter-applicatifs du système d'information.

▪ L’EAI est un framework d'intégration composé d'un ensemble de technologies et

de services qui forment un middleware pour permettre l'intégration de systèmes et

d'applications dans une entreprise. On le place dans la catégorie des technologies

d'intégration métier (business integration) et d'urbanisation.

▪ L’EAI permet d’éviter les situations de type « spaghetti », une allusion à

l'équivalent en programmation du « code spaghetti ».

▪ « Enterprise Integration Patterns » est un livre de Gregor Hohpe et Bobby Woolf et

décrit 65 patterns pour l'utilisation de l'intégration d'applications d'entreprise et du

middleware orienté message.

▪ Le livre distingue 4 types d’intégration majeurs de premier niveau:

2. Base de données partagée

3. Invocation de procédure à distance

2. Channel : point-to-point ou de type publish/subscriber

3. Envoi bloquant ou asynchrone

▪ Communication asynchrone: La file d'attente reçoit le message de

▪ Routage: Les messages peuvent être routés entre MOM(s).

▪ Transformation des données: Les MOM permettent de changer le format

Les MOM ont deux modes de fonctionnement principaux :

qu'un message est lu, il est retiré de la file d'attente.

2. Publish-subscribe (par abonnement) : les applications consommatrices des

messages s'abonnent à un topic (sujet, catégorie de messages). Les messages

applications abonnées aient lu le message.

Structure d’un message JMS

Structure d’un message AMQP

HornetMQ (Jboss) Oracle WebLogic Server

OpenJMS (OpenJMS Group) SAP NetWeaver

* Open Message Queue (Open MQ): représente l'implémentation de référence pour la

(fournisseurs) sont implémentés sous la forme d'une implémentation Java JMS.

3. JMS Producer/Publisher: Un client JMS qui crée et envoie des messages.

4. JMS Consumer/Subscriber: Un client JMS qui reçoit des messages.

message n'est traité qu'une seule fois.

• Ce protocole est basé sur le concept de Queue de Messages, d’émetteurs et de receveurs.

2. La fabrique de connexions Factory :

▪ Un objet de type Factory produit une connexion permettant l'accès au broker.

▪ Il existe deux types de fabriques : QueueConnectionFactory et TopicConnectionFactory

▪ La fabrique de type ConnectionFactory permet d'obtenir une instance de l'interface

▪ Cette interface définit des méthodes pour la connexion au broker de messages.

▪ Cette connexion doit être établie en fonction du mode utilisé :

▪ l'interface TopicConnection pour le mode publication/abonnement

▪ La classe qui implémente cette interface se charge du dialogue avec le broker de

▪ La méthode start() permet de démarrer la connexion : connection.start();

▪ La méthode stop() permet de suspendre temporairement la connexion.

▪ La méthode close() permet de fermer la connexion.

▪ Représente un contexte transactionnel de réception et d'émission pour une connexion

▪ l'interface QueueSession pour le mode point à point

▪ l'interface TopicSession pour le mode publication/abonnement

▪ AUTO_ACKNOWLEDGE : l'accusé de réception est automatique, le MOM reçoit

▪ CLIENT_ACKNOWLEDGE : le MOM reçoit explicitement l'acquittement de la part de

▪ DUPS_OK_ACKNOWLEDGE : ce mode permet d'indiquer au MOM qu'il peut envoyer

• L'interface Session définit plusieurs méthodes dont les principales sont :