AMQP : présentation de l’Advanced Message Queuing Protocol

Il est impératif que les services puissent communiquer entre eux pour échanger des informations et transmettre des données. Contrairement à ce que l’on pourrait penser, c’est plus facile à dire qu’à faire, car les échanges entre différentes applications doivent surmonter plusieurs difficultés : le domaine informatique est lui aussi confronté aux barrières linguistiques (entre les différents langages de programmation) ce qui rend indispensable l’utilisation d’un protocole pour éviter que la communication ne se transforme en anarchie.

Une solution est offerte avec l’Advanced Message Queuing Protocol, abrégé en AMQP : un protocole global permettant de transporter les informations via un médiateur. Quel en est le fonctionnement ? Quels sont les plus d’AMQP ?

L’Advanced Message Queuing Protocol est développé depuis 2003 et constitue une exception puisque ce protocole n’est pas l’initiative d’une entreprise informatique comme à l’accoutumée. En effet, il a tout d’abord été développé par JPMorgan Chase, une banque américaine. Il fut alors décidé de poursuivre le développement du projet avec d’autres sociétés. Outre des entreprises informatiques comme Cisco, le protocole AMQP continue d’intéresser en premier lieu le secteur financier. Pourquoi cela ? Parce que pour la finance, le temps c’est de l’argent : pour une banque, une société de cartes de crédit ou une bourse, la transmission des informations joue un rôle prépondérant. Plusieurs centaines de milliers de messages y sont envoyés par seconde. En cas de retard ou d’absence de réception des messages, les coûts peuvent être considérables.

Puisqu’en 2003, aucun produit commercial n’était en mesure de satisfaire les exigences de la banque, elle a décidé (en la personne de son chef de projet John O’Hara) de développer son propre protocole. John O’Hara s’est appuyé sur les normes ouvertes comme TCP/IP et a fait le choix de mettre AMQP en libre accès afin d’accélérer le développement du protocole. Aujourd’hui, le développement du protocole a été confié à un groupe de travail OASIS (une organisation à but non lucratif).

AMQP résout plusieurs problèmes en même temps : ce protocole garantit d’une part une transmission des données fiable (à l’aide d’un message broker). D’autre part, l’AMQP permet de stocker des messages dans des files d’attente, permettant ainsi une communication asynchrone : l’émetteur et le destinataire n’ont pas à agir au même rythme. Le destinataire (consommateur) du message n’est pas obligé d’accepter directement l’information, de la traiter et d’en accuser réception auprès de l’émetteur (producteur). À la place, il va récupérer le message dans la file d’attente lorsqu’il en a la capacité. Le producteur peut ainsi continuer à travailler sans créer de période d’inactivité.

Le succès rencontré par ce protocole relativement récent lui vient également de son interopérabilité. L’Advanced Message Queuing Protocol établit à dessein une base commune qui permet même de publier les différentes applications dans des langages de programmation distincts. Les programmes de différentes organisations peuvent ainsi se comprendre sans difficulté. Et comme AMQP est en libre accès, chaque entreprise peut utiliser le protocole sans coûts supplémentaires.

Dans le modèle OSI, AMQP agit au niveau de la couche d’application : il est ainsi en contact direct avec les différents programmes. Les protocoles IMAP (pour les emails), FTP (pour la transmission de fichiers) et IRC (pour la messagerie instantanée) sont également actifs au niveau de cette couche. Pour transmettre les messages, le protocole s’appuie sur un médiateur appelé « message broker » (agent de messages). Ce dernier assure la distribution des messages aux différents destinataires selon des règles définies. AMQP règle également le comportement de ce serveur de transmission.

L’Advanced Message Queuing Protocol repose donc aussi bien sur la communication entre les différents participants que sur le comportement des brokers. Les instructions sont fournies à ces derniers dans les messages.

Dans l’univers d’AMQP, il existe trois acteurs et un objet :

• le message est l’élément central sur lequel repose toute la communication.
• Le producteur (Producer) procède à la création et à l’envoi du message.
• Le message broker distribue le message aux différentes files d’attente (Queue) selon des règles définies.
• Le consommateur (Consumer) récupère le message dans la file d’attente à laquelle il a accès et traite le message.

La transmission du message est à nouveau interrompue dans le message broker : l’Exchange réceptionne les messages et redirige les données vers la bonne file d’attente. L’Exchange sait dans quelle file d’attente le message doit être envoyé grâce au Binding. L’Exchange peut transmettre les messages de quatre façons différentes.

