• Lancement du serveur RabbitMQ
• Exercice 1 : exemple d'un programme RabbitMQ avec filtrage
• Exercice 2 : premier programme RabbitMQ avec Java
• Exercice 3 : sérialisation/désérialisation
• Exercice 4 : design-pattern scatter/gather
• Exercice 5 : design-pattern pooling statique
• Exercice 6 : design-pattern RPC
• Exercice 7 : contrôle de la perte de message
• Exercice 8 : design-pattern pooling dynamique
• Exercice 9 : design-pattern TMR
• Installer RabbitMQ pour faire tourner le TP ailleurs
• Corrections

Lancement du serveur RabbitMQ

Dans un premier temps, il est nécessaire de mettre en place l'environnement pour l'utilisation de RabbitMQ avec java. Pour ce faire, il faut :

1. Démarrer le serveur RabbitMQ
2. Modifier votre environnement de travail afin d'utiliser le compilateur Java et les bibliothèques associées permettant d'écrire et exécuter des clients pour le serveur.

1. Sur les machines du réseau enseignement, le plus simple et de lancer le script
   

   		./docker_rabbit.bash
   		

   qui va lancer un serveur via un container docker.
2. Sur une machine Linux de type Ubuntu ou debian, il est possible d'installer les paquetages suivants :
   
   

   		sudo apt-get install rabbitmq-server
   		sudo rabbitmq-plugins enable rabbitmq_management
   		

   Le serveur RabbitMQ est alors lancé automatiquement au démarrage de la machine.
3. Sur la machine virtuelle distribuée pour l'UE SOR, rabbitmq est déjà installé et automatiquement lancé.

• Un premier port pour recevoir les messages AMQP (souvent port 5672, à vérifier selon la configuration du serveur).
• Un deuxième port pour la supervision du serveur (souvent port 15672, à vérifier également).

• Login: guest
• Password: guest

1. Par exemple, lancer firefox en ouvrant l'URL http://localhost:PPPP où PPPP est le numéro de port associé au service de supervision.
2. Et connectez vous au serveur avec un login/password comme celui donné ci-dessus.

Exercice 1 : exemple d'un programme RabbitMQ avec Java

L'objectif de cet exercice est de vous montrer comment créer une application avec RabbitMQ. Nous utiliserons des clients Java pour ce faire.

Afin de pouvoir compiler les clients Java et utiliser les jar associés, récupérer le fichier rabbit.bash et appliquer la commande suivante :

source rabbit.bash

make

java Subscriber paul 'legumes.*' &
java Subscriber jacques legumes.tomate &
java Subscriber eric legumes.radis legumes.tomate &

java Publisher legumes.radis coucou1
java Publisher legumes.tomate coucou2 
java Publisher plouf coucou3

Publisher : legumes.radis coucou1
Subscriber paul recoit legumes.radis : coucou1
Subscriber eric recoit legumes.radis : coucou1
Publisher : legumes.tomate coucou2
Subscriber paul recoit legumes.tomate : coucou2
Subscriber eric recoit legumes.tomate : coucou2
Subscriber jacques recoit legumes.tomate':'coucou2
Publisher : plouf coucou3

1. Indiquez les messages reçus par chaque processus.
2. Pourquoi le message coucou3 n'est pas reçu ?
3. Le programme qui lit les messages utilise-t-il des communications en mode push ou en mode pull ?
4. Quel est le nom de l'exchange utilisé pour ces communications ?
5. Quelles commandes contient le script stop.sh ?
6. Lancer les 2 programmes selon plusieurs scénarios et naviguer dans l'interface d'administration pour voir l'effet de l'exécution de ces programmes.

Exercice 2 : premier programme RabbitMQ avec filtrage

Pour cet exercice, récupérez les fichiers à partir du répertoire EXO2 . Sauvez tous les fichiers dans un répertoire nommé EXO2. Compléter les programmes Lecteur_Depeche.java et Redacteur_Depeche.java de sorte que :

• Redacteur_Depeche.java envoit un message deux fois. Ce programme prends 3 paramètres : 2 noms de ville et 1 message à envoyer. Chaque nom de ville constitue une clef. Ce programme soit envoyer le message deux fois : le message doit être envoyé avec chacune des 2 clefs passées en argument.
• Lecteur_Depeche.java qui lit et affiche les messages pour une ville donnée. Ce programme ne prend qu'un paramètre : le nom de ville dont le lecteur souhaite recevoir les informations. Ici aussi, le nom de la ville est employé comme une clef. Le programme filtre donc les messages qui ne concerne pas le nom de la ville passé en argument.
• On vous donne un exemple d'utilisation avec le programme lance.sh qui doit générer le résultat suivant :
  
  

