Quand utiliser Spring Integration vs Camel?


138

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é:

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é.


5
Compte tenu de l'intégration absolument impressionnante de Camel avec Spring, je ne vois aucune bonne raison de regarder l'intégration de Spring. Camel excelle dans tous les domaines: concis, intuitif, puissant, ... amusant. Vous pouvez accomplir tellement de choses avec une seule ligne de code, que parfois je me sens coupable de ne pas avoir écrit suffisamment de code pour justifier la fonctionnalité.
Pavel Lechev

Réponses:


75

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.


1
Merci Peter d'avoir partagé vos points, avez-vous déjà essayé d'utiliser les capacités JMS de Camel, il semble que les composants respectifs sont également assez flexibles et ont la même richesse que Spring Integration? Par «fusillade à petite échelle», vous parlez de meilleurs chiffres de performance?
ngeek

1
Shootout: c'était principalement la performance des développeurs. Nos besoins de performance ne sont pas très élevés. Oui, nous utilisons beaucoup de JMS comme base. ActiveMQ et JBossMQ sont tous deux utilisés pour la messagerie.
Peter Tillemans


67

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?


31

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.


3
Merci, Fritz, de partager vos expériences! Je suis tout à fait d'accord avec vos observations: Camel est très propre en ce qui concerne ses concepts de base et fournit un éco-système de composants viables pour de nombreuses tâches à accomplir (resp. Permet de s'accrocher facilement si vous souhaitez personnaliser des routines spécifiques).
ngeek

15

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


9

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)


3
Java DSL nécessite beaucoup de travail et encore plus de documentation avant de pouvoir être pris en compte.
cuttcards

Il est sorti depuis un moment maintenant ... spring.io/blog/2014/11/24/…
Peter Szanto

6

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.


Y a-t-il eu une mauvaise configuration qui a conduit à l'ouverture de connexions inactives dans IBM MQ.
Harpreet Sandhu - TheRootCoder

4

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


4

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.


1

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.


2
Vous avez une abstraction sur les ThreadPools eux-mêmes dans les sondeurs SI et les exécuteurs de tâches de Spring. Rien n'est préconfiguré pour vous OOTB en SI cependant. Voir l'exécuteur de tâches configuré ici: static.springsource.org/spring-integration/docs/2.1.x/reference/…
cwash

@Jon, pouvez-vous s'il vous plaît jeter un oeil à mon message sur JMS
apprenant le

-1

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.


-3

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.


Camel a vraiment un excellent support pour Spring et couvre de nombreux composants tiers.
MikeHoss
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.