| Mardi prochain, le 18 janvier, le Lyon JUG propose une soirée autour de la thématique de Messaging. Pour vous donner envie de vous rendre à cette soirée, voici l’interview de Jean-Frédéric “Jeff” Mesnil. Jeff écrit des logiciels de middleware liés au messaging, aux transactions distribuées et à la réplication de base de données depuis une décennie. Récemment, il a travaillé sur HornetQ, l’implémentation de messaging de JBoss et Red Hat. Il écrit maintenant des logiciels de data mining pour un éditeur de sites Web, Bestofmedia. | Lors de cette même soirée, Arnaud Simon viendra également nous parler d’AMQP, et d’une de ses implémentations Apache Qpid (voir l’interview d’Arnaud également sur le site des JDuchess).

QPID

Agnès : Tu es un des leaders du projet HornetQ. Peux-tu nous présenter brièvement ce projet, notamment son “ontologie” (vis-à-vis de JBoss Messaging, de son intégration dans JBoss Application Server 6). Comment évolue-t-il? Qui est garant de ses évolutions?
Jeff : HornetQ est le successeur de JBoss Messaging. JBoss Messaging était le service de messaging fourni par JBoss AS. Quand Red Hat et JBoss ont défini la roadmap pour le messaging, il a été convenu que la base de code de JBoss Messaging n’était plus adaptée à certaines nouvelles contraintes (notamment pour embarquer un service de messaging dans une application). On a donc ré-architecturé le projet pour simplifier son utilisation, maximiser ses performances tout en offrant un panel de déploiement couvrant toutes les attentes de nos utilisateurs. Au fur et à mesure de la réécriture du code, il est devenu apparent que la nouvelle base de code était fondamentalement différente de celle de JBoss Messaging. Red Hat a alors décidé de renommer le projet pour marquer ce changement global.
Il y a un noyau de développeurs qui travaillent sur HornetQ employés par Red Hat et autour d’une communauté qui contribue de façons diverses et variées (bug report, patches, RFE, support sur les forums, etc.). HornetQ est devenu le service de messaging par défaut dans JBoss AS 6 et dans la prochaine version d’EAP. HornetQ est aussi beaucoup utilisé en mode “standalone” afin de fournir un serveur de messaging servant de bases à la communication d’applications plus complexes.

Agnès : Qu’est-ce qui le distingue d’une part des autres MoM (peux-tu en particulier nous parler de ses points forts vis-à-vis du cloud, notamment d’une solution PaaS) et d’autre part du projet JBossESB?
Jeff : Un aspect important du développement d’HornetQ est les performances. Un benchmark indépendant a été utilisé pour montrer les performances d’HornetQ comparées aux autres MOM du marché (Open Source et propriétaires). HornetQ est premier dans la plupart des scénarii (et avec une bonne longueur d’avance dans beaucoup!)
Un MOM est souvent utilisé comme base de communication pour les applications complexes. Les performances globales de l’application sont alors liées aux performances du MOM et de sa capacité à passer à l’échelle.
L’architecture d’HornetQ basée sur Java NIO permet un passage à l’échelle en évitant les goulots d’étranglements induits par du code bloquant. Dans HornetQ, le chemin du code est asynchrone et ne bloque pas, par exemple en attendant de recevoir des données du disque dur ou du réseau. Nous essayons aussi de rendre HornetQ le plus simple possible à configurer même si c’est souvent un compromis entre la simplicité de la configuration et la possibilité de configurer “au mieux” en fonction de son utilisation. HornetQ dispose d’une documentation exhaustive et d’exemples pour chacun de ces fonctionnalités afin de les appréhender au cas par cas avant de les combiner en utilisation réelle.
JBossESB et HornetQ sont à deux niveaux de fonctionnalités différents. HornetQ fournit un service de messagerie asynchrone. JBossESB fournit des services de plus haut-niveau (transformation, routage) qui peuvent utiliser les messages comme méthode de communication. Dans ce cas, JBossESB bénéficie “automatiquement” des performances de HornetQ.

