tutorial camel and esb apache-camel mule servicemix

and - Apache Camel y otros productos de ESB



apache camel store and forward (7)

Ahora es 2016 y han cambiado muchas cosas desde que se formuló la pregunta inicialmente, por lo que me gustaría volver a visitarla para los nuevos espectadores.

Estratégicamente hablando

  • Apache Camel se ha mantenido fiel a sus raíces y no se ha convertido en una plataforma de peso completo ni en una plataforma de tiempo completo. Es versátil y modular, y puede ejecutarse:

    1. Integrado en cualquier tipo de contenedor de Java (contenedor de servlets, 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 lo muestra el gráfico bajo este punto que OpenHub 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. Varios committers y miembros de PMC ahora están empleados por Red Hat para trabajar en Apache Camel.

  • Mule ESB ofrece dos versiones de su producto : Community (gratuito bajo la licencia CPAL) y Enterprise (pagado). Ellos definen su versión de comunidad como:

Ideal para evaluación o uso previo a la producción.

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

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

    • Cada vez que se inicia o ejecuta inicialmente un código fuente y ejecutable o un trabajo 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 visualización en una pantalla emergente ), Si alguna. => Básicamente, debe anunciar que todo lo que ha creado con Mule se ejecuta 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 el Origen de su implementación esté disponible para quien lo esté accediendo.

  • Como alguien más mencionado 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 Mule es una comunidad cerrada .

  • Por último, si bien no menos importante; tal vez la parte más importante. Esto es lo que Google Trends tiene que decir sobre Mule ESB vs. 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 esta forma, no estamos midiendo la popularidad de los animales (Mule vs Camel), ¡sino del software! Interpretación: Mule tuvo una fuerte tendencia desde 2007 hasta 2011, mientras que Apache Camel tuvo una tendencia ascendente. Desde 2011, Mule se ha estancado, mientras que Apache Camel sigue creciendo de manera saludable.

Evolución técnica de Apache Camel

Solo quería darle 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 fuente en ese momento .

  • En aquel 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, interruptor de circuito integrado EIP, muchas mejoras y mejoras a EIP como agregación, división, enrutamiento dinámico, etc.
  • El ecosistema ha crecido hasta ahora también incluye Hawtio para monitoreo y administración, fabric8 para implementación, etc.
  • Desde entonces, se han resuelto más de 5500 entradas , incluidas 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 de la comunidad de Mule ESB y Apache Camel, no creo que sean comparables entre sí.

Apache Camel es completamente de código abierto ❤️, mientras que la comunidad de Mule ESB requiere que los usuarios atribuyan Mulesoft y publiquen el código fuente del software que usa Mule. La licencia del software Apache es una licencia amigable para los negocios : usted es libre de usar Camel sin atribuciones ni ningún otro requisito. Verdaderamente libre como en la cerveza !

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

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

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 IOC, ni siquiera depende de Spring, por lo que es completamente independiente de la plataforma. Es "solo" una biblioteca. Por lo tanto, puede ejecutarlo en cualquier entorno JVM, por ejemplo, simple jvm, servlet, ejb, osgi. No incluye 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 puede integrarse en diferentes entornos, pero creo que Mule tiene las ventajas y desventajas de acoplar su biblioteca EIP a su contenedor. Cuando despliega Mule dentro de un entorno servlet o ejb, ¿realmente desea llevar todo ese equipaje del contenedor Mule? No soy un experto en Mule, y creo que probablemente pueda gastar una cantidad relativamente modesta de esfuerzo y eliminar parte de la capacidad redundante. (Tenga en cuenta que esta no es una mala capacidad en todos los casos, es simplemente redundante si se ejecuta incrustado dentro de otro contenedor).

Apache ServiceMix es un contenedor OSGI que utiliza 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 arquitectura en capas que combina los mejores Apache CXF, Camel y ActiveMQ en un contenedor OSGI. El principal valor aquí no es realmente ServiceMix y su soporte JBI, sino el estándar subyacente de contenedor OSGI acoplado a transportes Apache probados como CXF para servicios web y ActiveMQ para JMS. OSGI es un estándar maduro que ofrece un contenedor que aborda los mismos tipos de "DLL" que infestaban a Microsoft antes del advenimiento de .NET. Si bien 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 una perspectiva de selección de productos, el contenedor basado en estándares es el principal, y su característica esencial que Mule (y Java en general) no aborda es la gestión de la dependencia.

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 la comunidad Mule es muy activa, creo que la comunidad Apache es mucho más grande (y naturalmente, ya que no es una comunidad cerrada). Ambos enfoques tienen tanto ventajas como desventajas. Un aspecto positivo del enfoque de Apache es que hay varios proveedores para 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 tanto ventajas como desventajas dentro de la comunidad Apache, pero el verdadero objetivo es resaltar la diferencia entre Apache y Mule. No encontrará vendedores de múltiples filas en la comunidad Mule. Entonces, IMO, un ESB de Apache como Talend o ServiceMix es una comunidad más amplia, más inclusiva y, en última instancia, más competitiva que una comunidad cerrada como Mule.

Ed Ost

Camel es un motor de mediación, mientras que Mule es una plataforma de integración ligera. 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 incorporar el código de la aplicación con su código de integración. Ambos se integran estrechamente con Spring.

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

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. Estamos empezando a alejarnos de ese modelo en Mule 2 y se ha modificado por completo en Mule 3. Ahora tenemos un modelo de Procesador de mensajes muy simple que hace que su afirmación sea redundante.
  • Mule ha tenido una conversión de tipo explícita desde hace unos años, esto no es un diferenciador para Camel
  • Mule tiene licencia bajo la licencia aprobada CPI 1.0 de OSI . Esta es una licencia de código abierto no comercial. Por favor, actualice esto lo antes posible

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

Podría haber muchas diferencias que puede proporcionar entre los productos de ESB.

Debes saber algunas cosas antes de mirar en la diferenciación. Son

  1. Cómo se desarrollan los productos
  2. Su licencia
  3. Sus características de soporte
  4. Código abierto o no
  5. Si es de código abierto, la fuente puede ser modificada y utilizada, y así sucesivamente.

Lo anterior será un mejor factor que debe considerar antes de realizar 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 para las herramientas y su dominio. Es probable que sea la respuesta que está buscando. Encuentre la lista que necesita para introspección antes de hacer una selección.

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

Esta es probablemente una investigación que debe hacer por su cuenta para seleccionar la diferencia. De cualquier forma 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 te brinda 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 framework cuando se tiene en cuenta FUSE ESB. JBoss Stack proporciona una cantidad decente de otros productos que pueden complementar su selección.