Cours Informatique Répartie

Enseignant : Malek BEN SALEM

[Link]@[Link]

1ème année Master Professionnel

Génie Logiciel
AU 2024/2025
1
 Plan du Cours

1. Chapitre 1 : Introduction à la répartition

2. Chapitre 2 : Les intergiciels orientés messages
3. Chapitre 3 : Architectures des Systèmes Répartis
4. Chapitre 4 : Communication dans les Systèmes Répartis
5. Chapitre 5 : Synchronisation et Coordination
6. Chapitre 6 : Cohérence et Réplication
17 7. Chapitre 7 : Tolérance aux Pannes
 Chapitre 2: Intergiciels orientés
messages (MOM)
Enseignant : Malek BEN SALEM
[Link]@[Link]

1ème année Master Professionnel

Génie Logiciel
AU 2024/2025
18
 Plan du Chapitre 2: Intergiciels
orientés messages (MOM)
1. Message Oriented Middleware – MOM

2. Java Message Service – JMS

3. Exemples de code (utilisant l’API JMS)

Note : Le contenu de ce chapitre est inspiré du cours de Ada Diaconescu,

« Fundamentals of Distributed Application Development », Telecom Paris, 2019.
Enseignant : Malek BEN SALEM
19 [Link]@[Link]
Motivation - Pour quoi les Messages? (1 /2)

RPC / RMI – Rappel :

• Couplage fort :
 Le client dépend de l’interface du serveur
 Le client doit « connaître » le serveur (Référence)
• Dépendance temporelle : Le client et le serveur doivent être
simultanément disponibles
• Communication synchrone/bloquante (habituellement) : Le client est
bloqué entre l’envoi de la requête et l’arrivée de la réponse
20
Motivation - Pour quoi les Messages? (1 /2)
Différentes applications ont des besoins et contraintes différents :
 Pas de disponibilité simultané : les différents composants de
l’application ne sont pas toujours disponibles simultanément (surtout dans les
applications réparties à grande échelle).
 Possibilité de communication asynchrone / non-bloquante: la
logique métier de l’application permet à un composant d’envoyer des
informations à un autre composant et de continuer son exécution sans
recevoir une réponse immédiate.
 Besoins d’un couplage faible : le développeur veut éviter qu’un
composant dépend de l’interface des autres composants ou même de
« connaître » les autres composants (Références directes) =>
remplacement facile
=> Communication par Message
21
Message Oriented Middleware (MOM)
 Proposent un modèle simple et fiable pour l’échange de
messages dans une application répartie

 Utilisent un des modèles de communication les plus anciens

 Sont utilisés dans les systèmes de grande dimension

 Réseaux bancaires
 Télécommunications
 Systèmes de réservation, commerce
 … etc.

22
 MOM - Caractéristiques
 Garantie de délivrance de messages
 Support des transactions
 Gestion du routage
 Passage à l’échelle
 Support pour la configuration (politiques de QoS : Quality of Service)
 Composants faiblement couplés (généralement !)
 Pas de dépendance d’interface
 Pas de référence directe
 Pas de dépendance temporelle – l’exécution de l’émetteur n’est pas
interrompue si le destinataire n’est pas disponible
 Communication asynchrone / non-bloquante (pas de réponse
implicite, sauf ack.)
23
 MOM – Architecture générale
Entités de base :
 Client – utilisateur du MOM
 Émission et réception de
messages
 Fournisseur – « provider »
 support du MOM : routage,
stockage des messages
 Message - support des données
transmises
 Type MIME - formats texte,
son, image, ..
 QoS - priorité, date de remise,
..
24 MIME: Multipurpose Internet Mail Extensions
 MOM : Communication par message
Vue d’ensemble – caractéristiques :
 Synchrone vs. Asynchrone
 Persistant vs. Transitoire
 Unicast vs. Multicast
 Mode « push » vs. « pull »
 Modèles de communication :
