Publié par
Il y a 8 années · 12 minutes · Back

AMQP, une alternative à JMS ?

Vous avez une application Java qui doit envoyer et recevoir des messages à droite et à gauche pour des raisons qui n’appartiennent qu’à vous… Votre premier réflexe sera sûrement de contacter votre vieil ami JMS. Pour ça, vous aurez aussi besoin d’un broker de message, mais vous n’êtes pas très riche et des outils comme WebSphere ou Tibco sont hors de portée… Vous aurez alors de fortes chances de vous tourner vers votre autre vieil ami ActiveMQ. Bon d’accord, l’amitié ça compte, mais par ailleurs d’autres amis (des vrais !) vous signalent qu’ils ont eu quelques problèmes de blocage de file avec ActiveMQ et qu’ils ont eu du mal à identifier ces problèmes. En plus vous avez encore d’autres amis qui aimeraient bien communiquer avec vous sur ce même broker mais leurs applications tournent en ruby et C++ qui parlent mal le JMS… C’est le moment idéal de vous présenter un nouvel ami : AMQP !

AMQP (Advanced Message Queuing Protocol) est un protocole de messagerie créé à l’initiative de la banque JP Morgan Chase pour gérer la communication entre ses différents partenaires. Le but affiché était de fournir une solution alternative aux solutions payantes et relativement chères dans le domaine du MOM (Message-Oriented Middleware) dominé largement par Websphere MQ d’IBM et RendezVous de Tibco (93% du marché à eux deux en 2008). Un certain nombre de partenaires se sont fédérés autour de ce projet pour aboutir à une première spécification en 2006. L’ambition avouée est qu’elle devienne l’équivalent du HTTP pour l’internet, ce qui explique qu’elle décrive aussi bien les différentes sémantiques liées au MOM que la partie plus bas niveau du transport de ces messages. Cette normalisation permet la multiplication des solutions clientes ou serveurs dont la compatibilité sera garantie par cette spécification. Par exemple, un broker de message écrit en Erlang comme RabbitMQ transférera de façon transparente un message d’un client ruby vers un autre client Java/JMS.

Notez bien qu’AMQP s’identifie clairement comme un protocole et non comme une API, contrairement à JMS. Donc un client Java basé sur JMS peut, moyennant des adaptations plus ou moins coûteuses, communiquer avec un broker AMQP.

Un nouveau protocole

Les spécifications AMQP sont parties de cas d’utilisation très concrets pour aboutir à des spécifications essayant d’englober un maximum de typologies. Voici quelques unes d’entre elles (QPid ou RabbitMQ) :

  • Store-and-forward: les messages sont persistés puis récupérés par un seul client qui décidera s’il faut les supprimer.
  • Point-to-point: une communication dédiée entre un émetteur et un receveur, éventuellement bidirectionnelle.
  • One-to-many (ou fanout): un message est retransmis à toutes les queues d’une zone d’échange. Ceci permet de modéliser le multicast.
  • Transaction (distribuée ou pas): l’émetteur peut englober un paquet de messages dans une transaction, ces messages ne pourront être lus que lorsque l’émetteur les aura acquittés.
  • Publish-subscribe (pub-sub): plusieurs émetteurs postent des messages en fonction de mots clés (topics) auxquels s’abonnent plusieurs receveurs.
  • Content-based routing: le routage des messages est déterminé selon le contenu du message ou par une fonction externe.
  • Queued file transfer: on n’envoie plus de simples messages mais des fichiers, voire tout le contenu d’un répertoire.

Ces différentes architectures se combinent bien sûr entre elles, je pense particulièrement aux transactions. Ces schémas de base un peu abstraits rejoignent des concepts ou des applications connus de tous. Un serveur de mail par exemple s’appuiera sur un « store-and-forward », un chat sur un « point-to-point » ou un streaming de fichier sur un « queued file transfer ». Cette sémantique est un vrai plus pour la phase de conception d’un projet même si ensuite rien n’est figé dans la réalisation.

