Quand utiliser Spring Integration vs Camel?

En tant qu'utilisateur chevronné de Spring, je supposais que Spring Integration serait le plus logique dans un projet récent nécessitant des capacités de messagerie (JMS) ( plus de détails ). Après quelques jours de travail avec Spring Integration, vous ressentez toujours beaucoup de surcharge de configuration compte tenu du nombre de canaux que vous devez configurer pour mettre en place des communications requête-réponse (écoute sur différentes files d'attente JMS).

Par conséquent, je cherchais des informations générales sur la façon dont Camel est différent de Spring Integration, mais il semble que les informations disponibles soient assez rares, j'ai trouvé:

• http://java.dzone.com/articles/spring-integration-and-apache (Comparaison très neutre entre la mise en œuvre d'un scénario d'intégration dans le monde réel dans Spring Integration vs Camel, à partir de décembre 2009)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Comparing Camel with other solutions, octobre 2009)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, octobre 2008)

La question est: quelles expériences avez-vous faites en utilisant une pile plutôt qu'une autre? Dans quels scénarios recommanderiez-vous Camel si Spring Integration manque de support? Où voyez-vous les avantages et les inconvénients de chacun? Tout conseil de projets réels est très apprécié.

Nous choisissons Camel plutôt que Spring-Integration car l'API fluide est vraiment sympa. Nous l'utilisons en fait dans les projets Spring et utilisons Spring pour en configurer une partie. Les API de programmation sont claires et il existe un grand nombre de composants sensibles.

Nous avons fait une fusillade à petite échelle et à ce moment-là, pour notre exigence, Camel a gagné. Nous l'utilisons principalement pour transférer des fichiers de données internes vers / depuis des parties externes, ce qui nécessite généralement des conversions de format en les envoyant à l'aide de ftp / sftp / ... ou en les joignant à un e-mail et en l'envoyant.

Nous avons trouvé le cycle d'édition-compilation-débogage réduit. Utiliser groovy pour expérimenter la configuration d'itinéraires est un bonus supplémentaire.

Spring-Integration est également un excellent produit et je suis convaincu qu'il répondra également à nos besoins.

Je ne recommande Spring Integration que si vous avez déjà un projet Spring et que vous n'avez qu'à ajouter une intégration "basique" en utilisant File, FTP, JMS, JDBC, etc.

Apache Camel présente deux avantages principaux:

1. De nombreuses autres technologies sont prises en charge.
2. En plus, un (bon) XML DSL, il existe des API fluides pour Java, Groovy et Scala.

Parce qu'Apache Camel a une très bonne intégration avec Spring, je l'utiliserais même à la place de Spring Integration dans la plupart des projets Spring.

Si vous avez besoin de plus de détails, vous pouvez lire mes expériences dans mon article de blog: L' embarras du choix: quel cadre d'intégration utiliser - Spring Integration, Mule ESB ou Apache Camel?

J'ai récemment mené une fusillade Camel vs Spring Integration dans le but d'intégrer Apache Kafka . En dépit d'être un développeur passionné de Spring, j'ai malheureusement trouvé mes soupçons à l'égard de la pile de projets toujours croissante de Spring confirmée: Spring est génial en tant que conteneur IOC pour servir de colle pour d'autres frameworks, mais il ne parvient pas à fournir des alternatives viables à ces frameworks . Il peut y avoir des exceptions à cela, à savoir tout ce qui a trait à MVC, d'où vient Spring et où il fait un excellent travail, mais d'autres tentatives pour fournir de nouvelles fonctionnalités en plus des fonctionnalités du conteneur échouent pour trois raisons et le cas d'utilisation de SI Kafka le confirme tous:

• Introduction d'un DSL long et difficile à utiliser pour la configuration XML.
• Pages de code de configuration xml pour connecter tous les composants du framework.
• Ressources manquantes pour fournir des fonctionnalités à la hauteur des frameworks dédiés.

Maintenant, revenons aux résultats de ma fusillade: surtout, je suis impressionné par le concept global des itinéraires de Camels entre les points d'extrémité . Kafka s'intègre parfaitement à ce concept et trois lignes de configuration suffisent pour que tout soit opérationnel. Les problèmes rencontrés au cours du processus sont parfaitement traités par une documentation abondante de l'équipe de projet ainsi que par de nombreuses questions sur Stackoverflow. Enfin, il existe une intégration complète dans Spring qui ne laisse aucun souhait insatisfait.

Avec SI au contraire, la documentation de l'intégration de Kafka est assez intense et ne parvient toujours pas à expliquer clairement comment intégrer Kafka. L'intégration de Kafka est pressée dans la manière SI de faire les choses, ce qui ajoute une complexité supplémentaire. D'autres documentations, par exemple sur Stackoverflow, sont également moins abondantes et moins utiles que pour Camel.

Ma conclusion: le cordonnier reste fidèle à votre métier - utilisez Spring comme conteneur et Camel comme cadre d'intégration système.

Cela dépend vraiment de ce que vous voulez faire. Si vous avez besoin d'étendre quelque chose pour créer votre propre solution de messagerie, Spring Integration a le meilleur modèle de programmation. Si vous avez besoin de quelque chose qui prend en charge de nombreux protocoles sans code personnalisé, Camel est en avance sur Spring Integration.

