Quand utiliser Spring Integration vs Camel?
En tant qu'utilisateur expérimenté de Spring, je pensais que l'intégration de Spring serait plus logique dans un projet récent nécessitant des fonctionnalités de messagerie (JMS) ( plus de détails ). Après quelques jours d'utilisation de Spring Integration, la charge de configuration liée à la charge de configuration nécessaire pour mettre en place des communications demande-réponse (écoute sur différentes files d'attente JMS) reste importante.
Par conséquent, je cherchais des informations générales sur la façon dont Camel se différenciait de Spring Integration, mais il me semble que les informations disponibles sont assez épargnées. J'ai constaté:
- 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 réelle dans Spring Integration vs. Camel, à partir de décembre 2009)
- http://hillert.blogspot.com/2009/10/Apache-camel-alternatives.html (Comparaison de Camel avec d'autres 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 l’une sur l’autre? Dans quels scénarios recommanderiez-vous Camel si Spring Integration manquait de soutien? Où voyez-vous les avantages et les inconvénients de chacun? Tous les conseils de projets du monde réel sont très appréciés.
Nous avons choisi Camel plutôt que Spring-Integration parce que l’API fluide est vraiment agréable. 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à, notre exigence a été remportée par Camel. 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 une conversion de format, en l'envoyant via ftp/sftp/... ou en l'attachant à un courrier électronique et en l'envoyant.
Nous avons trouvé le cycle édition-compilation-débogage réduit. L'utilisation de groovy pour expérimenter la configuration d'itinéraires est un bonus supplémentaire.
Spring-Integration est également un excellent produit, et je suis sûr qu'il satisferait également nos besoins.
Je ne recommande l'intégration de Spring que si vous avez déjà un projet Spring et qu'il vous suffit d'ajouter une intégration "de base" à l'aide de Fichier, FTP, JMS, JDBC, etc.
Apache Camel présente deux avantages principaux:
- Beaucoup, beaucoup plus de technologies sont supportées.
- Outre un (bon) XML DSL, il existe des API fluides pour Java, Groovy et Scala.
Apache Camel étant très bien intégré à Spring, je l’utiliserais même si Intégration de Spring était intégrée à 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 framework d'intégration utiliser - Intégration de Spring, Mule ESB ou Apache Camel?
J'ai récemment mené une fusillade Camel vs Spring Integration dans le but d'intégrer Apache Kafka . Malgré le fait que je suis un passionné de développement Spring, j’ai tristement trouvé ma suspicion face à la pile de projets grandissante de Spring: Spring est génial en tant que IOC-Container qui sert de colle à d’autres frameworks, alternatives viables à ces cadres . Il peut y avoir des exceptions à cette règle, à savoir tout ce qui concerne MVC, l’origine et la qualité de Spring, mais d’autres tentatives visant à fournir de nouvelles fonctionnalités au-dessus des fonctionnalités de conteneur sont un raccourci pour Trois raisons et le cas d'utilisation SI Kafka ) les confirme toutes:
- Introduction d'un DSL difficile à utiliser pour la configuration XML.
- Pages de code de configuration XML pour obtenir tous les composants de l'infrastructure câblés.
- Ressources manquantes pour fournir des fonctionnalités comparables à celles des frameworks dédiés.
Revenons maintenant aux résultats de ma fusillade: je suis surtout impressionné par le concept général de Camels de routes 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 ne documentation détaillée fournie par l'équipe de projet et beaucoup de questions sur Stackoverflow Enfin, il existe une intégration complète dans Spring qui ne laisse aucun souhait inassouvi.
Au contraire de SI, la documentation de l'intégration Kafka est assez intense et ne permet toujours pas d'expliquer clairement comment intégrer Kafka. L'intégration de Kafka est enfoncé dans la manière de procéder du SI, ce qui ajoute à la complexité. D'autres documents, par exemple sur Stackoverflow, sont également moins nombreux et moins utiles que pour Camel.
Ma conclusion: Cobbler s'en tient à votre métier - utilisez Spring comme conteneur et Camel comme infrastructure d'intégration système.
Je dépend vraiment de ce que vous voulez faire. Si vous avez besoin de développer 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 supporte de nombreux protocoles sans code personnalisé, Camel devance Spring Integration.
Avoir une séance de tir à petite échelle est une très bonne idée, assurez-vous simplement que vous essayez de faire le genre de choses que vous feriez normalement dans le projet.
--disclaimer: Je suis un committer de Spring Integration
La plupart des comparaisons de Camel et de SI que j'ai vues ne tiennent pas compte des éléments suivants:
1.) Effet de Spring Boot sur la productivité des développeurs pour Spring Integration
2.) Spring XD a eu pour effet de rendre les applications Spring Integration disponibles sans compilation de code - les sources et les puits Spring XD sont simplement des adaptateurs de canal Spring Integration, lorsque vous souhaitez étendre Spring XD.
3.) L’effet de Spring XD a eu pour effet de regrouper dans une seule pile Spring Integration, Spring Batch, Spring Data (+ Hadoop!) Unificateur, ce qui permet de traiter efficacement les traitements par lots et de flux, la prise en charge HDFS/Apache Hadoop et bien d’autres encore.
4.) L’effet de l’intégration prochaine de Spring Integration 4.0 Java DSL https://github.com/spring-projects/spring-integration-extensions/ wiki/Spring-Integration-Java-DSL-Reference
Pour votre considération,
/ Pieter (disclaimer je travaille chez Pivotal)
Nous utilisons Spring Integration pour notre application et envisage maintenant de migrer vers Apache Camel, car nous avons rencontré de nombreux problèmes avec la structure Spring Integration. Voici quelques problèmes.
CachingConnectionFactory fourni par Spring ouvre 1 000 connexions inactives dans IBM MQ et rien ne garantit que ces connexions sont réutilisées. Et toujours ces connexions resteront ouvertes pour toujours, ce qui crée des problèmes du côté MQ. J'ai dû redémarrer l'application chaque semaine dans des environnements inférieurs pour actualiser les connexions. Apache Camel fournit également la mise en cache et les connexions semblent monter/descendre en fonction de la charge.
Spring ne fournit pas de mappeurs pour les paramètres QoS. Même si vous activez la QoS, le mode de livraison et les propriétés d'expiration/durée seront perdus (je vais soulever un problème JIRA pour cela). Apache Camel gère cela et les paramètres de QoS sont envoyés aux applications en amont sans être abandonnés.
Je travaille actuellement sur des problèmes liés au traitement 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 effectuer une recherche simple sur les forums SI/JIRA pour voir quelles nouvelles fonctionnalités ont été implémentées et quels bogues ont été corrigés. Divers bavardages semblent indiquer qu’il existe déjà quelques utilisations de la production. Je suggère donc de jeter 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
A bientôt Oleg
Clause de non-responsabilité: je suis responsable de l'intégration printanière
Apache Camel est un très bon framework et très complet aussi. Mais si votre application utilise Spring, mon conseil personnel consiste à utiliser Spring Integration.
Spring Integration est le cadre de plainte d'intégration 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 abstractions de messagerie ont été déplacées dans le framework, ce qui prouve que l'abstraction de base de Spring Integration est très forte. Maintenant, par exemple, Spring Framework utilise l'abstraction de messagerie pour Spring Web, prise en charge des sockets Web.
Une autre bonne chose dans une application Spring avec l'intégration de Spring en ce qui concerne l'utilisation d'Apache Camel est qu'avec l'intégration Spring, vous ne pouvez utiliser qu'un seul contexte d'application. Rappelez-vous que le contexte Camel est un contexte Spring. Si vous avez la possibilité d’utiliser une nouvelle version de Spring, je vous suggère d’utiliser Spring Integration Java DSL pour la configuration. Je l’utilise dans mes nouveaux projets. Il est plus lisible et plus clair. J'espère que cette réflexion peut vous aider pour vos évaluations.
Une des raisons d'utiliser l'intégration de Camel over Spring est lorsque vous avez besoin d'un ensemble EIP plus complet. Spring Integration ne fournit pas d'abstractions sur des choses telles que ThreadPool.
Camel fournit des constructions supplémentaires pour simplifier certains aspects du travail avec du code concurrent:
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 des fichiers, des points de terminaison JMS, FTP, etc., utilisez simplement Spring Integration.
Camel agit comme un middleware pour une application permettant de modéliser des données, de transformer des valeurs de message et de créer une chorégraphie de messages.