Derrière ces grands concepts se cachent des briques élémentaires très simples :

  • Queue de message (Message Queue): zone de stockage des messages (en mémoire ou sur le disque). Elle aura les propriétés privée/partagée, durable/transitoire, permanente/temporaire.
  • Zone d’échange (Exchange): l’entité qui accepte les messages et les route vers les queues de messages. Les critères de routage peuvent se faire de plusieurs façons (inspection du contenu, du header, clés de routage…). Les zones d’échange peuvent être créées dynamiquement par les applications clientes.
  • Zone virtuelle (Virtual Zone): ce concept est copié de celui des serveurs HTTP d’Apache. Cette zone crée un espace contenant différentes zones d’échange et de queues de message complètement étanches aux autres zones virtuelles. Donc une connexion au serveur ne pourra être associée qu’à une zone virtuelle. C’est très utile lorsqu’on veut mutualiser les ressources.

Pour le routage, la zone d’échange pourra implémenter différents algorithmes :

  • Direct: la clé de routage correspond exactement à l’adresse de la queue.
  • Topic: la clé de routage correspond à un certain pattern (une expression régulière) de l’adresse de la queue.
  • Routage par le header: analyse une table clé/valeur pour décider vers quelle queue aller.
  • Système : appel à un service externe.

De même les queues de message peuvent avoir des typologies assez variées: durables après un redémarrage de serveur, auto-suppression si plus utilisées, dépendant d’un souscripteur, partagées par plusieurs souscripteurs, répondant à un message particulier…

La gestion des transactions et des transactions distribuées est également spécifiée. Un message envoyé à l’intérieur d’une transaction ne sera récupéré par les souscripteurs qu’à partir du moment où l’émetteur acquittera la transaction. Cependant, cette gestion peut varier selon l’implémentation des serveurs car lors d’un rollback, seules les commandes de l’émetteur sont dépilées. Certains états du serveur peuvent donc être modifiés malgré tout (par exemple la déclaration d’une nouvelle queue de message).

Solutions existantes :

RabbitMQ (Mozilla Public License) est sans doute le broker AMQP le plus connu. Il est basé sur le langage Erlang et ses librairies OTP, développé par Ericsson et réputé pour sa haute-disponibilité et sa tolérance aux pannes (règle des « nine nines » : 99.9999999% de disponibilité !). Au-delà de sa maturité, le point fort de ce produit est sa volonté de faciliter son intégration dans les systèmes existants. Par exemple, des distributions dédiées à Amazon EC2, avec intégration à EBS, sont proposées. La gestion du cluster est également très simple, en une commande on peut rattacher un broker à un autre. Toutes les zones d’échange, les queues de message ou les zones virtuelles seront alors partagées et répliquées. Côté client, une API Java est incluse dans la distribution, très simple et proche de l’API JMS. La communication avec un client JMS est possible grâce à une librairie proposée par OpenAMQ.

OpenAMQ propose lui-même un broker. Développé par iMatix, en C++, une API (WireAPI) est proposée. Sans doute plus complexe à appréhender, un effort particulier a néanmoins été apporté aux outils de développement (débogage, constructions de test…) et de monitoring (log, tuning…). Un langage XML (PAL) a été développé pour scripter des scénarios utiles pour les tests par exemple. Ou encore une console de monitoring pour serveur AMQP. Très pointu, OpenAMQ semble s’adresser à des experts confrontés à des projets soumis à de fortes contraintes. Il y a un côté un peu R&D qui permet par ailleurs de jouer un rôle moteur dans la communauté. A noter également que la distribution linux vient avec une implémentation de RestMS.

Par ailleurs OpenAMQ a fait main basse sur un autre broker AMQP : ZeroMQ. Enfin plus précisément un broker qui implémente plusieurs protocoles dont AMQP. On est ici à la limite du sujet tant cette application s’attache moins à son intégration dans une application de gestion classique qu’à construire une bête de course aux performances affichées impressionnantes (13.4 microsecondes de latence end-to-end, 4.1 millions de messages à la seconde).

Avec Qpid on revient un peu sur terre. Ce broker est incubé chez Apache et ne semble a priori rien apporter de plus que ceux cités plus haut. Il vaut malgré tout le coup de s’y intéresser pour les différents frameworks et librairies auxquels il s’intègre et en premier lieu celles d’Apache (Axis2, Camel, Synapse). Il est également intégré à la distribution de Red Hat MRG et est compatible avec l’outil de visualisation et de contrôle HermesJMS.

A noter également que le projet très en vue HornetQ de JBoss prévoit également de supporter ce protocole dans une prochaine version.

Perspectives et enjeux

Une communauté

La capacité d’AMQP à s’imposer comme un standard sera liée à sa capacité à drainer une vraie communauté autour de lui. Cette communauté se divise en deux actuellement : les membres du groupe de travail AMQP et la communauté open source.

