No olvides que en la informática un error casi siempere puede tener más de una resoluciones, de igual modo nosotros aquí enseñamos lo más óptimo y mejor.
Solución:
Elegimos Camel en lugar de Spring-Integration porque la API fluida es realmente agradable. De hecho, lo usamos en proyectos de Spring y usamos 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, por nuestro requisito, Camel ganó. Lo usamos principalmente para transferir archivos de datos internos hacia/desde partes externas, lo que generalmente requiere conversiones de formato para enviarlos mediante ftp/sftp/… o adjuntarlos a un correo electrónico y enviarlos.
Encontramos que el ciclo editar-compilar-depurar se redujo. El uso de Groovy para experimentar con la configuración de rutas son bonificaciones 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 Archivo, FTP, JMS, JDBC, etc.
Apache Camel tiene dos ventajas principales:
- Se admiten muchas, muchas más tecnologías.
- Además, un (buen) 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: Spoiled for Choice: ¿Qué marco de integración usar: Spring Integration, Mule ESB o Apache Camel?
Recientemente llevé a cabo un tiroteo de Camel vs Spring Integration con el objetivo de integrar Apache Kafka. A pesar de ser un ávido desarrollador de Spring, lamentablemente encontré confirmada mi sospecha con la creciente pila de proyectos de Spring: 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, a saber, todo lo relacionado con MVC, de donde proviene Spring y donde hace un gran trabajo, pero otros intentos de proporcionar una nueva funcionalidad además de las características del contenedor no alcanzan. tres razones y el Caso de uso SI Kafka los confirma todos:
- Introducción de un DSL extenso y difícil de usar para la configuración de XML.
- Páginas de código de configuración xml para conectar todos los componentes del marco.
- 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 Camels 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 que todo esté en funcionamiento. Los problemas encontrados durante el proceso se abordan claramente con una amplia documentación del equipo del proyecto, así como con muchas preguntas sobre Stackoverflow. Por último, pero no menos importante, hay un integración completa en Spring que no deja deseos sin cumplir.
Con SI, por el contrario, la documentación para la integración de Kafka es bastante intensa y aún 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 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.
Si piensas que ha sido útil este artículo, agradeceríamos que lo compartas con otros juniors de este modo contrubuyes a difundir nuestro contenido.