« 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…

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.

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

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

Question: comment est-ce que AMQP peut offrir les mêmes garanties transactionnelles de JMS/XA?

Comme par exemple: http://www.atomikos.com/Publications/ReliableJmsWithTransactions

Merci,
Guy

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!

PS: Super article , au fait

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.

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.

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.

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.

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/

@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.

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.