Les membres du groupe de standardisation sont eux-mêmes divisés en trois familles : des fournisseurs de brokers AMQP (RabbitMQ, OpenAMQ…), les clients historiques (JPMorgan, Goldman Sachs…) qui poussent ces solutions et les fournisseurs de solutions matérielles (Cisco, Solace Systems Inc., Tervela Inc. …). Ce mélange a le gros avantage de proposer d’ores et déjà des solutions implémentées et en production qui éprouvent ce standard et l’enrichissent en retour. La réalité du terrain guide largement les spécifications comme le montre leurs Business Requirements.

Du côté OpenSource par contre la communauté reste encore discrète. En faisant une recherche rapide sur internet on trouve tout de même une bonne quantité de projets, plus ou moins expérimentaux :

  • RestMS pour poster des messages directement en Rest.
  • amqp-js pour poster des messages en javascript.
  • ici une idée pour faire du twitter avec html5.
  • réplication en base de données.
  • des librairies spring pour utiliser de façon transparente les brokers.

Du chemin reste encore à faire, mais la diversité des projets prouve malgré tout qu’il y a une demande.

Une version de référence

Pour l’instant la version 0.10 est la dernière version officielle. Mais la plupart des brokers sont en version 0.8 ou 0.9. En effet, tout le monde attend la vraie version de référence, la 1.0. qui devrait sortir cette année. Elle devrait apporter de gros changements : un système d’adressage inspiré des mails (queue_message@my_server), le remplacement des zones d’échanges par deux nouvelles entités (une queue d’entrée et un service d’échange), la suppression des Virtual Hosts (conséquence de la suppression des zones d’échanges), l’amélioration de la partie administration du broker et l’ajout de support pour les services DNS.

Ces gros changements apportent sûrement des améliorations majeures à ce protocole. Il n’y a plus qu’à espérer que la migration se fera rapidement. Il est difficile de dire aujourd’hui si les clients sur les versions 0.x pourront se connecter à cette nouvelle version de façon transparente, mais si ce n’est pas le cas, cela risque de casser la dynamique autour d’AMQP.

La concurrence

La lutte est assez féroce dans le domaine du MOM. Si on met de côté Websphere MQ et Tibco, il existe de nombreuses solutions, parfois assez éloignées conceptuellement.

On peut s’en douter, ActiveMQ ne reste pas les bras croisés. Ils poussent entre autre une solution générique, STOMP, très simple d’utilisation mais moins complète et moins performante. Ils annoncent aussi une compatibilité AMQP, sans qu’on sache très bien comment.

Jusqu’à un certain point, ce protocole rentre également en concurrence avec XMPP, le protocole de messagerie instantanée.

MuleMQ est apparu également sur la scène et est proposé comme broker dans la nouvelle distribution de l’ESB Mule. C’est un broker JMS fourni avec quelques outils. Le « tout-intégré » de cette solution peut être assez attirant, par contre on peut regretter que MuleSoft s’éloigne de plus en plus de l’Open Source.

Au contraire, HornetQ joue le jeu de l’Open Source et peut profiter de la grande expérience de JBoss dans ce domaine. Mais cela reste du JMS… Cela sera sûrement la solution privilégiée pour les applications tournant sur JBoss mais difficile de dire si la solution out of the box aura du succès.

Au final JMS est le vrai concurrent d’AMQP même si encore une fois les deux peuvent vivre ensemble. Un adaptateur JMS pour AMQP peut sembler intéressant pour des projets qui migrent vers un nouveau broker, mais il semble plus pertinent pour un nouveau projet de commencer directement dans ce nouveau standard. Par exemple l’utilisation de la librairie Java de RabbitMQ est vraiment très proche de l’API JMS et la vitesse d’apprentissage semble assez rapide pour un développeur Java.

Car un des problèmes de JMS c’est justement son manque d’interopérabilité avec d’autres langages. A cet égard il est intéressant de remarquer que Microsoft s’intéresse de près à AMQP. Depuis 2008 il participe au groupe de travail et a collaboré activement avec QPid pour la version C++ du broker. Etre agnostique vis-à-vis de l’environnement DotNet ou Java serait sûrement une carte majeure de ce standard.

Conclusion

