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 œuvre 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 deux 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.
Outillage
| La connaissance préalable de Spring permet de rapidement mettre le pied à l'étrier |
Ces frameworks sont jeunes et Open Source, 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. Il faut noter également l'initiative Open Source 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 un langage de définition des échanges proche du langage naturel |
Camel propose trois "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 mocks appropriés aux problématique d'échanges.