Exercice 3 : sérialisation/désérialisation

Pour cet exercice, récupérez les fichiers à partir du répertoire EXO3 . Sauvez tous ces fichiers dans un répertoire nommé EXO3.

RabbitMQ n'offre pas nativement de service assurant la transparence à l'hétérogénéité, ce qui nous allons explorer ici.

Dans cet exercice, on vous demande d'implanter une application composée de 4 programmes et dont le but est d'émettre, de filtrer et de transmettre des informations permettant de connaitre l'état d'un réseau de lignes de bus.

• Le programme Capteur.java produit et émet les messages vers le programme Filtrage.java. Le programme Capteur.java est employé pour signaler un événement sur une ligne de bus.
  
  Chaque message émis/reçu décrit un événement intervenu sur une ligne de bus ainsi que son impact sur la ligne en question. Chaque message contient 3 informations : le numéro de ligne de bus concerné, l'événement et l'état de la ligne. Les classes Evenement.java et Statut.java décrivent respectivement les événements possibles et l'état de la ligne après l'événement.
  
  
• Le programme Filtrage.java réceptionne les messages émis par Capteur.java et renvoie également différents messages vers les processus executant Usager.java et Atelier.java.
  
  
• Les programmes Usager.java et Atelier.java permettent de réceptionner les différents messages envoyés par Filtrage.java.

String s = Statut.Arret.name();

 String [] result = M.split("#");
 

1. Transférer le message sans le modifier vers les usagers et l'atelier.
2. Compter le nombre total de pannes, d'accidents et de travaux, puis envoyer à chaque nouvel événement la valeur de ces 3 compteurs à l'atelier. La structure de ce nouveau message ainsi que les méthodes pour le sérialiser/désérialiser doivent être implantés dans la classe Message_stat.java

• Lorsque le programme Usager.java est utilisé par un usager des bus, le programme ne réceptionne que les messages associés aux événements que l'usager souhaitent recevoir. L'événement constitue une clef pour Usager.java. En d'autres termes, chaque usager indique pour quels événements il souhaite obtenir les informations des lignes de bus.
  
  A titre d'exemple, le script lance.sh indique que usager1 souhaite recevoir les évenements Travaux et Accident alors que usager3 souhaite ne recevoir que les événements Panne.
• Le programme Atelier.java est utilisé doit recevoir tous les messages émis par Filtrage.java, et en particulier tous les événements.

Exercice 4 : design-pattern Scatter/gather

Pour cet exercice, récupérez les fichiers à partir du répertoire EXO4 . Sauvez tous ces fichiers dans un répertoire nommé EXO4.

1. Le programme Scatter.java pilote les calculs à réaliser par vague successive. Un vague consiste à envoyer un nombre à convertir vers chacun des 3 processus exécutant Traitement.java.
2. Une fois une vague lancée, Scatter.java attend d'être informé par Gather.java que la vague en cours est terminée avant d'envoyer la vague suivante, c-à-d envoyer 3 nouveaux entiers aux processus Traitement.java.
3. Chaque Traitement.java attend de recevoir un nombre à convertir. Sur réception d'un nombre, ce programme le convertit en binaire et envoie le résultat au programme Gather.java. Pour traduire un entier en binaire, Traitement.java applique cet algorithme:
   1. Le programme divise par 2 l'entier reçu et mémorise le reste (0 ou 1).
   2. Si le résultat de la division est supérieur à 1, le programme refait une division avec le dividende de la division précédente.
   3. Si le résultat de la division est inférieur ou égal à 1, alors le calcul est terminé et les différents 0 et 1 mémorisés pendant le calcul constituent la représentation binaire du nombre reçu.
4. Le programme Gather.java attend les 3 nombres convertis en binaire. Lorsqu'il reçoit un nombre en binaire, alors il l'affiche à l'écran. Lorsqu'il a reçu 3 nombres binaires, il affiche à l'écran que la vague actuelle est terminée, ce qui permet à l'utilisateur de Scatter.java de lancer la vague suivante.

121456
223065
4593687
954067
3485654
20976364
2305435
1203409
34356
66540
2234000
11333084

Exercice 5 : design-pattern pooling statique

L'objectif de cet exercice est d'implanter le patron de conception pooling. Dans cette première version, l'ordre d'utilisation des workers est statique.

Pour cet exercice, récupérez les fichiers à partir du répertoire EXO5 . Sauver tous les fichiers dans un répertoire nommé EXO5.

