¿Cuándo usar Spring Integration vs. Camel?


138

Como usuario experimentado de Spring, suponía que Spring Integration tendría más sentido en un proyecto reciente que requiere algunas capacidades de mensajería (JMS) ( más detalles ). Después de algunos días trabajando con Spring Integration, todavía parece una gran sobrecarga de configuración dada la cantidad de canales que debe configurar para llevar a cabo algunas comunicaciones de solicitud-respuesta (escucha en diferentes colas JMS).

Por lo tanto, estaba buscando información de fondo sobre cómo Camel es diferente de Spring Integration, pero parece que la información que hay es bastante escasa, encontré:

La pregunta es: ¿qué experiencias hiciste al usar una pila sobre la otra? ¿En qué escenarios recomendaría Camel si Spring Integration carece de soporte? ¿Dónde ves los pros y los contras de cada uno? Cualquier consejo de proyectos del mundo real es muy apreciado.


55
Dada la integración absolutamente increíble que Camel tiene con Spring, no veo ninguna buena razón para siquiera mirar Spring Integration. Camel sobresale en cualquier área: concisa, intuitiva, poderosa, ... divertida. Puede lograr tanto con una sola línea de código, que a veces me siento culpable por no escribir suficiente código para justificar la funcionalidad.
Pavel Lechev

Respuestas:


75

Elegimos Camel sobre Spring-Integration porque la API fluida es realmente agradable. De hecho, lo usamos en proyectos de Spring y utilizamos Spring para configurar parte de él. Las API de programación son claras y hay un gran conjunto de componentes sensibles.

Hicimos un tiroteo a pequeña escala y básicamente en ese momento para nuestro requisito Camel ganó. Lo usamos principalmente para transferir archivos de datos internos a / desde terceros que generalmente requieren conversiones de formato enviándolo usando ftp / sftp / ... o adjuntándolo a un correo electrónico y enviándolo.

Encontramos el ciclo de edición-compilación-depuración reducido. El uso de groovy para experimentar la creación de rutas son bonos adicionales.

Spring-Integration también es un gran producto, y estoy bastante seguro de que también satisfará nuestras necesidades.


1
Gracias Peter por compartir tus puntos, ¿alguna vez intentaste usar las capacidades JMS de Camel, parece que los componentes respectivos también son bastante flexibles y tienen la misma riqueza que Spring Integration? ¿Por "tiroteo a pequeña escala" se refiere a mejores números de rendimiento?
ngeek

1
Tiroteo: fue principalmente el rendimiento del desarrollador. Nuestras necesidades de rendimiento no son muy altas. Sí, usamos mucho JMS como base. Tanto ActiveMQ como JBossMQ se usan para mensajería.
Peter Tillemans


67

Solo recomiendo Spring Integration si ya tiene un proyecto Spring y solo tiene que agregar alguna integración "básica" usando File, FTP, JMS, JDBC, etc.

Apache Camel tiene dos ventajas principales:

  1. Muchas, muchas más tecnologías son compatibles.
  2. Además, un (bueno) XML DSL, hay API fluidas para Java, Groovy y Scala.

Debido a que Apache Camel tiene una muy buena integración con Spring, incluso lo usaría en lugar de Spring Integration en la mayoría de los proyectos de Spring.

Si necesita más detalles, puede leer mis experiencias en la publicación de mi blog: Opciones para elegir: ¿Qué marco de integración usar? ¿Spring Integration, Mule ESB o Apache Camel?


31

Recientemente realicé un tiroteo Camel vs Spring Integration con el objetivo de integrar Apache Kafka . A pesar de ser un ávido desarrollador de Spring, lamentablemente encontré mi sospecha con la creciente pila de proyectos de Spring confirmada: Spring es increíble como IOC-Container para servir como pegamento para otro marco, pero falla al proporcionar alternativas viables a esos marcos . Puede haber excepciones a esto, es decir, todo lo que tiene que ver con MVC, de dónde proviene Spring y dónde hace un gran trabajo, pero otros intentos de proporcionar una nueva funcionalidad además de las características del contenedor se quedan cortos por tres razones y el caso de uso de SI Kafka confirma todos ellos:

  • Introducción de un DSL de largo aliento y difícil de usar para la configuración XML.
  • Páginas de código de configuración xml para conectar todos los componentes del framework.
  • Faltan recursos para proporcionar funcionalidad a la par con marcos dedicados.

Ahora, volviendo a los resultados de mi tiroteo: lo más importante es que estoy impresionado por el concepto general de rutas de Camels entre puntos finales . Kafka se integra a la perfección con este concepto y tres líneas de configuración son suficientes para poner todo en funcionamiento. Los problemas encontrados durante el proceso se abordan de manera clara mediante una amplia documentación del equipo del proyecto , así como muchas preguntas sobre Stackoverflow. Por último, pero no menos importante, hay una integración integral en Spring que no deja ningún deseo sin cumplir.

Con SI, por el contrario, la documentación para la integración de Kafka es bastante intensa y todavía no explica claramente cómo integrar Kafka. La integración de Kafka está presionada en la forma SI de hacer las cosas, lo que agrega complejidad adicional. Otra documentación, por ejemplo, en Stackoverflow también es menos abundante y menos útil que para Camel.

Mi conclusión: el zapatero se adhiere a su oficio: use Spring como contenedor y Camel como marco de integración del sistema.


3
¡Gracias, Fritz, por compartir tus experiencias! Estoy totalmente de acuerdo con sus observaciones: Camel es muy limpio con respecto a sus conceptos básicos, además de proporcionar un ecosistema de componentes viables para muchas tareas a mano (resp. Permite conectarse fácilmente si desea personalizar rutinas específicas).
ngeek

15

