Apache Camel y otros productos ESB

Oye,
si tenemos Apache Camel, ¿por qué usar otras soluciones como Apache ServiceMix y Mule?
¿Hay algo que Apache Camel no pueda hacer en comparación con estos productos?
¿Cuándo usar Mule / ServiceMix y cuándo usar Camel?

Apache Camel es una biblioteca que implementa patrones de integración empresarial (EIP). Si bien puede usar Spring como su marco de IOC, ni siquiera depende de Spring, por lo que es completamente independiente de la plataforma. Es "solo" una biblioteca. Así que puede ejecutarlo en cualquier entorno JVM, por ejemplo, jvm simple, servlet, ejb, osgi. No trae con ninguno de los beneficios (o gastos generales) de un contenedor como Mule. En mi opinión, tiene una separación más clara de preocupaciones en esta área.

Mule también se puede integrar en diferentes entornos, pero creo que Mule tiene las ventajas y desventajas de acoplar su biblioteca EIP a su contenedor. Cuando despliegas Mule dentro de un entorno servlet o ejb, ¿realmente quieres llevar todo ese equipaje del contenedor Mule? No soy un experto en mulas, y creo que probablemente puedas dedicar una cantidad relativamente modesta de esfuerzo y limpiar parte de la capacidad redundante. (Tenga en cuenta que esta no es una mala capacidad en todos los casos, solo es redundante si está ejecutando incrustado dentro de otro contenedor).

Apache ServiceMix es un contenedor OSGI que usa Camel para implementar EIP como base de un ESB. Aunque ServiceMix históricamente comenzó con sus raíces en JBI, se ha alejado de JBI y se ha convertido en (IMO) una bonita arquitectura en capas que combina lo mejor de Apache CXF, Camel y ActiveMQ en un contenedor OSGI. El valor principal aquí no es realmente ServiceMix y su soporte JBI, sino el estándar de contenedor OSGI subyacentejunto con transportes Apache probados como CXF para servicios web y ActiveMQ para JMS. OSGI es un estándar maduro que ofrece un contenedor que se dirige a los mismos tipos de infierno "DLL" que plagaban a Microsoft antes de la llegada de .NET. Aunque ni .NET ni OSGI resuelven la complejidad esencial del problema subyacente, al menos proporcionan un medio para abordarlo. OSGI también tiene otros beneficios, pero desde la perspectiva de la selección de productos, el contenedor basado en estándares es primario, y su característica esencial que Mule (y Java en general) no aborda es la gestión de dependencias.

Algunas cosas importantes a tener en cuenta al comparar Mule con las comunidades Apache. Mule es como Redhat en el sentido de que, aunque es una licencia de código abierto, en mi opinión, no es una comunidad abierta. Cualquiera puede participar en Apache, mientras que MuleSoft posee la comunidad Mule y la hoja de ruta final. En segundo lugar, aunque se puede decir que la comunidad de Mule es bastante activa, creo que la comunidad de Apache es mucho más grande (y naturalmente, ya que no es una comunidad cerrada). Ambos enfoques tienen ventajas y desventajas. Un aspecto positivo del enfoque de Apache es que existen múltiples proveedores de ESB basados ​​en Camel, CXF, ActiveMQ y OSGI. Por ejemplo, Talend ofrece un ESB en las mismas tecnologías centrales sin el historial de ServiceMix JBI. Esto tiene ventajas y desventajas dentro de la comunidad Apache, pero el punto real es resaltar la diferencia entre Apache y Mule. No encontrará varios proveedores en la comunidad de Mule. Entonces, en mi opinión, un Apache ESB como Talend o ServiceMix es una comunidad más amplia, más inclusiva y, en última instancia, competitiva que una comunidad cerrada como Mule.

Ed Ost

Ahora estamos en 2016 y mucho ha cambiado desde que se hizo la pregunta inicialmente, así que me gustaría volver a visitarla para nuevos espectadores.

Estratégicamente hablando

