AMQP : pré­sen­ta­tion de l’Advanced Message Queuing Protocol

Il est impératif que les services puissent com­mu­ni­quer entre eux pour échanger des in­for­ma­tions et trans­mettre des données. Con­trai­re­ment à ce que l’on pourrait penser, c’est plus facile à dire qu’à faire, car les échanges entre dif­fé­rentes ap­pli­ca­tions doivent surmonter plusieurs dif­fi­cul­tés : le domaine in­for­ma­tique est lui aussi confronté aux barrières lin­guis­tiques (entre les dif­fé­rents langages de pro­gram­ma­tion) ce qui rend in­dis­pen­sable l’uti­li­sa­tion d’un protocole pour éviter que la com­mu­ni­ca­tion ne se trans­forme en anarchie.

Une solution est offerte avec l’Advanced Message Queuing Protocol, abrégé en AMQP : un protocole global per­met­tant de trans­por­ter les in­for­ma­tions via un médiateur. Quel en est le fonc­tion­ne­ment ? 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’ini­tia­tive d’une en­tre­prise in­for­ma­tique comme à l’ac­cou­tu­mée. En effet, il a tout d’abord été développé par JPMorgan Chase, une banque amé­ri­caine. Il fut alors décidé de pour­suivre le dé­ve­lop­pe­ment du projet avec d’autres sociétés. Outre des en­tre­prises in­for­ma­tiques comme Cisco, le protocole AMQP continue d’in­té­res­ser 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 trans­mis­sion des in­for­ma­tions joue un rôle pré­pon­dé­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 con­si­dé­rables.

Puisqu’en 2003, aucun produit com­mer­cial n’était en mesure de sa­tis­faire les exigences de la banque, elle a décidé (en la personne de son chef de projet John O’Hara) de dé­ve­lop­per 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é­ve­lop­pe­ment du protocole. Aujourd’hui, le dé­ve­lop­pe­ment du protocole a été confié à un groupe de travail OASIS (une or­ga­ni­sa­tion à but non lucratif).

AMQP résout plusieurs problèmes en même temps : ce protocole garantit d’une part une trans­mis­sion 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, per­met­tant ainsi une com­mu­ni­ca­tion asyn­chrone : l’émetteur et le des­ti­na­taire n’ont pas à agir au même rythme. Le des­ti­na­taire (con­som­ma­teur) du message n’est pas obligé d’accepter di­rec­te­ment l’in­for­ma­tion, de la traiter et d’en accuser réception auprès de l’émetteur (pro­duc­teur). À la place, il va récupérer le message dans la file d’attente lorsqu’il en a la capacité. Le pro­duc­teur peut ainsi continuer à tra­vail­ler sans créer de période d’inac­ti­vité.

Le succès rencontré par ce protocole re­la­ti­ve­ment récent lui vient également de son in­te­ro­pé­ra­bi­lité. L’Advanced Message Queuing Protocol établit à dessein une base commune qui permet même de publier les dif­fé­rentes ap­pli­ca­tions dans des langages de pro­gram­ma­tion distincts. Les pro­grammes de dif­fé­rentes or­ga­ni­sa­tions peuvent ainsi se com­prendre sans dif­fi­culté. Et comme AMQP est en libre accès, chaque en­tre­prise peut utiliser le protocole sans coûts sup­plé­men­taires.

Dans le modèle OSI, AMQP agit au niveau de la couche d’ap­pli­ca­tion : il est ainsi en contact direct avec les dif­fé­rents pro­grammes. Les pro­to­coles IMAP (pour les emails), FTP (pour la trans­mis­sion de fichiers) et IRC (pour la mes­sa­ge­rie ins­tan­ta­née) sont également actifs au niveau de cette couche. Pour trans­mettre les messages, le protocole s’appuie sur un médiateur appelé « message broker » (agent de messages). Ce dernier assure la dis­tri­bu­tion des messages aux dif­fé­rents des­ti­na­taires selon des règles définies. AMQP règle également le com­por­te­ment de ce serveur de trans­mis­sion.

L’Advanced Message Queuing Protocol repose donc aussi bien sur la com­mu­ni­ca­tion entre les dif­fé­rents par­ti­ci­pants que sur le com­por­te­ment des brokers. Les ins­truc­tions 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 com­mu­ni­ca­tion.
• Le pro­duc­teur (Producer) procède à la création et à l’envoi du message.
• Le message broker distribue le message aux dif­fé­rentes files d’attente (Queue) selon des règles définies.
• Le con­som­ma­teur (Consumer) récupère le message dans la file d’attente à laquelle il a accès et traite le message.