Requête/Réponse, Point à Point, Publication/Abonnement,..
 Systèmes de routage des messages
 Bibliothèque de traitement de messages
=> Plusieurs modèles de communication par message
 Implantant diverses combinaisons des aspects indiqués auparavant

25
 MOM: Communication par message
Communication synchrone vs. Asynchrone :

 Synchrone / bloquante
 L’émetteur reste bloqué jusqu’à ce que le destinataire acquitte la
réception du message (« Acknowledgement »)

 Asynchrone / non-bloquante
 L’émetteur continue de s’exécuter après avoir soumis le message
pour la transmission

26
 MOM : Communication par message
Données persistantes vs. transitoires :
 Communication persistante (« persistent »)
 Le serveur MOM conserve le message jusqu’à ce qu’il soit transmis
au récepteur; le message n’est jamais perdu ou effacé
 => pas de dépendance temporelle : l’émetteur et le récepteur ne
sont pas obligés d’être présents en même temps
 Communication transitoire (« transient »)
 Le serveur MOM conserve le message seulement pendant
l’exécution simultanée de l’émetteur et du récepteur
 => dépendance temporelle : l’émetteur et le(s) récepteur(s) doivent
être présents en même temps

27
 MOM : Communication par message
Unicast vs. Multicast :

 « Unicast » : Le message est envoyé à un seul destinataire

 « Multicast » - Diffusion (ou group) : Le message est distribué à

plusieurs destinataires

28
 MOM : Communication par message

Mode « push » vs. « pull »

 Mode « push »
 L’émetteur envoie le message au récepteur
 Ex. en appelant une méthode de « callback » du récepteur
 Mode « pull »
 Le récepteur va chercher le message chez l’émetteur
 Ex. :
o périodiquement;
o en restant bloqué jusqu’à ce qu’un message devient disponible;
o sur notification de l’émetteur (« push » et « pull »)

29
 Modèles de communication par message
msg.
 Point à Point (« Point to Point »)

req.
 Requête / Réponse
resp.

 Publication/Abonnement (« Publish/Subscribe ») msg.

topic

 …

30
Modèles de communication par message:
exemple 1
 Point-à-Point (“Point-to-Point” - 1 : 1)

 Chaque message est stocké dans une fille (« Queue ») jusqu’à ce que
le destinataire le lise
 Chaque message est consommé une seule fois (par un seul destinataire)
 Pas de dépendance temporelle entre émetteur et destinataire du
message
 Le destinataire peut acquitter les messages reçus

31
Modèles de communication par message:
exemple 2
 Publication/Abonnement (“Publish/Subscribe” - * : * )

 Le sujet (« Topic ») gère l’envoi de messages pour un ensemble de

lecteurs abonnés
 Découplage entre les « publishers » et les « subscribers » : les
fournisseurs n’ont pas besoins de connaître les consommateurs
 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.

32
 Topologies pour le Fournisseur de MOM
 Différentes topologies possibles pour le Message Broker
 Centralisée
 Décentralisée
 Hybride

 Chaque produit MOM peut utiliser une ou plusieurs topologies

33
MOM – topologie centralisée ( « hub &
spoke »)
 Serveur central de gestion de messages
 Routage, stockage, transactions, ..
 Avantage : Découple les clients, qui ne voient
que le serveur; l’ajout ou l’enlèvement d’un
client n’a pas d’impact sur les autres clients.
 Inconvénients
 Engendre un trafic réseau important
 Crée un goulot d’étranglement:
o Point unique d’échec (« unique point of
failure »)
o Problèmes de passage à l’échelle
34 o Possibilité de performance réduite (latence)
 MOM – topologie décentralisée
 Une instance de MOM est installé chez chaque Client - pas
de serveur central
 Stockage, transactions, sécurité, …
 Routage de messages
o Ad-hoc – entre les MOMs
o Basé sur le protocole réseaux existant - ex. IP-
Multicast
 Avantages
 Distribution des fonctions du MOM entre les
serveurs,ex. persistance, sécurité, …
 Inconvénients
 Problèmes potentiels d’interopérabilité – ex. différents
vendeurs ou versions de MOM
35
 Clients plus lourds, duplication des fonctions
 MOM – topologie hybride

 Combine les deux

architectures précédentes

 Combine les avantages et

les inconvénients

36
 MOM – exemple de topologie pour Joram
 Plusieurs Serveurs
 Chaque Client se connecte à un des Serveurs
 Chaque Client peut communiquer avec tout autre
Client, quel que soit le Serveur auquel ils se sont
connectés

37
 Paramètres de configuration du MOM
Administration du MOM : Configuration des clients :
 Déploiement  Point d’accès au MOM
 Position des nœuds  Authentification
 Allocation des ressources  Établissement de connexions
 Configuration des files de  Mode d’émission/réception des
messages messages
 Taille des files  Type de connexion
 Persistance  Priorités d’accès au MOM
 Filtrage des messages  Filtrage en réception
 Outils d’aide à
l’administration
38
 MOM – besoins de standardisation
 Un modèle de répartition - Une définition unique
« modèle de répartition fondé sur l’échange de messages entre les nœuds d’une
application répartie »
 Multiples solutions d’implantation
 Différentes sémantiques et services offerts

o Envoi « à l’aveugle » des messages ou support de l’acquittement;

support des transactions; …
o Gestion de la mobilité, support pour la reconfiguration dynamique, …

 Différentes architectures et implantations

o Communication à base de TCP/IP, IP multicast, SSL, HTTP, …

o Diverses implantations pour les files et les topics
39 o Diverses topologie supportées – centralisée, décentralisée, hybride
 MOM – besoins de standardisation
 => Besoins de standardisation

Ex: Java Message Service (JMS), OMG COS

Events/Notification, WS-Reliable Messaging, AMQP, …
 Jusqu’à ~2001, peu ou pas d’efforts de normalisation
 Une API par vendeur
 Conceptions différentes (ex. utilisation des ressources)
 Fonctionnalités différentes
 Difficultés
 Limitation de l’interopérabilité (critique)
 Problèmes de maintenance et d’évolutivité

40
 MOM - efforts de standardisation
 Évolutions

 Java Messaging Service (JMS) - une API standard pour le client

 CORBA COS Notification - une API pour le client, description de

l’infrastructure (objets et API)

 Advanced Message Queueing Protocol (AMQP) – un standard ouvert

pour l’interopérabilité d’intergiciels à message écrits en différents

langages et pour différentes plates-formes

…

41
 Spécification JMS: Java Message Service
 Spécification d’un API pour les MOM
 Intégré à J2EE 1.3 ++, couplage avec les EJB (Message-Driven Bean)
 Première spécification d’un MOM publiquement accessible
 Implémentée par les principaux MOM
 Adaptable à d’autres langages (C++, Ada)
 Peu restrictive: synthèse des MOM existants => autorise plutôt
qu’interdit
 Ne spécifie pas l’infrastructure
 JMS : spécification 2.0  Protocole, représentation,
 Spécification pour le client transport
 P-t-P, Pub/Sub, call-backs,  Processus de configuration
 Gestion des erreurs, de la
 Filtrage (syntaxe à la SQL) et reprise sur pannes
transactions  Interfaces d’administration
42
 Type de messages  Sécurité
 JMS Architecture
 JMS Client – utilise l’API JMS
 Pour envoyer/recevoir des
messages
 Pour les « Objets Administrés »
 JMS Provider – impl. l’API JMS
 Gestion des files et topics
 Transmission des messages
 Configuration globale du MOM
 Source d’hétérogénéité –
ex. mécanismes d’administration,
protocole utilisé, gestion des
erreurs, …
• Objets Administrés
 JMS Message – objets contenant  Fabriques de connections
l’information communiquée (« Connection Factories »)
 Un en-tête  Destinations: files et sujets
