Dans nos modèles Meurise, MCD, SGBDR, la relation entre tables est naturelle.  Avec du NoSQL,  ça l’est moins. Mongo nous propose des pistes de modélisation, mais je ne trouvais pas les solutions satisfaisantes. Je m’explique. Imaginons, une collection d’auteurs et une collection d’articles. Avec un SGBDR classique on aurait : D’après Mongo, il y a 2 solutions :

1. On inclue le document auteur (tout ou partie) dans le document article
   • Avantage : quand on veut la liste des articles, on a les infos de l’auteur avec
   • Inconvénient : quand l’auteur change une de ces infos présente dans le document article, il faut faire 2 mise à jour des données
2. On a une référence de l’auteur (son id) dans le document article.
   • Avantage : les mises à jours sont simplifiées
   • Inconvénient : on est forcé de récupérer la liste des articles, puis pour chacun d’eux, récupérer l’id de l’auteur, rechercher tous les auteurs dont l’id se trouve dans cette liste et enfin raccrocher l’article à son auteur. 2 requêtes et des manipulations de listes côté serveur.

Mais alors est-ce possible de tout récupérer en un seul appel avec une référence de l’auteur dans l’article? Après un peu de recherche oui.

Pour les besoins d’une conférence sur Apache Camel, je trouvais sympa d’afficher les live-tweets sous forme de notification Ubuntu pendant le déroulement des slides. (J’avais trouvé l’idée du Tweet-wall du DevoXX sympa) En creusant un peu, je suis tombé sur la librairie GTK.jar fournie par java-gnome.

Le composant camel-kafka dédié au framework Camel et permettant des interactions avec le bus Kafka est disponible : camel-kafka La documentation se trouve là : Usage

Dans la même lignée que le mariage Thrift-Camel, ça me trottait depuis longtemps dans la tête de marier Kafka et Camel. Kafka est un bus événementiel très performant de type publish/subscribe. Il gère de la persistance, se coordonne avec Zookeeper fonctionne en cluster. J’avais dans l’idée de créer un composant Camel pour produire et consommer des messages et c’est chose faite.

Dans le cadre de mes pérégrinations architecturales, j’étais tombé au hasard d’un surf sur des slides présentant l’architecture ultime en terme de performances. Cette archi utilisait Thrift et Camel. Thrift servant de protocole et de transport pour communiquer avec un bus Camel. Ça m’a intrigué car le composant Thrift n’existe pas chez Camel. Alors, je me suis arraché le peu de cheveux qu’il me reste et voici la solution.

Voici la problématique : faire un export display depuis mon PC vers une autre machine en passant par une machine intermédiaire : [singlepic id=31 w=320 h=240 float=]