Realmente depende de lo que quieras hacer. Si necesita extender algo para construir su propia solución de mensajería, Spring Integration tiene el mejor modelo de programación. Si necesita algo que admita muchos protocolos sin código personalizado, Camel está por delante de Spring Integration.

Tener un tiroteo a pequeña escala es una muy buena idea, solo asegúrate de estar tratando de hacer el tipo de cosas que normalmente harías en el proyecto.

--descargo de responsabilidad: soy un integrador de Spring Integration


9

La mayoría de las comparaciones de Camel y SI que he visto no tienen en cuenta lo siguiente:

1.) El efecto que Spring Boot ha tenido en la productividad del desarrollador para Spring Integration

2.) El efecto de Spring XD ha tenido en hacer que las aplicaciones Spring Integration estén disponibles sin compilación de código; también las fuentes y sumideros Spring XD son simplemente adaptadores de canal Spring Integration, cuando se busca extender Spring XD.

3.) El efecto de Spring XD ha tenido en unificar Spring Integration, Spring Batch, Spring Data (+ Hadoop!) En una pila, trayendo efectivamente procesamiento por lotes y stream, soporte HDFS / Apache Hadoop y mucho más a Spring Integration.

4.) El efecto de Spring Integration 4.0 Java DSL que se lanzará próximamente https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

Por tu consideración,

/ Pieter (descargo de responsabilidad, trabajo en Pivotal)


3
Java DSL necesita mucho trabajo e incluso más documentación antes de tenerlo en cuenta.
cuttcards

Se lanzó hace un tiempo ... spring.io/blog/2014/11/24/…
Peter Szanto

6

Estamos utilizando Spring Integration para nuestra aplicación y ahora estamos considerando mudarnos a Apache Camel ya que encontramos muchos problemas con el marco de Spring Integration. Aquí hay un par de problemas.

  1. La CachingConnectionFactory que proporciona Spring abre miles de conexiones inactivas en IBM MQ y no hay garantía de que estas conexiones se reutilicen. Y aún así, estas conexiones permanecerán abiertas para siempre, lo que crea problemas en el lado de MQ. Tuve que reiniciar la aplicación todas las semanas en entornos inferiores solo para actualizar las conexiones. Apache Camel también proporciona almacenamiento en caché y las conexiones parecen subir / bajar según la carga.

  2. Spring no proporciona mapeadores para los parámetros de QoS. Incluso si habilita QoS, el modo de entrega y las propiedades de vencimiento / tiempo de espera se perderán (voy a plantear un problema de JIRA para esto). Apache Camel maneja esto y los parámetros de QoS se envían a aplicaciones ascendentes y no se descartan.

Ahora mismo estoy trabajando en problemas con el manejo de las excepciones y transacciones con Apache Camel que Spring parecía manejar mejor con AOP.


¿Hubo alguna configuración incorrecta que condujera a conexiones inactivas abiertas en IBM MQ?
Harpreet Sandhu - TheRootCoder

4

En realidad, diría que FTP ha graduado su período de incubación. Puede hacer una búsqueda simple en los foros de SI / JIRA para ver qué nuevas características se implementaron y qué errores se corrigieron. Según varias charlas, parece que ya hay algún uso de producción, por lo que sugeriría darle una segunda mirada y, por supuesto, comunicarnos sus preocupaciones a través de

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

Saludos Oleg

Descargo de responsabilidad: soy el integrador de Spring Integration


4

Apache Camel es un marco muy bueno y muy completo también. Pero si su aplicación usa Spring, mi consejo personal es usar Spring Integration.

Spring Integration es el marco de reclamación de integración EIP del ecosistema Spring-Source. Tiene una excelente integración con el ecosistema: Spring boot, Batch, XD; incluso el núcleo utiliza la misma abstracción a partir de Spring Framework 4. Algunas de las abstracciones de mensajería se movieron en el marco, como prueba de que la abstracción de mensajería básica de Spring Integration es muy fuerte. Ahora Spring framework, por ejemplo, usa la abstracción de mensajes para Spring Web, soporte de socket web.

Otra cosa buena en una aplicación Spring con integración Spring respecto al uso de Apache Camel es que con la integración Spring, puede usar solo un Contexto de aplicación. Recuerde que el contexto del camello es un contexto de primavera. Si tiene la posibilidad de usar una nueva versión de Spring, sugiero usar Spring Integration Java DSL para la configuración. Lo uso en mis nuevos proyectos, y se siente más legible y claro. Espero que esta reflexión pueda ayudarlo en sus evaluaciones.


1

Una razón para usar Camel over Spring Integration es cuando necesita un conjunto EIP más funcional. Spring Integration no proporciona abstracciones sobre cosas como ThreadPool.

Camel proporciona construcciones adicionales para esto, simplificando algunos de los aspectos del trabajo con código concurrente:

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

Si no necesita este tipo de cosas y solo desea conectar archivos, puntos finales JMS, FTP, etc., simplemente use Spring Integration.


2
Sí tiene una abstracción sobre los propios ThreadPools en los sondeos SI y los ejecutores de tareas de Spring. Sin embargo, nada está preconfigurado para usted OOTB en SI. Vea el ejecutor de tareas configurado aquí: static.springsource.org/spring-integration/docs/2.1.x/reference/…
cwash

@ Jon, ¿puedes echar un vistazo a mi post sobre JMS
alumno

-1

Camel actúa como middleware para aplicaciones donde uno puede realizar modelado de datos, transformación de valores de mensajes y coreografía de mensajes.


-3

Si su aplicación actual está en Spring y requiere características compatibles con Spring Integration of EIP, Spring Integration es la mejor opción; de lo contrario, necesitará más soportes de terceros / protocolos / formatos de archivo, etc.


Camel realmente tiene un gran soporte para Spring y cubre muchos componentes de terceros.
MikeHoss
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.