• Apache Camel se ha mantenido fiel a sus raíces y no se ha convertido en una plataforma de tiempo de ejecución de peso pesado ni completa. Es versátil y modular, y puede ejecutar:

  1. Integrado en cualquier tipo de contenedor Java (contenedor de servlet, servidor de aplicaciones, Spring Boot).
  2. Independiente como un proceso de Java.
  3. Dentro de un entorno OSGi ( Apache Karaf ).

• Apache Camel ha seguido evolucionando y ganando tracción y actividad mensualmente, como se muestra en el gráfico bajo este punto que extraje de OpenHub . La base de usuarios también sigue aumentando.

• En 2012, Red Hat adquirió FuseSource , uno de los principales promotores y desarrolladores detrás de Apache Camel, ActiveMQ, ServiceMix y CXF. Red Hat emplea ahora a varios miembros de la PMC y de los confirmadores para trabajar en Apache Camel.

• Mule ESB ofrece dos versiones de su producto : Community (gratis bajo la licencia CPAL) y Enterprise (de pago). Definen su versión comunitaria como:

Ideal para evaluación o uso en preproducción.

=> Lo que significa que debe adquirir una suscripción empresarial paga para uso de producción.

• De hecho, Mule ESB Community Edition se distribuye bajo la licencia CPAL . Esto significa que si aún decides usar esta versión, Mule REQUIERE QUE :

  • Cada vez que se lanza o ejecuta inicialmente un código fuente y ejecutable o una obra más grande, debe aparecer una visualización destacada de la información de atribución de Mulesoft en la interfaz gráfica de usuario empleada por el usuario final para acceder a dicho código cubierto (que puede incluir la visualización en una pantalla de presentación). ), Si alguna. => Básicamente, necesitas anunciar que todo lo que hayas construido con Mule se está ejecutando en Mule.

  • Si se accede a su implementación de Mule ESB a través de la red (¡siempre lo hará, ya que es una plataforma de integración!), También debe hacer que la Fuente de su implementación esté disponible para quienes accedan a ella.

• Como alguien más mencionó anteriormente, Apache Camel es un proyecto completamente abierto e impulsado por la comunidad, para la comunidad . Todo el código fuente está disponible públicamente, y se anima a todos a enviar solicitudes de extracción, contribuir con componentes y ayudar o consultar en los foros. Por el contrario, la comunidad de Mule es una comunidad cerrada .

• Por último, si bien no menos importante; quizás la parte más importante. Esto es lo que Google Trends tiene que decir sobre Mule ESB frente a Apache Camel . Tenga en cuenta que estoy usando la nueva medición de temas semánticos para una mayor precisión en lugar de las palabras clave de consulta estándar . De esa forma no estamos midiendo la popularidad de los animales (Mule vs Camel), ¡sino del Software! Interpretación: Mule tuvo una fuerte tendencia a la baja desde 2007 hasta 2011, mientras que Apache Camel tuvo una tendencia al alza. Desde 2011, Mule se ha estancado, mientras que Apache Camel sigue mejorando de forma saludable.

Evolución técnica de Apache Camel

Solo quería brindarle algunas métricas funcionales sobre la evolución de Apache Camel desde el 25 de septiembre de 2010, cuando originalmente hizo la pregunta. Este era el árbol de origen en ese momento .

• En ese entonces, Camel tenía 88 componentes, ahora tiene 220 componentes que incluyen integraciones con Facebook, Twitter, Salesforce, Apache Ignite , Apache Cassandra , AWS, Apache Kafka , MongoDB, Apache Spark, etc.
• Muchas, muchas mejoras técnicas: motor de enrutamiento asíncrono, historial de mensajes, EIP de disyuntor, muchas, muchas mejoras y mejoras en EIP como agregación, división, enrutamiento dinámico, etc.
• El ecosistema ha crecido hasta incluir ahora también Hawtio para monitoreo y administración, fabric8 para implementación, etc.
• Desde entonces se han resuelto más de 5500 tickets que incluyen nuevas funciones, mejoras, errores, etc.
• ¡Y mucho, mucho más!

Notas finales

¡Ambos productos han evolucionado mucho en los últimos 5,25 años! Sin embargo, debido a la diferencia en las licencias y la naturaleza comunitaria de Mule ESB y Apache Camel, ya no creo que sean comparables entre sí.

