Spring-boot: RabbitMQ

On a jamais parler de Spring-boot [9], ça fait même assez longtemps que l’on a pas parler Java! Du coup comme nous sommes lancé dans les articles sur RabbitMQ et que ce message broker est assez courant dans ces écosystèmes, on va en profiter!

On va donc finir cette liste d’articles [2, 3] avec une mise en situation en réalisant une application client server implémentée avec Spring-boot (sur lequel nous reviendrons de façon plus général dans un autre article).

RabbitMQ : Configuration

Dans l’article précédent nous avions vu rapidement le fonctionnement de RabbitMQ [1]. Nous y avions vu comment le lancer dans un container Docker et de choisir quel type de binding et d’exchange utiliser selon nos besoins.

Par contre nous n’avions pas vu comment configurer de nouveaux exchanges, de nouvelles queues ou définir de nouveaux binding. Remédions à cela!

Pour réaliser une configuration, on peut utiliser l’interface web permettant de “jouer” et faire une config et des tests rapide. Par contre, il est évident que cela manque de reproductibilité. Il faut donc une approche et quelques outils.

RabbitMQ

Il y a deux ans nous avions parlé de JMS [1], et des principes et enjeux liés aux échanges de messages entre systèmes logiciels. Aujourd’hui je profite d'être sur un sujet très proche de JMS  pour écrire un petit article ce coup ci sur RabbitMQ [2].

Un message Broker

Qu’est ce que RabbitMQ? Il s’agit d’un message broker [4] qui à l'instar de JMS permet la réception et le dispatch de message au sein d’un système d’information.

De façon logique, on va donc retrouver comme dans JMS une logique de files auxquelles les applications vont devoir s’abonner. La différence dans RabbitMQ est que la gestion des messages n’est pas limitée autour de l’utilisation de files ou de topic mais autour de files configurable [5] selon différentes configurations auxquelles vont être associées des clefs de routages permettant la gestion de la diffusion des messages.