Avoir une fusillade à petite échelle est une très bonne idée, assurez-vous simplement que vous essayez de faire le type de choses que vous faites généralement dans le projet.

--disclaimer: Je suis un committer Spring Integration

La plupart des comparaisons de Camel et de SI que j'ai vues ne prennent pas en compte les éléments suivants:

1.) L'effet que Spring Boot a eu sur la productivité des développeurs pour Spring Integration

2.) L'effet de Spring XD a eu pour effet de rendre les applications Spring Integration disponibles sans compilation de code - les sources et les récepteurs Spring XD sont également simplement des adaptateurs de canal Spring Integration, lorsque vous cherchez à étendre Spring XD.

3.) L'effet de Spring XD a eu sur l'unification de Spring Integration, Spring Batch, Spring Data (+ Hadoop!) Dans une seule pile, apportant efficacement le traitement par lots et en flux, la prise en charge HDFS / Apache Hadoop, et bien plus encore à Spring Integration.

4.) L'effet du DSL Java Spring Integration 4.0 qui sortira prochainement https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

Pour votre considération,

/ Pieter (avertissement Je travaille chez Pivotal)

Nous utilisons Spring Integration pour notre application et envisageons maintenant de passer à Apache Camel car nous avons rencontré de nombreux problèmes avec le framework Spring Integration. Voici quelques problèmes.

1. La CachingConnectionFactory fournie par Spring ouvre des milliers de connexions inactives dans IBM MQ et il n'y a aucune garantie que ces connexions soient réutilisées. Et ces connexions resteront ouvertes pour toujours, ce qui crée des problèmes du côté de MQ. J'ai dû redémarrer l'application chaque semaine dans des environnements inférieurs juste pour actualiser les connexions. Apache Camel fournit également la mise en cache et les connexions semblent augmenter / diminuer en fonction de la charge.

2. Spring ne fournit pas de mappeurs pour les paramètres QoS. Même si vous activez QoS, le mode de livraison et les propriétés d'expiration / timeolive seront perdus (je vais soulever un problème JIRA pour cela). Apache Camel gère cela et les paramètres QoS sont envoyés aux applications en amont et ne les abandonnent pas.

Je travaille actuellement sur des problèmes de gestion des exceptions et des transactions avec Apache Camel que Spring semblait mieux gérer avec AOP.

En fait, je dirais que FTP a gradué sa période d'incubation. Vous pouvez faire une simple recherche sur les forums SI / JIRA pour voir quelles nouvelles fonctionnalités ont été implémentées et les bogues qui ont été corrigés. À partir de divers bavardages, il semble qu'il y ait déjà une utilisation en production, alors je suggérerais de lui donner un second regard et bien sûr de nous faire part de vos préoccupations via

http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT

Vive Oleg

Clause de non-responsabilité: je suis un commetteur Spring Integration

Apache Camel est un très bon framework et très complet aussi. Mais si votre application utilise Spring, mon conseil personnel est d'utiliser Spring Integration.

Spring Integration est le cadre d'intégration de plaintes EIP de l'écosystème Spring-Source. Il a une excellente intégration avec l'écosystème: Spring boot, Batch, XD; même le noyau utilise la même abstraction à partir de Spring Framework 4. Certaines des abstractions de messagerie ont été déplacées dans le framework, comme preuve que l'abstraction de messagerie de base de Spring Integration est très forte. Maintenant, le framework Spring, par exemple, utilise l'abstraction de messagerie pour Spring Web, le support de socket Web.

Une autre bonne chose dans une application Spring avec l'intégration Spring par rapport à l'utilisation d'Apache Camel est qu'avec l'intégration Spring, vous ne pouvez utiliser qu'un seul contexte d'application. N'oubliez pas que le contexte de chameau est un contexte de printemps. si vous avez la possibilité d'utiliser une nouvelle version de Spring, je suggère d'utiliser Spring Integration Java DSL pour la configuration. Je l'utilise sur mes nouveaux projets, et c'est plus lisible et plus clair. J'espère que cette réflexion pourra vous aider pour vos évaluations.

Une des raisons d'utiliser Camel sur Spring Integration est lorsque vous avez besoin d'un ensemble EIP plus fonctionnel. Spring Integration ne fournit pas d'abstractions sur des éléments tels que ThreadPool.

Camel fournit des constructions supplémentaires pour simplifier certains des aspects du travail avec du code simultané:

http://camel.apache.org/camel-23-threadpool-configuration.html

Si vous n'avez pas besoin de ce genre de chose et que vous souhaitez simplement connecter un fichier, des points de terminaison JMS, FTP, etc., utilisez simplement Spring Integration.

Camel agit comme un middleware pour l'application où l'on peut effectuer la modélisation des données, la transformation des valeurs de message et la chorégraphie des messages.

Si votre application actuelle est au printemps et nécessite des fonctionnalités prises en charge par Spring Integration d'EIP, Spring Integration est la meilleure option, sinon nécessite plus de supports / protocoles / formats de fichiers tiers, etc.