d’intérêt (« queues » et
 Des propriétés (optionnel)
43 « topics »)
 Un corps (optionnel)
 Message JMS (1)
 Trois parties: entête, propriétés, corps
 En-tête du message - identification et routage du message
De la forme Paires (nom, valeur) :
JMSDestination, JMSDeliveryMode, JMSMessageID, JMSTimestamp,
JMSExpiration, JMSRedelivered, JMSPriority, JMSReplyTo,
JMSCorrelationID, JMSType
 Propriétés (optionnel) – spécifiques à l’application, utilisées pour filtrer
les messages
Ex – sender : [Link](“Username”,”John Doe”);
Ex – receiver :
TopicSubscriber sub = [Link](chatTopic,
”Username!=‘William’ ” );//avec filtre!
44
 Message JMS (2)

 Corps (optionnel) - contient les données de l’application

Ex: [Link](MSG_TEXT + " " + (i + 1));
 TextMessage: chaîne de caractères
 MapMessage: ensemble de paires (nom, valeur)
 ByteMessage: flux d’octets
 StreamMessage: flux de valeurs
 ObjectMessage: objet sérialisable

45
 Réception de messages JMS
 Attention à l’utilisation des termes « synchrone »
& « asynchrone » !
 Réception Synchrone - mode « pull », bloquant
 Le consommateur récupère explicitement le message depuis la
Destination
en appelant la méthode receive.
 Cette méthode bloque jusqu’à ce qu’un message soit disponible,
ou qu’un délai expire.
 Réception Asynchrone – mode « push », avec dépendance temporelle
 Le consommateur enregistre un « Message Listener » auprès de la
Destination ciblée
 Lorsqu’un message arrive, le fournisseur JMS délivre le message au
46 « Message Listener » en appelant la méthode onMessage.
 Types de Destinations JMS
 File - « Queue »
 Persistance des messages
 Découplage temporel entre le producteur et le consommateur des
messages
 Habituellement utilisé pour la communication Point-à-Point
 Sujet - « Topic »
 Non-persistance des messages
 Couplage temporel entre le producteur et le consommateur des
messages
(sauf utilisation de l’option « durable subscription »)
 Habituellement utilisé pour la communication
Publication/Abonnement
 Note: JMS permet l’utilisation des deux types de destinations - queues et topics,
47
avec les deux modes de réception - synchrone et asynchrone.
 Modèles de communication JMS (1 /2)
 Point-à-Point :
 Chaque message est stocké dans une File jusqu’à ce qu’un destinataire
le lise (ou jusqu’à ce que le message expire)
 Chaque message est consommé une seule fois, par un seul destinataire
 Pas de dépendance temporelle entre l’émetteur et le destinataire du
message
 Le destinataire acquitte les messages reçus

48
 Modèles de communication JMS (2 /2)
 Publication / Abonnement
 Chaque message peut avoir plusieurs consommateurs
 Dépendance temporelle entre producteur et consommateur d’un message
o Consommateurs reçoivent seulement les messages produits après leur
souscription
o Consommateurs doivent rester disponibles pour recevoir des messages
o (les consommateurs peuvent créer des souscriptions « durables » afin
de relâcher cette contrainte)

49
 JMS Client :
Comment initialiser la communication ?
 Une Usine de Connexions –
« Connection Factory »
 Prend en charge la connexion avec le
fournisseur JMS (MOM).
 Encapsule les paramètres de connexion
mis en place par l’administrateur.
 Une Session
 Est un contexte mono-tâche
 Utilisé pour l'émission et la réception
de messages
 Gère plusieurs consommateurs et
producteurs de message Image from Oracle’s JMS tutorial
50 [Link]
JMS Client : Comment obtenir la Fabrique
de Connexions et les Destinations?
 L’administrateur du MOM:
 Crée les Objets Administrés : Usines de
Connections (FC) et Destinations (D)
 Ajoute les Objets Administrés dans
