¿Cuándo usar Spring Integration vs. Camel?

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

• http://java.dzone.com/articles/spring-integration-and-apache (Comparación muy neutral entre la implementación de un escenario de integración del mundo real en Spring Integration vs. Camel, desde diciembre de 2009)
• http://hillert.blogspot.com/2009/10/apache-camel-alternatives.html (Comparación de Camel con otras soluciones, octubre de 2009)
• http://raibledesigns.com/rd/entry/taking_apache_camel_for_a (Matt Raible, octubre de 2008)

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.

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.

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?

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.

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

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)

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.

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

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.

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.

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.

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.