Apache Camel es completamente de código abierto ❤️, mientras que Mule ESB Community requiere que los usuarios atribuyan Mulesoft y publiquen el código fuente del software que usa Mule. La licencia de software Apache es una licencia para empresas : puede utilizar Camel sin atribuciones ni otros requisitos. ¡Verdaderamente gratis como en la cerveza !

¡Espero que esta reflexión sobre los últimos años ayude a los nuevos espectadores! :)

Descargo de responsabilidad: soy un comprometido y miembro de PMC en el proyecto Apache Camel.

Mi publicación de blog responde exactamente a esta pregunta: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel es un marco de integración ligero, ServiceMix y así sucesivamente son ESB completos.

Camel es un motor de mediación, mientras que Mule es una plataforma de integración liviana. La diferencia es que Mule ofrece todas las capacidades de un ESB, incluido un contenedor para implementar aplicaciones, REST y servicios web. Mule puede integrarse de la misma manera que Camel para permitir a los desarrolladores de aplicaciones incrustar el código de la aplicación con su código de integración. Ambos se integran estrechamente con Spring.

Mule no usa JBI por buenas razones y ahora que la especificación de JBI se ha disuelto (ningún grupo de trabajo, propiedad de Oracle que pasó originalmente la especificación de JBI) no hay una buena razón profesional o técnica para usar JBI.

Hay algunas entradas de preguntas frecuentes en Apache Camel que arrojan algo de luz sobre esto http://camel.apache.org/faq

Y la colección de enlaces en Apache Camel http://camel.apache.org/articles.html

Tenga algunos enlaces donde la gente de la comunidad hable y compare Camel con otros proyectos.

Claus, hay una serie de errores en las preguntas frecuentes de Camel, como era de esperar, ninguno de ellos a nuestro favor :)

• el modelo UMO en Mule ya no está en Mule. Comenzamos a alejarnos de ese modelo en Mule 2 y se ha cambiado por completo en Mule 3. Ahora tenemos un modelo de procesador de mensajes muy simple que hace que su declaración al respecto sea redundante
• Mule ha tenido una conversión de tipo explícita durante algunos años, esto no es un diferenciador para Camel
• Mule tiene la licencia CPAL 1.0 aprobada por OSI . Esta es una licencia de código abierto, no comercial. Actualice esto lo antes posible

Primero debe comprender que Service Mix es como un contenedor que puede ejecutar el código Apache Camel y Mule ESB es un producto separado en sí mismo.

Puede haber muchas diferenciaciones que puede proporcionar entre los productos ESB.

Debe saber algunas cosas antes de buscar en la diferenciación. Son

1. Cómo se desarrollan los productos
2. Su licencia
3. Sus funciones de soporte
4. Código abierto o no
5. Si es de código abierto, se puede modificar y utilizar la fuente, etc.

Lo anterior será uno de los mejores factores que debe considerar antes de hacer una selección. Lo anterior es genérico para la mayoría de la selección de productos y también necesita atención especial aquí.

La diferencia del producto secundario será específica de las herramientas y su dominio. Esta es probablemente la respuesta que está buscando. Busque la lista que necesita hacer una introspección antes de hacer una selección.

1. Soporte comunitario
2. Pila de productos
3. Extensibilidad en términos de modificación de su propio código
4. Capacidad de aprendizaje y usabilidad
5. Soporte de producto cuando se compra como empresa

Esta es probablemente una investigación que debe realizar por su cuenta para seleccionar la diferencia. De cualquier manera, hay muchos valores agregados que hacen que el producto sea adecuado para su organización en lugar de decir lo mejor en el mercado.

Cuando se trata de Apache camel u Otro ESB. La diferencia que hará son

1. El número de transporte
2. Apache Camel le proporciona la variedad de DSL sobre Mule y otras son que no tienen DSL múltiple como en Camel.
3. Mule en su pila de productos contiene administración de API y conectores en la nube internos, donde Apache Camel es un marco cuando se tiene en cuenta FUSE ESB, JBoss Stack proporciona una cantidad decente de otros productos que pueden complementar su selección.