La trans­mis­sion du message est à nouveau in­ter­rom­pue dans le message broker : l’Exchange ré­cep­tionne 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 trans­mettre les messages de quatre façons dif­fé­rentes.

La première façon, le Direct exchange, envoie les messages à un des­ti­na­taire 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’iden­ti­fier la « Queue ». Lorsque la Routing key et la Binding key cor­res­pon­dent, le message peut être transmis à la file d’attente et, à terme, au des­ti­na­taire 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 des­ti­na­taires.

Le « Fanout exchange » fonc­tionne de façon similaire. Cependant, le message broker ignore com­plè­te­ment la « Routing key » dans ce cas et l’Exchange redirige le message vers toutes les Queues dis­po­nibles en du­pli­quant les in­for­ma­tions. Le « Topic exchange » fonc­tionne de façon dif­fé­rente. Comme avec le Direct exchange, la Routing key est comparée aux Binding keys, mais il n’est pas né­ces­saire qu’elles cor­res­pon­dent par­fai­te­ment. Ici, on utilise plutôt des balises afin de mettre les messages à dis­po­si­tion de plusieurs Queues de façon ciblée.

Fi­na­le­ment, 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é­sig­na­tion x-match détermine si toutes les valeurs doivent cor­res­pondre (valeur : all) ou si une seule valeur doit cor­res­pondre au Binding (valeur : any). La première valeur cor­res­pond 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 des­ti­na­taire avant que toutes les autres trames aient atteint leur des­ti­na­tion. Chaque trame peut être divisée en trois segments (dans la version 1.0) :

• Frame header : cet entête obli­ga­toire a une valeur de 8 bytes et contient les in­for­ma­tions dé­fi­nis­sant le routage du message.
• Extended header : cette section est fa­cul­ta­tive et n’a pas de longueur fixe. Elle permet de compléter l’entête ul­té­rieu­re­ment avec des in­for­ma­tions sup­plé­men­taires.
• Frame body : le corps contient les données à trans­mettre à pro­pre­ment 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 dis­tinctes :

• open : négocie les pa­ra­mètres de connexion entre le message broker et le client.
• begin : indique qu’une connexion est établie.
• attach : un lien né­ces­saire à l’uti­li­sa­tion du transfert de données est joint au message.
• flow : modifie le statut d’un lien.
• transfer : la trame « transfer » transmet le message à pro­pre­ment parler.
• dis­po­si­tion : une trame de dis­po­si­tion fournit des in­for­ma­tions sur les mo­di­fi­ca­tions apportées à la livraison des in­for­ma­tions.
• 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 per­met­tant son iden­ti­fi­ca­tion par les autres par­ti­ci­pants. Cette dé­sig­na­tion 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 per­ma­nente ou être volatile dans une mémoire vive. La variante per­ma­nente permet de garantir la con­ser­va­tion de la file d’attente en cas de re­dé­mar­rage d’un message broker. Cependant, elle ne garantit pas que les messages seront également sau­ve­gar­dés du­ra­ble­ment : leur dis­po­ni­bi­lité après un re­dé­mar­rage 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é in­ter­rompu(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 des­ti­na­taire. 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 per­ti­nem­ment de recevoir un message. Cela peut s’avérer utile lorsque le trai­te­ment du message ne fonc­tionne pas. Le retour de la part du Consumer pousse le message broker à supprimer com­plè­te­ment le message ou à l’insérer à nouveau dans la file d’attente.

À l’heure actuelle, il existe deux versions en­tiè­re­ment in­dé­pen­dantes de l’Advanced Message Queuing Protocol. La version 1.0 est dé­ve­lop­pée par le groupe OASIS. Dans le cas de RabbitMQ en par­ti­cu­lier, la version 0-9-1, un peu plus ancienne, est toutefois utilisée. Les deux versions ne sont pas com­pa­tibles l’une avec l’autre. Dans la version 1.0, les message brokers, les Bindings et les Exchanges ont une moindre im­por­tance. La version 0-9-1 n’en a pas besoin, mais ne s’interdit pas pour autant d’utiliser ces mé­dia­teurs.