La première façon, le Direct exchange, envoie les messages à un destinataire précis en utilisant des « Routing keys » (« clés de routage »). Ces clés sont indiquées par le message. Les files d’attente disposent quant à elles d’une « Binding key » (« clé de liaison ») qui permet à l’Exchange d’identifier la « Queue ». Lorsque la Routing key et la Binding key correspondent, le message peut être transmis à la file d’attente et, à terme, au destinataire du message. Une Queue peut également disposer de plusieurs Binding keys et être utilisée pour plusieurs Routing keys. À l’inverse, plusieurs Queues peuvent également se partager une Binding key : c'est le « Multiple binding ». L’Exchange duplique le message et l’envoie à plusieurs destinataires.

Le « Fanout exchange » fonctionne de façon similaire. Cependant, le message broker ignore complètement la « Routing key » dans ce cas et l’Exchange redirige le message vers toutes les Queues disponibles en dupliquant les informations. Le « Topic exchange » fonctionne de façon différente. Comme avec le Direct exchange, la Routing key est comparée aux Binding keys, mais il n’est pas nécessaire qu’elles correspondent parfaitement. Ici, on utilise plutôt des balises afin de mettre les messages à disposition de plusieurs Queues de façon ciblée.

Finalement, l’Headers exchange utilise l’en-tête des messages à la place de la Routing key. Cet entête contient les valeurs qui seront comparées avec le Binding. L’argument avec la désignation x-match détermine si toutes les valeurs doivent correspondre (valeur : all) ou si une seule valeur doit correspondre au Binding (valeur : any). La première valeur correspond au Direct exchange et la seconde permet d’obtenir le même effet qu’un Topic exchange.

L’unité de base du protocole AMQP est la trame. Une connexion consiste en une séquence ordonnée de trames. On entend ici par « ordonnée » le fait que la dernière trame ne peut pas atteindre le destinataire avant que toutes les autres trames aient atteint leur destination. Chaque trame peut être divisée en trois segments (dans la version 1.0) :

• Frame header : cet entête obligatoire a une valeur de 8 bytes et contient les informations définissant le routage du message.
• Extended header : cette section est facultative et n’a pas de longueur fixe. Elle permet de compléter l’entête ultérieurement avec des informations supplémentaires.
• Frame body : le corps contient les données à transmettre à proprement parler. La taille du corps est libre. Cette section peut toutefois rester vide, auquel cas la trame a pour unique but d’établir la connexion.

Le corps d’une trame peut prendre à son tour neuf formes distinctes :

• open : négocie les paramètres de connexion entre le message broker et le client.
• begin : indique qu’une connexion est établie.
• attach : un lien nécessaire à l’utilisation du transfert de données est joint au message.
• flow : modifie le statut d’un lien.
• transfer : la trame « transfer » transmet le message à proprement parler.
• disposition : une trame de disposition fournit des informations sur les modifications apportées à la livraison des informations.
• detach : supprime le lien.
• end : indique que la connexion est terminée.
• close : met un terme à la connexion et indique que plus aucune autre trame ne doit être envoyée.

Chaque Queue dispose d’un nom propre permettant son identification par les autres participants. Cette désignation est définie par le client ou par le message broker. Une file d’attente est réalisée à l’aide d’une mémoire qui peut être placée sur un disque dur de façon permanente ou être volatile dans une mémoire vive. La variante permanente permet de garantir la conservation de la file d’attente en cas de redémarrage d’un message broker. Cependant, elle ne garantit pas que les messages seront également sauvegardés durablement : leur disponibilité après un redémarrage dépend du type de message.

Que se passe-t-il lorsqu’un Consumer ne peut pas consulter le message dans la file d’attente parce que le client ou la connexion a été interrompu(e) ? Il est possible de définir si un Consumer doit accuser réception d’un message par défaut ou si la livraison pure et simple suffit au succès. Dans le premier cas, si le Consumer ne renvoie aucun message, le message broker tente de renvoyer le message à un autre Consumer ou d’atteindre à nouveau le même destinataire. En revanche, si le Consumer ne consulte pas le message dans la variante sans accusé de réception, celui-ci est perdu.

Il est néanmoins possible qu’un client refuse pertinemment de recevoir un message. Cela peut s’avérer utile lorsque le traitement du message ne fonctionne pas. Le retour de la part du Consumer pousse le message broker à supprimer complètement le message ou à l’insérer à nouveau dans la file d’attente.

À l’heure actuelle, il existe deux versions entièrement indépendantes de l’Advanced Message Queuing Protocol. La version 1.0 est développée par le groupe OASIS. Dans le cas de RabbitMQ en particulier, la version 0-9-1, un peu plus ancienne, est toutefois utilisée. Les deux versions ne sont pas compatibles l’une avec l’autre. Dans la version 1.0, les message brokers, les Bindings et les Exchanges ont une moindre importance. La version 0-9-1 n’en a pas besoin, mais ne s’interdit pas pour autant d’utiliser ces médiateurs.