Les solutions propriétaires comme IBM et Tibco ne sont pas réellement menacées par ce nouveau concurrent car leurs solutions sont très complètes, éprouvées et ils fournissent un support sérieux qui rassure les DSI. Le défi d’AMQP est moins de concurrencer ces leaders que de promouvoir l’architecture orientée message au sein de projets de taille moyenne et/ou open-source qui n’ont pas forcément un gros budget à investir. L’adoption massive de ce modèle de conception imposerait AMQP comme le protocole référent tant sa spécification est avancée et complète.

24 réflexions au sujet de « AMQP, une alternative à JMS ? »

  1. Publié par Julien Dubois, Il y a 8 années

    Guillaume, ton post est très bien fait!! Par contre il faudrait qu’on se synchronise, je sors justement un post sur ce sujet Vendredi, sur le blog de Responcia! Je vais le réécrire, on dira que c’est complémentaire :-)

  2. Publié par Julien Coste, Il y a 8 années

    Bravo pour cet article super complet. Par contre en surfant sur le site de ZeroMQ je suis tombé sur la FAQ qui indique que AMQP n’est plus supporté.

    Extrait de la FAQ :
    Does ØMQ support AMQP protocol?

    It used to. The feature was dropped to protect ØMQ users from infringement on AMQP-related patents.

  3. Publié par Guillaume Arnaud, Il y a 8 années

    @Julien Dubois: J’attends ton article avec impatience.
    désolé pour le surplus de boulot :)

    @Julien Coste: Bien vu! Il semble que ØMQ a peur qu’on lui reproche ses écarts au standard. La question serait de savoir s’il est trop difficile de s’y conformer ou s’ils ont choisi une direction complètement différente. Reste que leur récent partenariat avec OpenAMQ les maintient dans la sphère AMQP.

  4. Publié par Francois Armand, Il y a 8 années

    Bel article, c’est bien de voir que dans notre monde de plus en plus polyglotte et hétérogène, les Java-ist de Xebia ne sont pas à la traine ;)

    Pour ZeroMQ, ils ont choisi de s’écarter d’AMQP pour des raisons de performances, pas de complexité de la norme. Certains points d’AMQP imposent une architecture qui ne va pas avec le type de latence/débit qu’ils veulent atteindre. Par contre, ils ont une passerelle ZeroMQ/AMQP[1]

    Enfin, on peut remarquer à quelle point ce type de protocole fonctionnent bien en dessous d’une architecture à base d’acteurs. AKKA[2] propose d’ailleurs une implémentation qui utilise AMQP comme moyen de communications.

    [1] http://www.zeromq.org/whitepapers:design-v05#toc8
    [2] http://akkasource.org/

  5. Publié par Guillaume Arnaud, Il y a 8 années

    Merci pour le lien sur AKKA, sûrement à creuser, à voir peut-être avec nos spécialistes Scala…

    J’avais hésité à citer le white paper de ZeroMQ car ils parlent de la version 0.5 alors que semble-t-il la version actuelle soit la 2.0, je ne sais pas si c’est à jour.

  6. Publié par Romain Maton, Il y a 8 années

    @Fanf Salut François. Je m’intéresse beaucoup à Scala et aux frameworks environnants. Akka en fait partie. En tout cas merci pour le complément, il est vrai qu’en plus des modules Spring, Guice, REST et Comet, Akka possède aussi un module AMQP (que j’avais omis de la revue de presse citée).

  7. Publié par Guillaume Arnaud, Il y a 8 années

    @Sylvain: je pense qu’ActiveMQ n’est pas si pressé que ça d’implémenter un connecteur AMQP. Dans le lien que tu donnes ils disent attendre la version 0.10 des spécifications alors qu’elle est déjà sortie… A mon avis ils parlent plutôt de la version 1.0 qui sera très conséquente (plus d’Exchange entre autre).

    Cette version sera un gros challenge pour AMQP, s’ils cassent la compatibilité ils risquent de décourager quelques projets qui ont déjà investi dans cette techno mais, dans l’autre sens, ça peut aussi leur donner un nouveau coup de projecteur. En effet ce projet a au moins 4 ans de rodage et reste toujours relativement confidentiel.

  8. Publié par Henri Gomez, Il y a 8 années

    Etonnant cet article puisque je suis, professionnellement, en plein dedans.

    JMS est une API d’accès à des brokers et garantit la délivrance.
    Ce sont les services qu’un ActiveMQ, HornetQ ou Websphere offrent de facto.

    Quand on parle de performance, ensuite, il faut savoir ce qui est mis en oeuvre, je sors d’une série de benchs JMS en interne sur Websphere MQ, Active MQ et HornetQ et on voit que l’impact sur les performances est très sensible dès lorsqu’on active la persistance dans le broker et/ou la durabilité en mode Topic.

    On passe de 10000 msg/s en cas favorable à moins de 1000 dans le mode costume-bretelle. Un prix à payer qui n’est problématique qu’en environnement très temps-réel.

    Dans le cas de Tibco RDV, qui a été développé pour de la diffusion de flux de cotations (Reuters), on est dans une problématique de délivrance de flux très important sur du LAN avec une latence faible et un acheminement très rapide.

    Un bon article sur le sujet d’ailleurs :

    http://www.nighttale.net/activemq/python-messaging-activemq-and-rabbitmq.html

    Dans le secteur financier, Websphere MQ est utilisé notamment par certains réseaux comme OASIS au US et va remplacer certains anciens solutions franco-français.

    AMQP pourrait se généraliser si des utilisateurs initiateurs, comme JP Morgan l’impose aussi à leurs partenaires, ça fera l’effet boule de neige, notamment dans le domaine de la finance.

    Je serais preneur de retour d’expérience sur AMQP en utilisation réelle et production.

  9. Publié par Guillaume Arnaud, Il y a 8 années

    @Henri Gomez : J’ai l’impression que les benchmarks sont assez difficiles à réaliser dans le domaine des MOM surtout quand il faut comparer deux produits différents. En effet chacun à sa stratégie d’optimisation. Par exemple HornetQ a sorti récemment des résultats (http://www.infoq.com/news/2010/02/hornetq2-vs-activemq5.3) qui dépasseraient de 300% ceux d’ActiveMQ. Mais on apprend que c’est, pour beaucoup, grâce à une écriture fichier asynchrone (AIO) nécessitant du code natif linux. Ce qui relativise ces résultats. MuleMQ a sorti des benchs (http://www.mulesoft.org/display/MQ/Performance+Tests) qui ne permettent pas de franchement trancher pour l’un ou l’autre.
    A moins d’une rupture technologique, on peu penser qu’il n’y aura plus de grosses différences entre ces différents produits. Les avantages des uns par rapport aux autres se situeront plus sûrement autour des fonctionnalités, du support ou du monitoring.

  10. Publié par Henri Gomez, Il y a 8 années

    J’ai testé HornetQ et je dois avouer que je n’ai pas vu les 300% de mieux qu’ActiveMQ. Même pire les perfs etaient si mauvaises que j’ai contacté les développeurs de JBoss a qui j’ai aussi envoyé mon code de bench.

    Résultat ils ont levés un bug chez eux et m’ont dit que la confguration par défaut d’AMQ était plus optimiste que celle d’HornetQ. J’ai demandé une config optimiste d’HornetQ mais sans réponse encore.

    De toute façon c’est le support de persistance qui plombe la capacité du broker à avaler et restituer des messages et c’est normal.

    On en arrive à des limites physiques, celles de la capacité d’accès à un système disque en mode aléatoire.

    Je retesterais HornetQ 2.1 même si je pense avoir trouvé avec ActiveMQ un excellent compromis performance/stabilité.

    Si je voulais faire de la publication multicast et sans garantie, d’autres API existent comme JGroups par exemple.

  11. Publié par Ga.K., Il y a 8 années

    @Henri Gomez : On avait fait des tests également avec activemq et l’influence de la persistence était assez forte.
    Mais cela dépend ce qu’on cherche. Sur le projet sur lequel j’ai travaillé, on avait une problématique très forte de reliability. Besoin que les brokers se connectent, se déconnectent aisément, qu’il n’y ait pas de perte de message même après déconnection etc. Pour cela Joram avait très bien fait l’affaire, bien plus que activemq qui était un peu frimeur (pour ne pas dire plus) dans sa doc.
    Tout cela pour dire que tout dépend de ton besoin. Plus de vitesse, de scalabilité et de solidité…

    PS: Super article , au fait :)

  12. Publié par Sept.Vingt, Il y a 8 années

    Une question que je me pose concernant AMQP…
    On peut simuler un mode « multicast logique » en mode fanout ou one-tomany ..
    Ok tres bien une relation 1-n donc … mais dans un environnement fortement TRES distribué (géographiquement)…

    en multicast ip, quand une machine veut sans se poser de question parler à tt les machines enregistrées sur un flux multicast, elle envoit des données avec pour ip destination une adresse multicast et basta … au bout du compte tt les machines enregistrées sur ce flux recoivent les données qui n’ont jamais été dupliquées sur les liens réseaux …

    Si on simule ce comportement avec AQMP avec le « fanout » … dans les terminaisons reseaux, chaque client qui a soucrit à un « exchange » se verra envoyer les données, si 10 machines sont sur le meme reseau, les messages vont passer 10 fois non?

    Ca me pose un serieux probleme tout cela … je n’ai pas l’impression que AMQP puisse utiliser le multicast IP pour éviter des duplications de messages sur les liens réseaux …

    Si vous pouviez m’éclairer à ce sujet, j’en serai plus que content!

    Merci et super article! :)

  13. Publié par Henri Gomez, Il y a 8 années

    Quand on en vient à utiliser du multicast sur un LAN, comme par exemple en salle de marché pour de la diffusion de flux temps-réel, on utilise des API de plus bas niveaux, par exemple JGroups (ou TIBCO-Rendez-vous si on a les moyens) :)

  14. Publié par Guillaume Arnaud, Il y a 8 années

    @Sept.Vingt
    C’est sûr que ça ne remplacera pas un vrai multicast, entre autre sur la gestion de la bande-passante. Ce mode sert surtout à faciliter la tâche de l’émetteur, il n’a pas à spécifier le destinataire, toutes les queues associées à un exchange seront notifiées. Il y aura donc autant de messages envoyés qu’il y a de queues.
    Il est vaguement question d’intégrer le multicast dans la norme mais ça ne semble pas leur priorité.
    Il faut ensuite peut-être regarder ce que chaque broker propose mais de mon côté je n’ai rien trouvé d’intéressant à ce sujet.

  15. Publié par bjb, Il y a 7 années

    « Donc un client Java basé sur JMS peut, moyennant des adaptations plus ou moins coûteuses, communiquer avec un broker AMQP. »

    C’est vague. Compte tenue de la prédominance de JMS comme API dans le monde du MOM en entreprise, on peut se demander pourquoi ne pas avoir simplement implémenté un protocole standard pour JMS ;)

    Manque :
    – Performance des solutions évoquées en mode cluster
    – Stratégies de persistence des messages
    – Gestion de transaction ou acquittement
    – Inclusion dans des transactions XA

    Bref, soit la spec est légère … soit l’article mérite un deuxième volet ;)

  16. Publié par Marc Buils, Il y a 7 années

    Salut Guillaume,

    Je te remercie pour ton article, c’est une excellente introduction au protocole AMQP.
    Ça fait quelques temps que je cherche une sorte de bus qui me permette de faire communiquer des applications industrielles avec du PHP. J’ai l’impression qu’AMPQ est une solution sérieuse.

    Merci,

    Marc

  17. Publié par Guillaume Arnaud, Il y a 7 années

    @bjb

    L’expression est peut-être un peu maladroite. Mon propos était qu’il ne me semblait pas approprié d’utiliser JMS via un adaptateur AMQP, il y a forcément un surcoût de conception voire de performance. D’autant qu’il existe des librairies Java pour les clients AMQP (par exemple avec Spring AMQP: http://www.springsource.org/spring-amqp).

    « pourquoi ne pas avoir simplement implémenté un protocole standard pour JMS  » ? Un des grands enjeux de ce protocole est l’interopérabilité entre des plateformes hétérogènes, une application Java communiquant avec une application .Net par exemple.

    @Marc

    Je pense effectivement qu’AMQP se prête bien à ton cas d’utilisation. J’ai vu une présentation intéressante d’Alvaro Videla (qui, au passage, est en train d’écrire « RabbitMQ in Action » chez Manning) sur des cas d’utilisation pour le php: http://www.slideshare.net/old_sound/integrating-php-withrabbitmqzendcon . Si vous continuez dans cette voie je serais très intéressé par vos retour d’expérience.

  18. Publié par Toto, Il y a 6 années

    @bjb

    « on peut se demander pourquoi ne pas avoir simplement implémenté un protocole standard pour JMS »

    Peut-être parce que JMS ne définit aucun protocole réseau mais uniquement une API et la façon d’en fournir des implémentations (SPI). Dit autrement pour parler AMQP sur le réseau il faut un fournisseur de service JMS qui parle AMQP… un adaptateur quoi…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *