2010-06-13 18 views
112

Como usuario Primavera sazonada estaba asumiendo que la primavera Integración tendría más sentido en un proyecto reciente que requieren algunas capacidades (JMS) mensajería (more details). Después de algunos días de trabajar con Spring Integration, todavía se siente como una gran cantidad de gastos de configuración dada la cantidad de canales que tiene que configurar para traer algunas comunicaciones de solicitud-respuesta (escuchar en diferentes colas JMS) en su lugar.Cuándo usar Spring Integration vs. Camel?

Por tanto, yo estaba buscando algo de información de cómo camello es diferente de Integración primavera, pero parece que la información ahí fuera son bastante libre, me encontré:

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

+1

Teniendo en cuenta la integración absolutamente increíble que Camel tiene con Spring, no veo ninguna buena razón para siquiera mirar Spring Integration. Camel se destaca en cualquier área: conciso, intuitivo, poderoso, ... divertido. Puede lograr mucho con una sola línea de código, que a veces me siento culpable por no escribir suficiente código para justificar la funcionalidad. –

Respuesta

57

Elegimos camello durante la primavera-Integración debido a que el API fluida es muy agradable. Realmente lo usamos en proyectos de primavera y usamos Spring para configurar una parte. 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 partes externas 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 de depuración reducida. Usar Groovy para experimentar la configuración de rutas se agrega bonificaciones.

Primavera-integración es un gran producto también, y estoy bastante seguro de que satisfacer nuestras necesidades también.

+1

Gracias Peter por compartir sus puntos. ¿Alguna vez intentó utilizar 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

Shootout: fue principalmente el rendimiento del desarrollador. Nuestras necesidades de rendimiento no son muy altas. Sí, usamos muchos JMS como base. Tanto ActiveMQ como JBossMQ se usan para mensajería. –

+0

¿Puedes echarle un vistazo https://stackoverflow.com/questions/46930494/camel-saves-full-http-request-but-i-want-only-attached-file? – gstackoverflow

13

Realmente dependo de lo que quieres hacer. Si necesita ampliar algo para crear 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 una tanda de pequeña escala es una muy buena idea, sólo asegúrese de que está tratando de hacer el tipo de cosas que normalmente estaría haciendo en el proyecto.

--disclaimer: Soy un confirmador Integración primavera

3

En realidad, yo diría 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 cuáles fueron corregidos.A partir de diversas charlas que parece que ya hay un cierto uso de producción fuera de él, así que te recomiendo darle una segunda mirada y por supuesto comunicar sus inquietudes a través de

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

Saludos Oleg

responsabilidad: soy integración primavera committer

57

solo recomiendo integración primavera si ya tiene un proyecto de primavera y que acaba de añadir un poco de usin "básica" de integración g Archivo, FTP, JMS, JDBC, etc.

Apache Camel tiene dos ventajas principales:

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

Como Apache Camel tiene una muy buena integración con Spring, incluso podría usarlo en lugar de Spring Integration en la mayoría de los proyectos de Spring.

Si necesita más información, puede leer mis experiencias en mi blog: Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel?

1

Una razón para utilizar camello sobre Integración primavera es cuando se necesita un conjunto EIP más featureful. Spring Integration no proporciona abstracciones sobre cosas como ThreadPool.

Camel proporciona construcciones adicionales para este simplificar algunos de los aspectos del trabajo con código concurrente:

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

Si no tiene necesidad de este tipo de cosas y simplemente desea conectar archivo, JMS, Puntos finales de FTP, etc. ... entonces simplemente use Spring Integration.

+2

Tiene una abstracción sobre ThreadPools en sí mismos en SI pollers y ejecutores de tareas de Spring. Sin embargo, no hay nada preconfigurado para usted OOTB en SI. Consulte el ejecutor de tareas configurado aquí: http://static.springsource.org/spring-integration/docs/2.1.x/reference/html/samples.html – cwash

+0

@Jon, ¿puede echar un vistazo a mi publicación en JMS – user3181365

-3

Si su aplicación actual es en primavera y requieren características que se apoyan en la primavera Integración de EIP continuación primavera integración es la mejor opción demás requieren más terceros soporta/protocolos/formatos de archivo, etc

+0

? Camel realmente tiene un gran soporte para Spring y cubre una gran cantidad de componentes de terceros. – MikeHoss

9

mayoría de las comparaciones de camello y SI que he visto no toman en cuenta lo siguiente:

1.) el efecto que la primavera de arranque ha tenido sobre la productividad del desarrollador para la primavera Integración

2.) el efecto de la primavera XD ha tenido en haciendo que las aplicaciones Spring Integration estén disponibles sin compilación de código, también Sp Las fuentes y sumideros XD de Ring son simplemente adaptadores de canal Spring Integration, cuando está buscando extender Spring XD.

3.) El efecto de la primavera XD ha tenido en la toma unificar primavera Integración, Spring Batch, Primavera de datos (+ Hadoop!) En una pila, con lo que efectivamente lotes y flujo de procesamiento, el apoyo HDFS/Apache Hadoop, y mucho más a la integración de primavera.

4.) El efecto de Spring Integration 4, que pronto se lanzará.0 de Java DSL https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

Para su consideración,

/Pieter (disclaimer Trabajo en Pivotal)

+3

Java DSL necesita mucho trabajo e incluso más documentación antes de que se tenga en cuenta. – cuttcards

+0

Se lanzó hace un tiempo ... https://spring.io/blog/2014/11/24/spring-integration-java-dsl-1-0-ga-released –

17

recientemente he realizado un camello vs Integración primavera tiroteo con el objetivo de integrar Apache Kafka. A pesar de ser un ávido desarrollador de Spring, lamentablemente encontré mi sospecha con la creciente pila Project Project de Spring confirmada: Spring es increíble como IOC-Container para servir como pegamento para otros frameworks, pero no proporciona alternativas viables to esos frameworks . Puede haber excepciones a esto, es decir, todo lo relacionado con MVC, de dónde viene Spring y dónde hace un gran trabajo, pero otros intentos de proporcionar una nueva funcionalidad sobre las características del contenedor son insuficientes para tres razones y SI Kafka caso de uso confirma todos ellos:

  • Introducción de un prolijo difícil de usar DSL para XML-configuración.
  • Páginas del código xml-configuration para conectar todos los componentes del framework.
  • Recursos faltantes para proporcionar funcionalidad a la par con marcos dedicados.

Ahora, de vuelta a los resultados de mi tanda de lo más importante: Estoy impresionado por Camellos concepto general de rutas 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 marcha. Los problemas encontrados durante el proceso son claramente tratados por ample documentation from the project team, así como muchas preguntas sobre Stackoverflow. Por último, pero no menos importante, existe una integración integral en Spring que no deja deseos sin cumplir.

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

Mi conclusión: zapatero se adhiere a tu comercio: utiliza Spring como contenedor y Camel como sistema de integración de sistemas.

+2

Gracias, Fritz, por compartir tu ¡experiencias! Estoy totalmente de acuerdo con sus observaciones: Camel es muy limpio con respecto a sus conceptos básicos, así como también proporciona un ecosistema de componentes viables para muchas tareas a mano (o permite engancharse fácilmente si desea personalizar rutinas específicas). – ngeek

1

Apache Camel es un muy buen marco y muy completo, pero si la aplicación utiliza la primavera, mi consejo personal es revertir a la integración de primavera. Spring Integration es el marco de quejas de integración EIP del ecosistema Spring-Source. Tiene una muy buena integración con el ecosistema: Spring boot, Batch, XD, incluso el núcleo utiliza la misma abstracción a partir de Spring Framework 4, parte de la abstracción de mensajes se movió en el marco como prueba de que la abstracción básica de mensajes de Spring Integration es muy fuerte, ahora Spring framework, por ejemplo, usa la mensajería abstracta para Spring Web, soporte de socket web. Otra cosa buena en una aplicación de Spring con integración de Spring respecto al uso de Apache Camel es que con la integración de Spring puede usar solo una aplicación Contecxt. Recuerde que el contexto de Camel es un contexto de primavera. si tiene la fortuna de usar una nueva versión de Spring, puedo sugerir el uso de Spring Integration java dsl para la configuración. Lo uso en mis nuevos proyectos y me siento más legible y claro.

espero que este reflectin que puede ayudar a las evaluaciones de sus

2

Estamos utilizando Integración de primavera para nuestra aplicación y ahora están considerando mudarse a Apache Camel como nos encontramos con un montón de problemas con el marco de la integración de primavera. Aquí hay un par de problemas.

  1. El CachingConnectionFactory la que se abre un resorte que proporciona 1000 de las conexiones inactivas en IBM MQ y no hay ninguna garantía de que estas conexiones se vuelven a utilizar. Y aún estas conexiones permanecerán abiertas para siempre, lo que crea problemas en el lado de MQ. Tuve que reiniciar la aplicación cada semana en entornos más bajos solo para actualizar las conexiones. Apache Camel también proporciona almacenamiento en caché y las conexiones parecen subir/bajar según la carga.

  2. El muelle no proporciona mapas para los parámetros de QoS. Incluso si habilita la QoS, el modo de entrega y las propiedades de caducidad/timetolive se perderán (plantearé un problema JIRA para esto). Apache Camel maneja esto y los parámetros de QoS se envían a aplicaciones en sentido ascendente 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.

Cuestiones relacionadas