Cette session animée par Claus Ibsen (@davsclaus) et James Strachan (@jstrachan) s’est déroulée en deux parties:

• une première assez théorique puisqu’elle a consisté à rappeler les concepts de base ainsi que les avantages des EIPs, mais également comment Apache Camel permettait de les implémenter
• une deuxième partie plus pratique avec une démonstration de Fuse IDE

Avant de vous en faire un petit résumé, il convient de revenir sur nos deux speakers :

• En effet, Claus Ibsen est commiteur actif sur le projet Apache Camel et est également l’auteur du livre “Camel In Action” aux éditions Manning.
• James Strachan est, quant à lui, le papa du langage Groovy mais également co-fondateur des projets ServiceMix et Scalate et également commiteur actif sur les projets ActiveMQ et Camel. Autant le dire tout de suite, des speakers de qualité qui connaissaient bien leur sujet.

Ainsi, la première partie de cette session a, tout d’abord, présenté Apache Camel dont l’acronyme signifie “Concise Application Messaging Exchange Language” et qui a débuté le 19/03/2007 avec une première release stable en Juin 2007.
En fait, il s’agit d’un framework open source basé sur les EIPs (Enterprise Integration Patterns), sujet qui a fait l’objet d’une petite piqûre de rappel (pour plus d’informations sur ce point que je ne détaillerai pas, je vous renvoie sur l’article suivant).

Claus a ensuite rappelé en quoi les problématiques d’intégration étaient importantes. En effet, les applications actuelles intègrent de plus en plus de couches techniques hétérogènes en raison de la nécessité d’avoir à s’intégrer avec des systèmes externes mais également en raison de contraintes plus techniques. Ces nombreuses couches techniques ont fait qu’il est devenu de plus en plus difficile d’intégrer les différents modules d’une application.

Fort de ce constat, il est apparu qu’un framework d’intégration était nécessaire afin de n’avoir plus à réinventer éternellement la roue, pour se concentrer, enfin, sur les vrais problèmes métier en déléguant au framework les taches d’intégration (tels que les problématiques de routage ou de transformation).

Par exemple, afin d’implémenter le pattern Filter (en terme d’EIPs, cela signifie que tous les messages d’un certain type ne sont pas transmis d’un point à un autre), il est plus agréable de pouvoir écrire pour spécifier directement quelque chose du type :

from(A).filter(isWidget).to(B)

où les Filter (au sens EIP) pourraient être :

isWidget = xpath('/quote/product = 'widget')
Endpoint A = endpoint(...)
Endpoint B = endpoint(...)

En fait, Apache Camel offre la possibilité de définir des concepts de routes soit directement en Java (grâce à la possibilité de passer par une API “fluent“) soit, en passant par un XML-DSL ou encore grâce à Scala.

from(A) filter(isWidget) --> B

Ainsi, Apache Camel permet de se focaliser sur les problématiques métiers en masquant la complexité plutôt que de se focaliser sur du code “bas niveau”.
Pour ce faire, il permet d’implémenter, entre autres, plus de 50 EIPs, offre plus de 80 composants et plus de 148 convertisseurs de données.

beanRef("myBean', "aMethod(${body}, ${header.JMSCorrelationId}))

Il offre également un mapping vers les moteurs de tests tels que JUnit ou TestNg afin de pouvoir tester plus simplement les routes.
En outre, coté management, Apache Camel offre une intégration avec JMX mais également une API REST en permettant, entre autres, de modifier à chaud un endpoint ou de redémarrer une route. Il est également compatible avec FuseHQ qui correspond à Spring Hyperic sur lequel a été ajouté les plugins d’Apache Camel.
Claus a également montré comment le framework gérait les erreurs :

doTry()
...
doCatch()
...
doFinally()
...
end()

errorHandler{
deadLetterChannel('mon uri')
.maximumRedeliveries(5)
.redeliveryDelay(5000)
);

Enfin, pour finir avec cette présentation des features de Camel, Claus a précisé que, coté exécution, Camel ne s’exécutait pas sur un conteneur en particulier mais qu’il pouvait être directement utilisé en :

• Java
• Spring
• Spring DM
• OSGi Blueprint

Pour finir avec cette session, James nous a fait une petite démonstration en mettant en avant l’outils FuseIDE permettant de modéliser les routes/EIPs. Ce dernier permet donc de modéliser graphiquement ces dernières et cela sans transcodage entre le context spring généré et l’outil (qui s’appuie sur Eclipse). De plus, FuseIDE offre également une console de profiling et de supervision des routes et des différents endpoints (avec, entre autres, le nombre de messages, le temps de traitement, …) en découvrant automatiquement les JVM présentes. Enfin, il permet de tester directement une route en lui fournissant un message par simple drag & drop.

Conclusion

Pour conclure, je dirai que cette session m’a beaucoup plu même si elle avait plus pour objectif de montrer les différentes possibilités offertes par le framework Apache Camel (que je connaissais un peu 😉 ).
Par contre, il est vrai que les fonctionnalités offertes par FuseIDE sont intéressantes pour une équipe amenée à prendre en main ce framework ou pour des personnes souhaitant obtenir rapidement une vue des différentes routes configurées dans l’application sans avoir à lire des fichiers XML.