Spring Integration – Apache Camel

Cet article fait suite à la présentation des frameworks d’intégration Java et propose un survol des deux solutions les plus en vue aujourd’hui : Spring Integration (Spring SI) et Apache Camel.

Il n’a pas la prétention d’être exhaustif en terme de couverture des fonctionnalités proposées par les produits et n’est pas issu d’un réel retour d’expérience s’appuyant sur les deux frameworks. L’idée est plutôt d’évaluer de manière qualitative et objective ce que propose chacun des candidats sur différents axes permettant de connaître leur positionnement relatif.

La documentation

Aussi fiable soit-il, un framework n’aura pas sa place dans un environnement industriel sans une documentation exhaustive, pratique et facilement utilisable.

Sur ces points, il est clair que nous avons à faire à deux éditeurs d’expérience dont le nom est gage de sérieux, même si en terme d’organisation et de quantité, les projets se différencient quelque peu :

• Documentation en ligne La seule documentation (hors javadoc) fournie par l’éditeur SpringSource correspond au guide de référence, couvrant l’ensemble des fonctionnalités du projet de manière structurée et claire. Côté Apache, en plus du guide utilisateur présentant une vue générale du produit, on trouve un cookbook, des rubriques spécifiques à chaque pattern EIP implémenté par le framework, le détail des composants avec pour chacun d’entre eux quelques cas d’utilisation courants, la présentation de l’architecture du produit, des exemples commentés, le détail des formats de données utilisés, la présentation des différents langages d’expression disponibles.
• Javadoc La couverture du code par la javadoc est relativement complète dans les 2 cas (environ 50%)
• Parutions Il existe aujourd’hui de chaque côté 1 livre en cours d’édition chez Manning dont la parution est prévue pour l’été 2010
• Exemples Des projets exemples sont fournis par les 2 éditeurs et correspondent à des cas d’utilisation concrets. Ils sont toutefois sensiblement plus documentés et accompagnés de tests côté Camel.

La pérennité

Malgré l’intérêt évident que peuvent susciter ces frameworks, il est nécessaire de s’assurer que l’adoption de la solution ne met pas en risque les projets dans lesquels ils s’intègrent, particulièrement sur les activités de build et de maintenance.

• Editeur Inutile de s’étendre sur la présentation des communautés SpringSource et Apache, leur renommée n’est plus à faire. Il est toutefois intéressant de préciser que le projet Camel est issu d’ActiveMQ et fait partie intégrante de FuseESB, fournie par la société Progress Software, spécialiste des solutions ESB. En outre le fait que le projet soit l’un des plus actifs de la communauté (avec ActiveMQ) permet d’assoir sa réputation. L’avenir de Spring Integration pourrait quant à lui être bousculé par le rachat récent de SpringSource par VMWare, affaire à suivre…
• Maturité La version RC1 de Spring Integration a été officialisée fin 2008, Camel est passé en projet top level chez Apache début 2009, on peut donc estimer que les deux solutions ont percé sur le marché au même moment et qu’elles sont plutôt récentes, ce qui ne présente pas en soit un risque majeur, mais ne permet pas forcément d’avoir de réels retours d’expérience sur des projets d’ampleur suffisante.
• Equipe de développement Le projet Camel est développé par une équipe formée de 70 contributeurs et 20 commiters dont certains reconnus tels que James Strachan (co-fondateur de Active MQ, ServiceMix, Groovy, commiter sur Maven …). En revanche il y a très peu d’information disponible sur l’équipe chargée du développement de Spring Integration. A priori à partir des informations glanées sur l’outil de gestion d’anomalies on peut estimer la population à environ 10 développeurs, mais ce chiffre n’est pas officiel.
• Support Cet aspect est particulièrement important aux yeux des décideurs susceptibles de valider l’adoption d’une solution. L’assurance d’un support fourni par un éditeur reconnu est souvent le signe d’une implication et d’un engagement forts de la part de ce dernier et donc indirectement un argument de poids quant au choix d’un produit. Sur Spring Integration, il existe différents types d’interventions ou de prestations de consulting proposées dans le cadre de l’offre de support autour de Spring. Sur Camel, le support est pris en charge entre autres par les sociétés FuseSource, Progress Software ou OpenLogic.
• Adoption Il suffit de saisir les bons termes dans un moteur de recherche pour s’apercevoir que Spring Integration et Camel sont des sujets d’actualité : plus de 100000 résultats ramenés par Google pour l’un comme pour l’autre, plusieurs centaines de documents, plusieurs milliers de posts dans les forums ou les blogs. Spring Integration a une légère avance en matière de résultats, sur la partie documentaire en particulier. Les forums officiels des éditeurs sont également particulièrement actifs.
• Roadmap On ne peut pas vraiment parler de roadmap chez SpringSource puisqu’il nous n’avons a pas de visibilité sur le plan de versions, ce qui n’est pas le cas côté Camel pour lequel le détail des 2 prochaines versions (plus une version « future ») est disponible. Le contenu des releases est très variable mais globalement les versions de Camel contiennent de nombreuses améliorations ou évolutions par rapport à son concurrent qui semble-t-il s’investit sur la stabilisation de son produit plus que son extension.

