Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Naufrage pour Google Wave

Le coin de la technique

• Nouvelle architecture de réplication et de sharding pour MongoDB
• Axon, une implémentation Java du pattern CQRS
• L’architecture de Last.fm basée sur HornetQ

Actualité éditeurs / SSII

Naufrage pour Google Wave

Nous l’apprenons sur The H, Google Wave coule et ne sera bientôt plus. Après un peu plus d’un an d’existence, Google a décidé de mettre fin à son expérimentation qui n’aura pas répondu à toutes les attentes qu’elle avait provoqué. Pourtant, nous-mêmes, nous y avons cru ! Basé sur des protocoles ouverts, le système avait de quoi séduire, même si tout le monde se demandait un peu quelles allaient être les applications réelles… Las, les serveurs de Google devraient être fermés l’année prochaine. La firme annonce quand même la mise à disposition future d’outils permettant aux utilisateurs de « libérer leurs données de Wave ». Mais ne nous y trompons pas, même si l’interface graphique colorée ayant donné aux internautes un avant goût de la communication du futur disparaît, il reste quasi-certain que le mécanisme d’échange de données entre serveurs Wave devrait survivre et servir de base à d’autres projets.

Le coin de la technique

Nouvelle architecture de réplication et de sharding pour MongoDB

MongoDB est une base de données orientée documents très populaire ces temps-ci. 10gen l’entreprise Open Source qui en est à la source se montre très active tant sur la communication que le plan technique en apportant des améliorations régulières pour placer leur base de données NoSQL à la hauteur des ambitions qu’on lui prête.
Respectant le planning présenté mi-juin lors du MongoDB Day à Paris, la version 1.6 vient d’être finalisée. Cette release estivale était particulièrement attendue car elle apporte des améliorations majeures sur l’architecture distribuée de MongoDB :

• La réplication était jusqu’alors assurée par une architecture master / slave qui souffrait d’un single point of failure à cause de son nœud master. MongoDB 1.6 introduit la notion de replica set qui est un ensemble de nœuds qui possèderont des replicas d’une même donnée. Une élection de master permet alors de définir un nœud unique qui sera responsable des écritures.
• Le sharding est maintenant production ready dans MongoDB. L’architecture de partitionnement repose sur un ou plusieurs nœud proxy intermédiaire entre les clients et les instances MongoDB.

En apportant ces améliorations, 10gen offre à MongoDB une architecture distribuée plus attrayante. Ce choix se comprend puisque MongoDB ne proposait jusqu’alors que des mécanismes peu innovants et qui poussaient beaucoup de projets à lui préférer Cassandra.

Axon, une implémentation Java du pattern CQRS

Le Command Query Request Segregation (CQRS) est un pattern architectural qui a été formalisé fin 2009 par Greg Young et Udi Dahan. Il repose sur l’idée de séparer le code métier selon qu’il s’appuie sur des opérations d’écriture (command) ou de consultation de données (query), plutôt que par découpage fonctionnel. Le but recherché ici est d’offrir une grande scalabilité en permettant aux lectures de s’effectuer de manière synchrone dans un cache, tandis que les requêtes d’écritures sont effectuées de manière asynchrone en mettant à jour à la fois le cache et la base de données sous-jacente.

Les développeurs Java disposent d’une implémentation Open Source de ce pattern, il s’agit du framework Axon (anciennement CQRS4J). Le projet est très actif et vient diffuser une version 0.6 dont la maturité mérite de s’y attarder : gestion et persistance des évènements, intégration à Spring et gestion des transactions.
Ce framework reste modeste pour l’instant et ne couvre qu’un nombre limité d’environnements techniques mais à défaut de répondre à votre besoin il constituera un exemple d’implémentation intéressant à étudier.

L’architecture de Last.fm basée sur HornetQ

Tout le monde connaît Last.fm, le service de streaming et de recommandation de musique. La compagnie a récemment changé son infrastructure de streaming et en a profité pour adopter JBoss HornetQ comme serveur de messaging, au détriment « d’un autre serveur open-source » (mais nous ne saurons pas lequel !). Jeff Mesnil publie sur DZone un article expliquant les raisons de ce changement et la façon dont Last.fm se sert d’HornetQ.
Pour résumer simplement, les messages JMS sont générés principalement par les streamers pour:

• notifier la fin de l’écoute d’un morceau et donc faire mettre à jour la base.
• permettre la déconnexion automatique d’un utilisateur connecté à un flux si un message généré par un second streamer indique qu’il vient de se connecter à un autre flux.

Dans sa configuration de HornetQ, Last.fm a mis l’accent sur la performance:

• la persistance a été désactivée. Comme rapporté par nos lecteurs dans les commentaires d’un précédant article celle-ci est connue pour être consommatrice.
• messages déclarés comme pré-acquittés, permettant d’éliminer des accès réseau supplémentaires.

Bien sûr tout ceci est fait au détriment de la robustesse. On n’a rien sans rien ! Mais Last.fm préfère perdre des messages plutôt que d’empêcher un auditeur d’écouter sa musique: « Availability was more important than reliable delivery ». Il est à noter que pour renforcer la robustesse, les envois de messages ne sont pas faits n’importe comment: un seul thread s’occupe de la communication JMS. Il communique avec les autres threads en interne par un mécanisme de files, dans lesquelles il puise les messages à envoyer à HornetQ et dépose les messages reçus. Ces files étant limitées en mémoire, cette dernière est donc maîtrisée et comme il y a un seul thread responsable des accès JMS, il n’y a pas de risque de blocage de tout le système.

Pour continuer sur HornetQ, notons que la tant attendue interface REST vient d’être annoncée par Bill Burke, son développeur principal, sur le forum du broker. Cette interface n’est pas encore disponible dans une version officielle de HornetQ, mais sa documentation permet d’ores et déjà de se faire une idée. Basée directement sur HTTP, elle évite de forcer l’utilisation d’une quelconque encapsulation (autre qu’applicative) des messages. Et bien sûr, on peut l’utiliser avec n’importe quel langage: REST est interopérable. La documentation spécifique à la création de messages permet de se faire une idée rapidement. Basée sur RestEasy, qui fera aussi partie du futur JBoss AS 6, il y a fort à parier que cette interface fera parler d’elle et ouvrira la voie à de nouvelles utilisations du broker.