l’annuaire JNDI (opération bind) à
l’aide d’un Outil Administratif.
 Les Clients JMS:
 Utilisent l’annuaire JNDI afin d’obtenir
les Objets Administrés – FC, D
 Utilisent les Fabriques afin d’obtenir des
connections logiques au MOM Image from Oracle’s JMS tutorial
 Utilisent les Destinations afin [Link]
51
d’envoyer/recevoir des Messages
 JMS : Lien avec d’autres API Java
 JNDI (Java Naming and Directory Interface) est une API Java standard qui

permet aux applications Java de découvrir et d'accéder à des

ressources nommées dans service de répertoire ou serveur d'annuaire.

 Le contexte JNDI est une interface qui fournit une vue hiérarchique des

ressources enregistrées dans un répertoire.

 Dans une application JMS, JNDI est utilisé pour localiser et obtenir des

références aux objets nécessaires pour établir la communication avec un

broker JMS.

52
 JMS : Lien avec d’autres API Java
 Dans une application JMS, JNDI est utilisé pour localiser et obtenir des

références aux objets nécessaires pour établir la communication avec un

broker JMS. Cela inclut :

1. ConnectionFactory :

a. Un objet utilisé pour créer des connexions au broker JMS.

b. Enregistré dans le service de répertoire sous un nom logique.

2. Destinations (Queues/Topics) :

a. Objets qui représentent les files d'attente ou les sujets pour l'envoi
ou la réception de messages.
53
1. Également enregistrés dans JNDI sous des noms accessibles.
 Principaux Fournisseurs de JMS (1)
 Apache ActiveMQ: Probablement le MOM JMS open-source le plus

connu et le plus utilisé. Il offre une grande flexibilité, une haute

performance et supporte de nombreux protocoles.

 RabbitMQ: Un autre MOM open-source populaire, particulièrement

apprécié pour sa simplicité d'utilisation et son modèle de

publication/abonnement performant.

 HornetQ: Développé par Red Hat, il est un MOM JMS léger et

performant, souvent utilisé dans les environnements Jboss.

54
 Principaux Fournisseurs de JMS (2)
 IBM MQ: Un MOM commercial robuste et mature, offrant de nombreuses

fonctionnalités avancées et une intégration profonde avec l'écosystème IBM.

 Solace PubSub+: Un MOM cloud-native conçu pour les applications à

faible latence et à haut débit, souvent utilisé dans les environnements IoT.

55
 Tendances vis-à-vis MOM JMS (1)
Les MOM JMS répondent aux besoins des applications modernes:

 Cloud Native: Plus de MOM sont conçus pour fonctionner dans des

environnements cloud, avec des fonctionnalités de déploiement et de

gestion simplifiées.

 Streaming: Les MOM sont de plus en plus utilisés pour traiter des flux de

données en temps réel, grâce à des intégrations avec des outils de streaming
comme Apache Kafka.

 Microservices: Les MOM sont un élément clé des architectures de

microservices, permettant une communication décentralisée et asynchrone

56
entre les différents services.
 Démarche de développement avec JMS
1. Analyse des besoins
a. Identifier les cas d'utilisation de l'application répartie.
b. Déterminer les scénarios nécessitant une communication asynchrone
ou synchrone.
c. Décider des types de messages à utiliser : Point-to-Point (P2P) ou
Publish/Subscribe (Pub/Sub).
d. Analyser les performances et les contraintes de fiabilité (garantie de
livraison, persistance des messages, etc.).

57
 Démarche de développement avec JMS
2. Choix de la technologie JMS et des outils
a. Sélection du fournisseur JMS :
Choisir une implémentation de JMS comme ActiveMQ, RabbitMQ
(avec une passerelle JMS), IBM MQ, ou Apache Kafka.
b. Configurer l’environnement de développement :
- Intégration de l’implémentation JMS dans votre projet (par ex., via
des dépendances Maven/Gradle).
- Installer et configurer le serveur de messagerie (broker).

58
 Démarche de développement avec JMS