Les fonctionnalités

Un framework se doit avant tout de faciliter la mise en place de solutions répondant à des besoins spécifiques. Sans rentrer dans les détails, l’idée est de savoir comment le produit peut répondre nativement à quelques problématiques parmi les plus courantes en matière d’intégration.

• Les patterns EIP Dans le domaine de l’intégration, les patterns d’entreprises représentent aujourd’hui les bases du langage communément employé. Il est donc indispensable de savoir comment les frameworks intègrent cette terminologie. Côté Camel, le produit propose pas moins de 40 EIP « prêts à l’emploi ». Pour Spring, on en trouve une dizaine parmi les plus standards.
• La connectivité Spring s’interconnecte avec les systèmes externes via des adaptateurs (adapter). Il en existe environ 5 proposés par défaut aujourd’hui. En dehors des adaptateurs embarqués directement dans le framework, d’autres sont fournis via le projet Spring Extension. Seul  l’adapteur FTP est en cours de développement. Camel quant à lui embarque plus de 90 composants natifs, dont certains très spécifiques tels que HDFS, Atom ou JCR.
• Les expressions Un point essentiel permettant de décrire rapidement des échanges est l’utilisation d’expressions ou prédicats qui apportent toute la flexibilité aux règles utilisées dans la définition des patterns d’intégration. Ces expressions sont définies à partir de languages. Côté Spring, le seul langage disponible est Spring Expression Langage (SPEL) alors que Camel en propose nativement plus d’une dizaine, dont les langages de scripting les plus courants.
• Les conversions de données La transmission des données d’un point à un autre implique dans certains cas d’adapter le format des données pour se conformer aux interfaces de chacun. L’une des forces de Camel que l’on ne retrouve pas côté Spring est de convertir implicitement les données utiles contenues dans les messages échangés lors du passage d’un composant à l’autre. Il existe aujourd’hui plus de 100 conversions disponibles par défaut. De la même façon Camel propose des opérateurs de  transformations permettant de travailler avec de nombreux formats de données. Les deux frameworks permettent bien évidemment de définir explicitement ces conversions ou transformations si besoin en fournissant une implémentation spécifique.
• La gestion d’erreurs Spring propose une implémentation du pattern « dead letter channel » pour couvrir ce point. Camel le propose également et permet en outre de définir facilement des blocs try-catch sur une partie de l’échange ou d’utiliser le filtrage d’exceptions pour gérer finement la prise en charge des erreurs.
• Le rejeu Camel permet de définir un certain nombre de ré-émission d’un message suite à la remontée d’une exception, quelque soit le composant à l’origine de l’erreur. Ce nombre d’essais peut être spécifié directement dans les paramètres des composants ou indirectement via l’implémentation d’une stratégie de rejeu. De son côté, Spring Integration ne répond pas à ce type de besoin.
• La supervision – l’audit En dehors des mécanismes classiques (interception, AOP) proposés par le framework Spring, des intercepteurs plus spécifiques peuvent être utilisés par Spring Integration pour ajouter des informations à une piste d’audit. Camel permet d’ajouter des informations d’audit de manière transparent par simple paramétrage des échanges. Pour la supervision des flux, Spring n’offre pas de solution propre au framework alors que Camel intègre des fonctionnalités de BAM permettant d’évaluer certaines conditions sur des flux de bout en bout.
• La répartition de charge, le failover En dehors des solutions liées à l’infrastructure ou aux composants middleware, il peut-être utile de gérer des politiques de répartition de charge ou de failover de manière applicative. Les deux frameworks proposent non seulement des mécanismes prenant en charge ces aspects au travers de stratégies classiques de répartition (roundrobin ou aléatoire), mais également la possibilité de définir sa propre stratégie de répartition. Camel va un peu plus loin en permettant de paramétrer la stratégie de failover en fonction des exceptions détectées.
• La gestion transactionnelle Etre capable de définir les propriétés transactionnelles (délimitation, propagation) d’un échange peut s’avérer indispensable pour assurer l’intégrité des données dans le système. Camel aborde cette problématique en permettant d’ajouter le caractère transactionnel à une route en spécifiant ses paramètres à travers l’utilisation des gestionnaires de transaction Spring. Spring Integration a fait le choix de ne pas étendre la gestion des transactions telle qu’elle existe aujourd’hui pour l’adapter au contexte spécifique du développement de flux.

