Spring Integration vs Apache Camel

En savoir plus

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é

Camel embarque plus de 90 composants de 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, quel que 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.

Les deux frameworks permettent de définir sa propre stratégie de répartition de charge

 

 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.

Autour du même sujet
JDN Développeur Haut de page
A VOIR EGALEMENT