1. Dans cet exercice, le pool comporte 3 workers. Chaque worker à un nom unique servant de clef pour les communications et exécute le programme Worker.java.
2. Dispatcher.java pilote les calculs réalisés par le pool. A titre d'exemple, nous reprennons la traduction des nombres décimaux en binaire. Dispatcher.java maintient la liste des workers actifs et les invoque successivement dans un ordre prédéterminé grâce à la classe Pool.java.
3. Le nom de chaque worker est donné dans le fichier lance.sh: les noms sont work1, work2 et work3.
4. Dispatcher.java répartie les requêtes vers les workers selon un algorithme de round-robin. Il peut également décider de retirer un worker de pool. Dispatcher.java peut donc envoyer 2 types de requetes à un worker: 1) soit une demande pour convertir un nombre en binaire 2) soit une demande afin pour que le worker quitte le pool et donc arrête de fonctionner.
5. Les workers attendent les requêtes de Dispatcher.java. Lorsqu'une requête est reçue par un worker, il l'exécute. Si la requête est une demande de convertion, alors il calcule cette conversion, affiche le résultat et attend la requête suivante. Si la requête est une demande de retrait du pool, alors le worker stoppe son exécution.

Exercice 8 : design-pattern pooling dynamique

1. Récupérer les fichiers à partir du répertoire EXO8 . Sauver tous les fichiers dans un répertoire nommé EXO8. Copier les fichiers Pool.java, Dispatcher.java et Worker.java que vous avez implantés pour l'exercice 5.
2. Modifier Pool.java en ajoutant deux méthodes pour sérialiser et désérialiser le tableau utilisé pour ordonnancer les workers.
3. Implanter la classe Update_Pool.java qui définit avec Pool.java un nouvel ordonnancement des workers, le sérialise puis l'envoie à Dispatcher.java
4. Vérifier que Dispatcher.java reçoit bien le nouvel ordonnancement et active effectivement les workers selon l'ordre défini par Update_Pool.java

Exercice 9 : design-pattern TMR

L'objectif de cet exercice est de mettre en oeuvre un exemple du patron TMR (Triple Modular Redundancy). Nous allons procéder en 2 temps, ou 2 questions. Dans la première question, on implante le mécanisme de vote permettant de recouvrir une perte de message ou des données produites par des programmes byzantins. Dans la seconde question, on adapte la solution précédente afin de déployer l'application sur deux serveurs RabbitMQ/machines afin de recouvrir une panne franche du serveur.

Question 1 :

Tout d'abord, récupérer les fichiers à partir du répertoire EXO9Q1 . Sauver tous les fichiers dans un répertoire nommé EXO9Q1.

• Chaque capteur envoye les informations au voteur afin d'y appliquer le mécanisme de TMR. L'information est une valeur numérique entière issue d'une mesure assurée par un périphérique par exemple. On suppose que cette mesure est réalisée par trois équipements différents et conduit donc 3 processus capteurs à transmettre leur mesure au voteur.
• Chaque capteur numérote ses mesures et le numéro de mesure est transmis avec la mesure au voteur. La classe Message_donnee.java peut être utilisée pour sérialiser/désérialiser les messages échangés entre les capteurs et le voteur.
• Les numéros de mesure commencent à 1. Initialement, le voteur est donc en attente des mesures dont le numéro est 1.
• Lorque le voteur a reçu les 3 mesures pour le numéro de mesure attendu, alors il applique le vote et affiche les résulats du vote. Afficher le résultat du vote consiste à afficher 1) la valeur la plus fréquente 2) le nombre de valeurs différentes. Une fois l'affichage réalisé, il commence à attendre le numéro suivant.
• Lorsque le voteur est en attente des mesures pour le numéro n et qu'il reçoit une mesure numéro k tel que k>n, alors : 1) il arrête d'attendre les mesures numéro n qui sont considérées comme perdues, 2) il applique le vote sur les mesures n éventuellement reçues et affiche le résultat du vote, 3) il affiche le nombre de mesures n manquantes, 4) il se met en attente des mesures k suivantes.
• Lorsque le voteur est en attente des mesures pour le numéro n et qu'il reçoit une mesure dont le numéro est inférieur à n, alors il ignore le message/la mesure reçu.

Implanter le mécanisme de vote et tester le avec les scripts lance.sh et capteur.sh.

capteur.sh vous permettra de tester quelqu'unes des règles ci-dessus mais il ne faut pas hésiter à le compléter si cela est nécessaire.


Question 2 :




