Introduction à RabbitMQ – AMQP Partie II

Nous avons vu dans le billet précédent un aperçu global du fonctionnement du protocole AMQP pour tout ce qui est échange de messages. Cette fois-ci nous allons voir plus en détail les possibilités offertes par le protocole comme l’authentification, la création de VHost et les détails des Exchanges et Queues.

Versions

Avant tout, pour que ce billet ait du sens, il faut savoir qu’il se base entièrement sur la version 0.9.1 du protocole, sortie le 13 novembre 2008; cette version est celle implémentée actuellement dans RabbitMQ.
La spécification étant relativement jeune, des changements sont amenés au cours du temps, et une version 1.0 en cours de rédaction apporte des modifications majeures. Vous pouvez consulter les évolutions du protocole sur le draft de spécification.
Concernant la version 0.9.1, la spécification étant succincte, 40 pages en tout, dont une vingtaine qui sont intéressantes pour une approche uniquement fonctionnelle du protocole, je vous invite à la lire sur le site de AMQP.

Authentification

Comme nous avons pu voir précédemment, la première étape utilisée afin d’envoyer un message, est la connexion de l’utilisateur sur le broker.
Afin de travailler dans un environnement sécurisé et contrôlable, AMQP impose à tous les utilisateurs d’être authentifiés.
Un simple couple user/password est envoyé à la connexion permettant ainsi d’identifier l’auteur de chaque message transitant par le broker.
Il est possible selon l’implémentation du protocole d’appliquer un système de sécurité et de rôles aux différents utilisateurs pour autoriser ou non l’accès aux différents éléments disponibles dans le broker (Queues/Exchanges).
L’avantage évident de ce système est la sécurité offerte pour les messages et leurs destinataires qui pourront être sûr de la provenance des données. Cependant, ceci nécessite une opération de la part de l’administrateur du broker pour créer et autoriser de nouveaux utilisateurs pour chaque application se connectant.

VHost

Une fois authentifié sur le broker, il est demandé à l’utilisateur de choisir un VHost sur lequel travailler.
La fonctionnalité de VHost (hôte virtuel) sur AMQP consiste à offrir la possibilité d’héberger plusieurs “domaines” distincts sur une même infrastructure.
Chaque domaine possède ses propres Queues/Exchanges/Bindings, de cette manière il est possible de déployer deux domaines différents en évitant de multiplier le nombre de processus lancés ou le nombre de serveurs utilisés; dans le même temps les deux domaines étant distincts le système n’est pas prévu dans l’optique d’échanger des données entre les deux ou d’accéder à l’un depuis l’autre.
En tant que client, le changement de VHost nécessite l’ouverture d’une nouvelle connexion vers le broker.
Un autre avantage de cette vision par VHost est que la base d’utilisateurs est partagée au travers de tous les domaines d’un même broker, il n’est donc pas nécessaire de recréer tous les utilisateurs en cas de nécessité d’un nouveau domaine parallèle au premier déjà existant.

Exchanges

Une fois connecté et identifié et après avoir choisi un VHost, l’utilisateur aura la possibilité d’interagir avec les Exchages. Tel que vu précédemment, un Exchange sera le point d’entrée utilisé pour envoyer des messages.
Les Exchanges possèdent en plus d’un mode d’utilisation, vu dans la première partie, d’autres propriétés et particularités pour permettre un maximum de modularité.

Propriétés

Un Exchange devra avoir un nom qui permettra au client d’identifier l’Exchange sur lequel il souhaite déposer ses messages. Il s’agit d’une simple chaîne de caractère unique spécifiée lors de l’envoi d’un message.
Une durée de vie de l’Exchange doit être définie, ceci permet de spécifier si et quand est-ce que l’Exchange doit-être supprimé du broker.
Trois niveaux sont proposés :

• Temporary : L’Exchange sera utilisable tant que le broker n’a pas été arrêté. En cas de redémarrage l’Exchange est détruit.
• Auto-delete : L’Exchange est détruit dès lors qu’il n’est plus utilisé.
• Durable : L’Exchange est toujours disponible. En cas redémarrage du broker, l’Exchange est toujours disponible.

Enfin le type d’un Exchange permet de définir le système utilisé pour dispatcher les messages sur les Queues appropriées. Les modes direct, fanout et topic (voir Introduction à RabbitMQ – AMQP Partie I) sont décrits dans la spécification et sont donc standards à AMQP.
Selon le choix fait ici il sera possible d’utiliser les binding-keys et routing-keys, avec ou sans wildcards.
Attention ! le mode topic, même s’il est défini au niveau de la spécification n’est pas obligatoirement disponible dans le broker. Direct et fanout sont par contre obligatoirement présents.
Il est aussi possible dans une perspective de personnalisation de créer un tout autre type d’Exchange personnalisé, dans une implémentation du broker, basé sur d’autres facteurs, il suffira de spécifier le bon type lors de la création de l’Exchange.