3. Conception de l’architecture de l’application
a. Modélisation des messages :
• Définir les formats des messages (JSON, XML, objets Java sérialisés).
• Identifier les attributs nécessaires.
a. Choix du mode de communication :
• P2P : utilisation de queues pour des communications directes
(exemple : traitement de commandes).
• Pub/Sub : utilisation de topics pour la diffusion de messages à
plusieurs consommateurs (exemple : notifications).
a. Fiabilité et transactions :
• Décider si les messages doivent être persistants ou non.
• Définir les besoins en transactions JMS (par ex., XA transactions).
59
 Démarche de développement avec JMS
4. Implémentation de l’application
a. Configuration initiale
• Configurer les connexions :
• Créer une ConnectionFactory pour établir des connexions au broker.
• Configurer les destinations (queues/topics).
• Définir un contexte JNDI si nécessaire (selon le fournisseur JMS).
b. Émission des messages (Producteur)
• Créer un producteur :
• Établir une connexion au broker via ConnectionFactory.
• Ouvrir une session (Session).
• Utiliser un producteur de message (MessageProducer) pour envoyer
des messages vers une destination.
60
 Démarche de développement avec JMS
b. Émission des messages (Producteur) : Exemple

61
 Démarche de développement avec JMS
c. Réception des messages (Consommateur)
• Créer un consommateur :
• Connecter à la même destination.
• Configurer un listener pour gérer les messages de manière
asynchrone, ou utiliser une réception synchrone.
• Exemple :

62
 Démarche de développement avec JMS
d. Gestion des erreurs et de la fiabilité
• Implémenter des mécanismes de confirmation de réception
(acknowledgment).
• Configurer des Dead Letter Queues pour les messages non livrables.
e. Déploiement
• Déployer le broker JMS sur une infrastructure appropriée (local, cloud
ou conteneurs Docker).
• Déployer les composants producteurs et consommateurs sur les
différentes instances de l'application.
f. Gestion de la qualité de service : QoS
• Configurer des outils de monitoring pour le broker JMS (exemple :
JMX pour ActiveMQ).
• Analyser les métriques : Latence des messages, Taux de traitement, Taux
63 d’erreurs.
 Exemples de code avec l’API JMS
Les Exemples
 # 1: JMS Sender

 # 2: JMS Receiver

 # 3: JMS Publisher

 # 4: JMS Listener

64
 Exemple JMS: Point-à-Point #1 (1/4)