L'objectif de cette deuxième question est d'appliquer un mécanisme de redondance active pour les brokers cette fois-ci. Dans ce patron, comme indiqué dans la figure ci-dessus, 1 voteur est instancié sur 2 brokers différents. Toutefois pour ce TP, les 2 voteurs seront instanciés dans le même broker pour simplifier la mise en place du TP.

Récupérer les fichiers à partir du répertoire EXO9Q2 . Sauver tous les fichiers dans un répertoire nommé EXO9Q2.

Modifier votre application de la question 1 de sorte que :

1. Le programme Recepteur.java est instancié une fois.
2. Comme indiqué dans la figure ci-dessus, 2 voteurs sont instanciés.
3. Chacun des 3 processus capteurs envoient leur mesure à chacun des 2 voteurs.
4. Chaque voteur applique l'algorithme implanté dans la question 1 et transmet le résultat du vote au processus Recepteur.java Les voteurs n'affichent donc plus les résultats de vote mais les transmettent à Recepteur.java
5. Comme les voteurs, Recepteur.java est initialement en attente du résultat du vote pour le numéro de vote 1.
6. Lorsque Recepteur.java reçoit le résultat du vote pour le numéro de mesure attendu, alors il affiche le résultat et commence à attendre le numéro suivant.
7. Lorsque Recepteur.java est en attente du résultat du vote pour le numéro n et qu'il reçoit le résultat numéro k tel que k>n, alors : 1) il arrête d'attendre le résultat numéro n qui est considéré comme perdu, 2) affiche le résultat du vote k, 3) il se met en attente de résultat k+1.
8. Lorsque Recepteur.java est en attente des mesures pour le numéro n et qu'il reçoit une mesure dont le numéro est inférieur à n, alors il ignore le message/le résultat de mesure reçu.
9. Lorsque Recepteur.java a reçu le résultat pour le numéro n et qu'il reçoit le second résultat pour le numéro n, alors il ignore le dernier message/le résultat reçu.

Implanter cette seconde version du mécanisme de vote et tester le avec les scripts lance.sh et capteur.sh.

capteur.sh vous permettra de tester quelqu'unes des règles ci-dessus mais il ne faut pas hésiter à le compléter si cela est nécessaire.

Exercice 7 : contrôle de la perte de message

Pour cet exercice, récuperer les fichiers qui sont disponibles dans ce répertoire . Sauvez tous les fichiers dans un répertoire EXO7.

Dans cet exercice, on cherche à contrôler la perte de message, suite, par exemple, à l'arrêt d'un subscriber. On vous demande de réaliser une application permettant de gérer et contrôler des operations bancaires. L'application est composée des 3 programmes suivants :

• Le programme Web.java est un programme déclenché à chaque fois qu'un client de la banque demande une opération bancaire. A chaque fois qu'un utilisateur souhaite faire une opération de débit ou de crédit sur son compte bancaire, Web.java génère un message vers RabbitMQ. Chaque message est composé : 1) d'un numéro d'opération unique permettant d'identifier chaque opération ; 2) du numéro de compte concerné ; 3) du type d'opération qui peut être soit un débit soit un crédit ; 4) du montant (en euros) de l'opération. Chaque message est envoyée dans un exchange avec comme clef le numéro de compte. On remarque qu'au même instant, plusieurs programmes Web.java peuvent s'exécuter simultanément puisque plusieurs clients peuvent se connecter à leur banque simultanément.
  
  
• Le programme Compte.java gère un compte bancaire donné. Le programme lit depuis l'exchange tous les messages associés au compte qu'il gère : la clef constitue le numéro de compte associé au programme.
  
  Le rôle du programme Compte.java est de stocker dans un fichier texte chaque opération effectué sur le compte. Chaque opération est enregistrée sur une ligne du fichier texte. Chaque ligne dans le fichier contient également le solde du compte après applicationn de l'opération. On suppose qu'au lancement de Compte.java, le solde est égal à 0.
  
  Pour chaque message lu par Compte.java, le programme :
  1. Lit la dernière ligne du fichier texte afin de récupérer le solde du compte
  2. Calcule le solde du compte après application de l'opération contenue dans le message recu
  3. Puis stocke le message ainsi que le nouveau solde en ajoutant une ligne dans le fichier texte.
     
     Voici par exemple les messages produits par Web.java pour une opération de crédit et deux opérations de débit, pour respectivement 100 euros, -10 euros et -20. Ces trois opérations concerne le numéro de compte 1 (2ème champs du message). Le premier champs constitue le numéro d'opération (respectivement 1, 2 et 3 pour la dernière opération).

     tp@tphost:$java Web 1 1 credit 100
     Compte 1 recoit:1#1#credit#100
     tp@tphost:$ java Web 2 1 debit  -10
     Compte 1 recoit:2#1#debit#10
     tp@tphost:$ java Web 3 1 debit  -20
     Compte 1 recoit:3#1#debit#20
     

     Les 3 opérations conduisent à un fichier texte contenant 3 lignes. Chaque ligne contient l'ensemble des informations d'une opération ainsi que le solde actuel du compte. Ainsi, nous obtenons dans le fichier texte ci-dessous pour le compte numéro 1:

     1#1#credit#100#100
     2#1#debit#-10#90
     3#1#debit#-20#70
     

     Dans cet exemple de fichier, la 3ème ligne montre qu'après la 3ième opération (opération de débit de -20 euros) le solde du compte est de 70 euros. En effet, le 1er champs est le numéro d'opération. Le second champs est le numéro de compte. Le 3ème champs est l'opération. La 4ième champs est le montant de l'opération et le 5ième champs constitue le solde du compte bancaire. Pour les entrées/sorties sur fichier, vous pouvez utiliser le programme Linefile.java qui permet d'ajouter une ligne dans le fichier (méthode AppendLine), de lire la dernière ligne du fichier (méthode ReadLastLine) ou de lire l'intégralité du fichier ligne par ligne (méthode ReadAllLine).
  
  
  