Création

Bien que généralement créé par un administrateur, les Exchanges peuvent être déclarés par les utilisateurs. Le système propose même une solution permettant d’accéder a un Exchange, et s’il n’existe pas de le créer dans la foulée.
Par défaut le système propose aussi un Exchange direct sans nom dont les messages seront transférés selon les Queues existantes.
Un message envoyé sur cet Exchange (qui ne possède pas de nom) se verra transféré sur la Queue dont le nom correspond à la routing key du message.
Avec ce mécanisme automatique, une personne peut envoyer facilement un message sans avoir à se soucier des principes d’Exchanges/Queues/Bindings.
Le broker fournira en plus, par défaut, un Exchange de chaque type, ce qui dans un cas courant permet de ne gérer que de la partie Queues et Bindings en laissant les clients se connecter sur les Exchanges pré-existants. Les noms de ces Exchanges par défaut sont définis sous la forme de amq.direct, amq.fanout et amq.topic.

Queues

L’autre entité habituellement manipulée est la Queue, celle-ci permet de stocker dans un ordre précis les messages envoyés au fur et à mesure du temps.
Une fois que le message est récupéré, il n’est plus disponible et ne pourra être relu*, et c’est le suivant disponible sur la Queue qui est mis à disposition.
Les Queues fonctionnent sur la base d’un système FIFO (First In First Out), mais il n’est pas obligatoire (bien que recommandé) que cet ordre soit respecté. Par exemple l’affectation d’un système de priorité dans les messages peut interférer avec le fonctionnement classique.
Tout comme les Exchanges, les Queues peuvent être personnalisées via des propriétés.
(*) Exception faite d’un problème durant le transfert du message, celui-ci sera considéré comme “non lu” par le broker.

Propriétés

Très proche du système d’Exchange par rapport aux propriétés, une Queue possédera elle aussi un nom utilisable par le client pour obtenir les messages auprès d’une Queue spécifique.
La durée de vie d’une Queue a aussi beaucoup d’importance. Lorsqu’une Queue est détruite, tout son contenu, c’est-à-dire les messages non lus, sont eux aussi détruits. Les trois durées de vie sont :

• Temporary : La Queue et ses messages seront stockés jusqu’à l’arrêt du broker.
• Auto-delete : La Queue et son contenu sont détruits dès lors qu’il n’y a plus d’utilisateurs connectés à la Queue.
• Durable : La Queue est conservée, même après un redémarrage du broker.

Une Queue a aussi la possibilité d’être exclusive ou shared, ceci permet respectivement d’empêcher ou d’autoriser un autre utilisateur à connecter sur la Queue.
Une Queue exclusive a automatiquement une durée de vie d’auto-delete.

Création

Les Queues peuvent être gérées par les utilisateurs directement.
Étant donné que le système est forcément authentifié, AMQP permet aux utilisateurs (dans le respect des droits qui leur sont attribués), de créer eux-même des Queues en choisissant leur fonctionnement, ainsi qu’en appliquant des Bindings avec les Exchanges déjà existants.
De la même manière un utilisateur peut supprimer une Queue ou les Bindings associés.
Le but ici est de permettre aux différents utilisateurs de greffer leurs propres listes de réception et mettre en place un mapping adapté à leurs besoins sur le système déjà existant tout en évitant la nécessité d’une intervention administrative.
Lorsqu’une Queue est créée, il est possible de lui attribuer un nom automatiquement généré pour éviter d’écraser un nom déjà utilisé. En règle générale une queue exclusive à un nom auto-généré.

Implémentations d’AMQP

Broker

Il existe énormément de choix concernant le broker AMQP.
Parmi les plus communs :

• RabbitMQ – Par VMWare, écrit en erlang
• Apache Qpid – Par Apache, écrit en C++/Java
• OpenAMQ – Par iMatix, écrit en C
• Red Hat Messaging Realtime and Grid – Par Red Hat, basé sur Apache Qpid

Dans les prochains billets nous allons voir plus en détail RabbitMQ les possibilités qui sont offertes spécifiquement par cette implémentation.

Client

Généralement chaque implémentation d’AMQP fourni sa propre librairie cliente qui fonctionnera avec n’importe quel broker. Mais en plus, de par sa nature orientée interopérabilité, AMQP possède une liste assez conséquente de clients disponibles dans la plupart des langages de programmation. Le protocole étant lui-même assez simple, il est relativement facile de créer un client basique pour n’importe quel langage.
Liste de clients AMQP (non exhaustive)
Par la suite nous utiliserons le client java fourni par RabbitMQ au travers de l’API Spring-AMQP.

Conclusion

Après maintenant une découverte plus poussée d’AMQP, nous allons passer à l’utilisation réelle d’une implémentation via RabbitMQ, voir certaines spécificités de ce broker, comment l’installer, l’administrer.