Sender
import [Link].*;
import [Link].*;
public class SimpleQueueSender {
public static void main(String[] args) {
String queueName = null;
Context jndiContext = null;
QueueConnectionFactory queueConnectionFactory = null;
QueueConnection queueConnection = null;
QueueSession queueSession = null;
Queue queue = null;
QueueSender queueSender = null;
TextMessage message = null;
final int NUM_MSGS;
final String MSG_TEXT = new String("Here is a message");
Properties env = new Properties();
// Specify the vendor-specific JDNI properties

65
 Exemple JMS: Point-à-Point #1 (2/4)
Sender
queueName = “Test Queue”;
//Create a JNDI InitialContext object
try {

jndiContext = new InitialContext(env);

}
catch (NamingException e) {
[Link]("Could not create JNDI " +
"context: " +
[Link]());
[Link](1);
}

66
Exemple JMS: Point-à-Point #1 (3/4)
Sender
//Look up the connection factory and the queue
//If either does not exist Then exit
try {
queueConnectionFactory = (QueueConnectionFactory)
[Link]("QueueConnectionFactory");

queue = (Queue)[Link](queueName);

}
catch (NamingException e) {
[Link]("JNDI lookup failed: " +
[Link]());
[Link](1);
}
67
 Exemple JMS: Point-à-Point #1 (4/4)
Sender
try {
queueConnection =
[Link]();

queueSession = [Link](false,
Session.AUTO_ACKNOWLEDGE);

queueSender = [Link](queue);
message = [Link]();
for (int i = 0; i < NUM_MSGS; i++) {
[Link](MSG_TEXT + " " + (i + 1));
[Link]("Sending message: "
+ [Link]());
[Link](message);
}
}
catch (JMSException e) {
[Link]("Exception occurred: " + [Link]());
}

68
 Exemple JMS: Point-à-Point #2 (1/4)
Receiver
import [Link].*;
import [Link].*;

public class SimpleQueueReceiver {

public static void main(String[] args) {
String queueName = null;
Context jndiContext = null;
QueueConnectionFactory queueConnectionFactory =
null;
QueueConnection queueConnection = null;
QueueSession queueSession = null;
Queue queue = null;
QueueReceiver queueReceiver = null;
TextMessage message = null;

Properties env = new Properties();

// Specify the vendor-specific JDNI properties

69
Exemple JMS: Point-à-Point #2 (2/4)
Receiver
queueName = “Test Queue”;
//Create an JNDI InitialContext object
try {

jndiContext = new InitialContext(env);

}
catch (NamingException e) {
[Link]("Could not create JNDI " + "context: "
+
[Link]());
[Link](1);
}

70
 Exemple JMS: Point-à-Point #2 (3/4)
Receiver
//Look up connection factory and queue
//If either does not exist Then exit
try {
queueConnectionFactory = (QueueConnectionFactory)
[Link]("QueueConnectionFactory");

queue = (Queue) [Link](queueName);

}
catch (NamingException e) {
[Link]("JNDI lookup failed: " + [Link]());
[Link](1);
}

71
 Exemple JMS: Point-à-Point #2 (4/4)
Receiver
try {
queueConnection =
[Link]();

queueSession = [Link](false,
Session.AUTO_ACKNOWLEDGE);

queueReceiver = [Link](queue);

[Link](); //!!!
while (true) {
Message m = [Link](1);//timeout = 1ms
if (m != null) {
if (m instanceof TextMessage) {
message = (TextMessage) m;
[Link]("Reading message: " +
[Link]());
}
}
catch (JMSException e) {
[Link]("Exception occurred: " + [Link]());
}

72
 Exemple JMS: Pub/Sub #1 (1/4)
Publisher
import [Link].*;
import [Link].*;
public class SimpleTopicPublisher{
public static void main(String[] args) {

String topicName = null;

Context jndiContext = null;
TopicConnectionFactory topicConnectionFactory =
null;
TopicConnection topicConnection = null;
TopicSession topicSession = null;
Topic topic = null;
TopicPublisher topicPublisher = null;
TextMessage message = null;
final int NUM_MSGS;
final String MSG_TEXT = new String("Here is a
message");
Properties env = new Properties();
// Specify the vendor-specific JDNI properties

73
 Exemple JMS: Pub/Sub #1 (2/4)
Publisher
topicName = “Test Topic”;

//Create a JNDI InitialContext

try {

jndiContext = new InitialContext(env);

}
catch (NamingException e) {
[Link]("Could not create JNDI " + "context: "
+
[Link]());
[Link](1);
}

74
Exemple JMS: Pub/Sub #1 (3/4)
Publisher
//Look up connection factory and topic
//If either does not exist Then exit
try {

topicConnectionFactory = (TopicConnectionFactory)
[Link]("TopicConnectionFactory");

topic = (Topic) [Link](topicName);

} catch (NamingException e) {
[Link]("JNDI lookup failed: " + [Link]());
[Link](1);
}
 Exemple JMS: Pub/Sub #1 (4/4)
Publisher
try {
topicConnection =
[Link](user,pswd);
topicSession = [Link](false,
Session.AUTO_ACKNOWLEDGE);
topicPublisher = [Link](topic);
message = [Link]();

for (int i = 0; i < NUM_MSGS; i++) {

[Link](MSG_TEXT + " " + (i + 1));
[Link]("Publishing message: " +
[Link]());
[Link](message);
}
} catch (JMSException e) {
[Link]("Exception occurred: " + [Link]());
}

76
 Exemple JMS: Pub/Sub #2 (1/5)
Subscriber
import [Link].*;
import [Link].*;
public class SimpleTopicSubscriber{
public static void main(String[] args) {

String topicName = null;

Context jndiContext = null;
TopicConnectionFactory topicConnectionFactory =
null;
TopicConnection topicConnection = null;
TopicSession topicSession = null;
Topic topic = null;
TopicSubscriber topicSubscriber = null;
TextMessage message = null;
final int NUM_MSGS;
final String MSG_TEXT = new String("Here is a
message");
Properties env = new Properties();
// Specify the vendor-specific JDNI properties

77
Exemple JMS: Pub/Sub #2 (2/5)
Subscriber
topicName = “Test Topic”;

//Create a JNDI InitialContext

try {

jndiContext = new InitialContext(env);

}
catch (NamingException e) {
[Link]("Could not create JNDI " + "context: "
+
[Link]());
[Link](1);
}
 Exemple JMS: Pub/Sub #2 (3/5)
Subscriber
//Look up connection factory and topic
//If either does not exist Then exit
try {

topicConnectionFactory = (TopicConnectionFactory)
[Link]("TopicConnectionFactory");

topic = (Topic) [Link](topicName);

} catch (NamingException e) {
[Link]("JNDI lookup failed: " + [Link]());
[Link](1);
}

79
Exemple JMS: Pub/Sub #2 (4/5)
Subscriber
try {
topicConnection =
[Link](user,
psswd);

topicSession = [Link](false,
Session.AUTO_ACKNOWLEDGE);

topicSubscriber = [Link](topic);

topicListener = new TextListener();

[Link](topicListener);

[Link](); //!!!

[Link]("To end program, enter Q or q, " +

"then <return>");
//Read user input, exit when Ctrl+C entered
 Exemple JMS: Pub/Sub #2 (5/5)
Subscriber - TextListener
import [Link].*;
public class TextListener implements MessageListener {
public void onMessage(Message message) {
TextMessage msg = null;
try {
if (message instanceof TextMessage) {
msg = (TextMessage) message;
[Link]("Reading message: "
+
[Link]());
}
else { [Link]("Message of wrong
type: "
+ [Link]().getName());
}
}
catch (JMSException e) {
[Link]("JMSException in
onMessage(): " + [Link]());
}
}
}
81
Conclusion : Acteurs et utilisation
 Nombreux produits  Utilisation

 IBM WebsphereMQ (MQSeries)  Grands systèmes d’information - utilisateurs

 SonicMQ ( Progress Software) ‘historiques’
 BEA WebLogic ( Oracle)  ex: banque, assurance
 Microsoft Message Queuing  Passage à l’échelle nécessaire
(MSMQ)
 Amazon Simple Queue Service  EAI (Enterprise Application Integration)
(SQS)  Intégration de systèmes existants
 Joram ( ScalAgent)  Connexion à des bases de données
 ~ZeroMQ (pas un MOM)  Gestion aisée de plusieurs protocoles
 …
 …

82
 Conclusion : Acteurs et utilisation

 Les MOM sont

 ~ Faciles à implémenter
 ~ Faciles à déployer
 ~ Très configurables
 ~ Passent à l’échelle

 MAIS
 Restent des boîtes à outils
 Complexes à utiliser

83
 Conclusion : Autres exemples d’outils
pour la communication par message

 Sockets
 MOM
 Autres approches – ex. ZMQ (Zero MQ), Akka, …

84
 Plan du Cours

1. Chapitre 1 : Introduction à la répartition

2. Chapitre 2 : Les intergiciels orientés messages
3. Chapitre 3 : Architectures des Systèmes Répartis
4. Chapitre 4 : Communication dans les Systèmes Répartis
5. Chapitre 5 : Synchronisation et Coordination
6. Chapitre 6 : Cohérence et Réplication
85 7. Chapitre 7 : Tolérance aux Pannes