• Le 3ième programme, Controleur.java gère la perte de message. On lance un programme Controleur.java pour chaque programme Compte.java. Le programme Controleur.java reçoit tous les messages à destinations du programme Compte.java.
  A chaque message reçu, Controleur.java, après une attente de 10 secondes, vérifie que l'opération associée au message a bien été réalisée en lisant le fichier texte associé. Si l'opération n'est pas présente dans le fichier texte, alors Controleur.java renvoit le message vers le serveur RabittMQ afin que Compte.java puisse réaliser l'opération perdue.

Question 1 :

Dans un premier temps, écrire les programmes Web.java et Compte.java. Tester que chaque opération bancaire envoyé par Web.java est bien enregistrée par Compte.java dans le fichier texte associé.



Question 2 :

L'objectif de la question 2 est maintenant d'implanter le controleur. Implanter le Controleur.java, puis, tester qu'en cas de panne de Compte.java, les messages de Web.java sont bien ré-injectés dans le serveur RabbitMQ quand ceux-ci n'ont pas pu être traités par Compte.java.

Exercice 6 : design-pattern RPC

Dans cet exercice, on illustre comment fonctionne un mini-broker d'objets répartis similaire à CORBA ou Java RMI. Ce mini-broker utilise RabbitMQ pour implanter les communications entre les clients et les serveurs qui hébergent les objets accessibles à distance.

Récupérer les fichiers de cet exercice à partir du répertoire EXO6 . Sauvez tous les fichiers dans un répertoire EXO6.


Question 1:

• Compiler, tester et étudier ces programmes.
• Chaque classe correspond à une entité CORBA. Dites pour chaque classe à quoi elle correspond dans CORBA.
• Comment sont véhiculés les requêtes du client au serveur ?

Question 2:

Le programme donné pour la question 1 ne comporte que le code nécessaire pour transmettre la requête du client vers le serveur. Avec cette première version, les objets ne peuvent pas retourner une réponse au client.

Pour cette question, nous vous donnons une nouvelle version de certains fichiers du mini-broker, fichiers qui sont disponibles dans ce répertoire EXO6Q2 . Sauvez tous les fichiers dans un répertoire EXO6Q2.

Modifier les autres classes Java constituant ce mini-broker afin de permettre à l'objet de transmettre une réponse au client via la souche et le squelette. Cette nouvelle version nécessite de mettre en place l'envoie d'un message constituant la réponse du serveur vers le client. Pour ce faire, vous aurez besoin d'un exchange supplémentaire entre l'ObjectAdapter et le Client.



Question 3:

Le programme précédent ne gère qu'un seul objet Calcul. On souhaite étendre ce programme afin de pouvoir manipuler plusieurs objets, c-à-dire plusieurs instances de la classe CalculImpl.java. Chaque objet est identifié par un identifiant unique. Au niveau de l'ObjectAdapter, chaque objet est associé à un thread (thread généralement appelé Servant) qui lit les requetes associées à l'objet et émet les réponses vers le client. Chaque objet doit utiliser une clef de filtrage dédiée.

Modifier les classes Java afin d'implanter cette nouvelle fonctionnalité. Pour tester, vous modifierai Server.java afin d'héberger 3 instances de CalculImpl. Pour tester, le client devra également être modifié.



©(Copyright) singhoff@univ-brest.fr