Agnès : HornetMQ supporte STOMP et depuis peu REST. Qu’en est-il d’AMQP? Que penses-tu de ce standard, ce protocole “wire-level”?
Jeff : Arnaud Simon qui présentera AMQP au JUG de Lyon est mieux placé que moi pour répondre :)
Pour HornetQ, nous avons décidé dans un premier temps de supporter STOMP pour l’interopérabilité avec d’autres plateformes que Java. STOMP est un bon protocole pour l’interopérabilité: il est simple, basé sur du texte. Par contre, il ne permet pas d’obtenir les mêmes performances qu’un protocole binaire. AMQP offre un tel protocole et plus encore: il définit aussi le comportement des brokers pour envoyer et recevoir des messages mais aussi la topologie du système. Il semble pour l’instant qu’il n’y ait pas encore de consensus pour la sortie d’une version 1.0 du protocole et les différents brokers qui implémentent AMQP ne sont pas tous capables de discuter entre eux. C’est un gros point négatif pour un protocole censé assurer l’interopérabilité entre les implémentations…

Agnès : Peux-tu nous parler de l’architecture d’HornetQ (ses couches applicatives, ses dépendances)? Puis-je l’embarquer facilement dans mon application java (utile pour la partie tests unitaires par exemple)?
Jeff : En tirant les leçons de JBoss Messaging, il a été décidé très tôt de rendre HornetQ plus facilement déployable et intégrable. A la base, HornetQ est un ensemble de classes Java “POJO”. HornetQ ne dépend que d’un seul jar pour Netty, le remarquable framework NIO. Il suffit d’inclure le jar d’HornetQ et celui de Netty pour embarquer un serveur de messaging complet dans n’importe quelle application Java. Cela est rendu encore plus facile par l’utilisation d’un framework comme JBoss Microcontainer ou Google Guice mais vous pouvez aussi instantier directement les classes de HornetQ. Un autre aspect important de HornetQ est son “journal”. Il s’agit du composant chargé de persister les messages sur disque pour éviter de les perdre en cas de crashs. HornetQ n’utilise pas de bases de données relationnelles mais une bibliothèque utilisant Java NIO pour son journal afin de garantir la persistance des données de manière fiable et rapide. Si HornetQ est exécuté sur Linux, nous supportons la lib asyncio qui permet encore d’augmenter les performances du journal. Le reste des dépendances est optionnel et dépend de l’utilisation d’HornetQ. Ainsi, la couche JMS est écrite en fonction du propre protocole de messaging de HornetQ. Pour bénéficier du support de JMS dans HornetQ, il suffit de rajouter un jar pour l’API JMS et hornetq-jms.jar.
Pour les tests unitaires, il est ainsi possible de créer en quelques lignes de code un serveur HornetQ en mémoire qui ne nécessitera aucun port ouvert (tous les échanges de message se feront en mémoire, les clients et le serveur étant dans la même JVM) et aucun accès disque dur (en désactivant la persistance des messages par exemple). Cela permet de tester le code fonctionnel de manière très simple sans installer une infrastructure complète au préalable.

Agnès : Un peu de teasing… Peux-tu nous parler de la roadmap d’HornetMQ?
Jeff :L’équipe d’HornetQ est au four et au moulin pour sortir HornetQ 2.2 très bientôt. Cette version étendra et simplifiera le déploiement de cluster de serveurs HornetQ et permettra une meilleure haute-disponibilité du service tout en simplifiant son déploiement. L’implémentation de STOMP a été aussi optimisé et ses performances deviennent vraiment intéressantes. De façon plus générale, HornetQ devient aussi le service de messaging par défaut dans JBoss AS 6 et sera disponible dans la prochaine version de JBoss EAP. Je ne veux pas gâcher les prochaines annonces de Clebert Suconic, le project lead de HornetQ, mais attendez-vous à des développements intéressants autour du cloud computing et des smartphones. Si vous venez me voir après la présentation au JUG de Lyon, je vous en dirai peut-être un peu plus :)

Merci Jeff!

Merci à Anne-Laure Rigaudon pour son aide précieuse sur la relecture de cet interview.

Les inscriptions sont ouvertes! Rendez-vous sur le site du Lyon JUG