Le développement

Même si le produit propose des fonctionnalités avancées, il est indispensable que son utilisation soit simplifiée au maximum afin d’être efficace dans sa mise en oeuvre et sa maintenance.

• Evolutivité Si le framework ne propose pas toutes les fonctionnalités attendues, il faut qu’il offre la possibilité d’être étendu de manière simple. Les 2 solutions permettent, par implémentation d’interfaces spécifiques, de créer des nouveaux composants ou d’en améliorer les fonctionnalités. Pour Spring Integration il s’agit des MessageChannel et côté Camel des Endpoints ou des Components (voir http://camel.apache.org/writing-components.html).
• Outillage Ces frameworks sont jeunes et opensource, il n’est donc pas surprenant de ne pas encore trouver d’outillage adapté à leur utilisation. Sans être totalement dédié à Camel il existe cependant un produit proposé par FuseSource qui permet de définir graphiquement les échanges, disponible avec l’option de support de l’éditeur (http://fusesource.com/products/fuse-integration-designer/). Il faut noter également l’initiative opensource de James Strachan hébergée sur Google : Camel route viewer. Pour Spring Integration on ne trouve actuellement aucune solution de ce type.
• Approche – Complexité – Prise en main Si les objectifs des deux concurrents sont identiques, Spring propose une approche plutôt orientée outil (bottom-up) alors que Camel est foncièrement orienté échange (top-down). Les composants Camel sont de plus haut niveau fonctionnel que les composants offerts par Spring, permettant de définir en peu d’étapes des échanges relativement complexes. Avec Spring Integration, de nombreux patterns doivent être reconstruits à partir des éléments de base, complexifiant de fait la description des échanges, même dans des cas simples (ex: polling jdbc).
  Spring Integration reposant intégralement sur le framework Spring IOC, tous les éléments doivent être déclarés de manière explicite dans le fichier de contexte XML sous forme de beans, ce qui peut rapidement amener à des configurations ardues à décrypter. D’un autre côté, la connaissance préalable de Spring permet de rapidement mettre le pied à l’étrier aux nouveaux candidats à son utilisation. Camel propose 3 « langages » de définition des échanges : Scala, Java et Spring (appelés communément « Domain Specific Language » ou DSL). Le DSL Java est formé d’un ensemble d’API permettant de définir les flux au travers d’un code proche du langage naturel dans sa forme. C’est l’une de forces majeures du produit puisqu’il permet en quelque lignes de définir un échange de bout en bout incluant l’ensemble de ses caractéristiques (connectivité, contraintes, rejeu, gestion d’erreurs, formats). Cette approche permet de prototyper très rapidement les flux en relation directe avec la maîtrise d’ouvrage qui peut interpréter le fonctionnement du système par simple lecture du code. En outre, la définition des endpoints Camel passe par l’utilisation des URI qui apportent une réelle souplesse et une lisibilité accrue à la définition des échanges.
  Dans les deux cas, quelques jours de pratique permettent d’aborder rapidement les concepts de base des frameworks et de pouvoir les utiliser.

• Tests Une fois les flux définis, il convient de pouvoir les tester, par morceaux ou de bout en bout, de manière simple. Spring Integration n’offre pas de solution spécifique sur ce point, il est toujours possible de passer par les mécanismes classiques mais ceux-ci restent génériques. Camel en revanche propose des mécanismes de templates ou de mocksappropriés aux problématique d’échanges.

Conclusion

Globalement les 2 solutions présentées se valent en terme de fonctionnalité, de maturité et de pérennité. Les taux de pénétration sur le marché sont difficilement évaluables à l’heure actuelle et ne permettent pas de dégager une tendance claire en matière d’adoption.

En toute objectivité on ne peut toutefois pas rester indifférent à la simplicité de mise en oeuvre apportée par Camel grâce à son DSL java, à ses conversions implicites et à ses fonctions transverses telles que les politiques de rejeu, le BAM, la piste d’audit, les tests. On peu également considérer que le composant camel-springintegration fourni par Apache est un pied-de-nez à son concurrent direct, ou simplement une ouverture d’esprit…

Spring Integration intéressera forcément les aficionados du framework IOC idoine et c’est peut-être justement un point sur lequel l’éditeur pêche par excès : hors Spring point de salut. En outre, point abordé précédemment, la configuration des échanges par fichier XML peut très vite devenir difficile à maintenir et à interpréter.

Comme le dit Willy Antoine, architecte applicatif chez BNP Paribas – Personal Finance, à propos d’un vaste projet d’intégration de progiciels de gestion de crédits (plusieurs dizaines de milliers de JH) :

Le choix d’utiliser un framework d’intégration nous a permis de mettre en oeuvre une première phase du projet, alors que nous ne dispositions pas encore d’un ESB.  Ce type d’approche est un  premier pas vers le déploiement de la solution cible du groupe assurant une trajectoire simple et directe.

Notre choix c’est porté sur Apache Camel pour sa facilité d’apprentissage au  niveau des développements,  grâce au DSL permettant de décrire simplement les routes et à la documentation proposant une double approche:  EIP ou Composant. Le nombre de composants disponnibles nous permet de concentrer les développements sur les parties spécifiques au métier qui pourront être reprises lors de la mise en oeuvre du bus de communication. La proximité de Progress, spécialiste des solutions d’intégration, a également favorisé le choix de Camel pour l’assurance d’un support de qualité.

L’ouverture vers OSGI rassure des deux côtés quant à l’évolutivité des développements mis en place et leur éventuel intégration future dans une infrastructure de type ESB, bien que sur ce point encore Camel fasse un pas de plus avec l’intégration du standard JBI. Le reste est question de pratique et d’approche.

Liens et références

Sites officiels

• Apache Camel : http://camel.apache.org/
• Spring Integration : http://www.springsource.org/spring-integration

Livres Manning

• Spring Integration http://www.manning.com/fisher/
• Apache Camel http://www.manning.com/ibsen/

Support

• Spring http://www.springsource.com/services/enterprisesupport
• Progress http://www.progress.com/fr/support/index.ssp
• OpenLogic http://www.openlogic.com/products/open-source-support.php
• FuseSource http://fusesource.com/enterprise-support/support-offerings/

Tests, analyses

• http://java.dzone.com/articles/spring-integration-and-apache
• http://spring-java-ee.blogspot.com/2010/01/event-notification-framework-with.html

Stéphane Delplanque

Filed under: Articles Tagged: apache, camel, eip, integration, java, SOA, Spring, spring-integration, SpringSource