¿Cómo se debe empaquetar/implementar un ESB?

Question

Estoy tratando de entender a Apache Camel, que parece ser un ESB liviano. Si entiendo los Camel/ESB correctamente, entonces puedes pensar en una Camel Route como un gráfico de nodos y bordes. Cada nodo es un punto final en la ruta (puede consumir/producir mensajes). Cada borde es una ruta entre dos puntos finales diferentes (1 productor y 1 consumidor).

Asumiendo que es correcto, tengo una pregunta práctica: ¿qué dictan las mejores prácticas sobre la implementación de la ruta ESB/Camel de su aplicación? ¿Debo empaquetarlo como su propio JAR, o es digno de ser su propio EAR lleno de EJB, servicios web y otros JAR?

Creo que estoy preguntando cómo una ruta camello o ESB deben desplegarse/Architected, como:

my-esb.ear/ 
    ejb1.jar/ 
     MyEJB_1.class 
    ejb2.jar/ 
     MyEJB_2.class 
    webservice.war/ 
     MyWebService.class 

O ...

my-esb.jar/ 
    MyEJB_1.class 
    MyEJB_2.class 
    MyWebService.class 

Answer 1

Según mi entender, hay un par de formas en que puede ejecutar Camel.

1. insertado en una aplicación Java: Puede incrustar camello en una aplicación Java independiente. En este escenario, comenzaría un Contexto de Camel dentro de su aplicación que iniciará las rutas, etc. Esto es excelente cuando su aplicación necesita comunicarse con servicios, etc. Para que esto funcione, deberá desplegar las jarras Camel y de terceros para los componentes. la ruta de clases

2. Integrado en una aplicación web: Como ya se ha señalado, esta opción parece ser una opción popular. Los frascos de Camel y los frascos de terceros están envueltos en un archivo WAR y esencialmente implementados en un contenedor web como Tomcat para alojar los servicios de Camel.

3. incrustado en un servidor de aplicaciones: He leído algún artículo sobre cómo implementar camello a un servidor de aplicaciones como JBoss e incluso he leído acerca de las personas que despliegan a Glassfish. Esto parece muy similar en cómo se implementa en Tomcat. JBoss tiene algunos problemas de carga de clases que necesitarías abordar, lo que lo hace complicado. Entonces, sí, puede implementar en un servidor de aplicaciones yendo por la ruta de WAR.

4. Implementar en OSGi: Usted puede hacer su camello jar un paquete OSGi con relativa rapidez y desplegar a un marco OSGi como Apache Felix. Es relativamente simple convertir el jar a un paquete OSGi apropiado y luego implementarlo. El gran problema aquí es que algunos terceros pueden no tener paquetes compatibles con OSGi para su implementación.

Mi preferencia personal es la ruta OSGi. Es fácil y liviano y me permite alojar mis rutas en camello como servicios persistentes (es decir, servicio de ventana, Unix Deamon) con una huella muy pequeña.

Lo que debe saber ahora es que Apache Camel se puede implementar de varias maneras y usted decide cómo quiere hacerlo. Me tomó un tiempo entender cómo implementar Camel ya que tuve que jugar con los diferentes modelos de implementación para sentirme bien. El único que no he tocado fue el despliegue en un Servidor de Aplicaciones, ya que sentí que la mayoría de estos Servidores son lo suficientemente pesados.

En lo que a arquitectura se refiere, me gusta mantener mis diferentes rutas/aplicaciones en diferentes contenedores. Como uso OSGi, me gusta poder actualizar una ruta específica e implementarla sin tener que volver a implementar todo. Si desplegó todo en un contenedor, necesitaría derribar el mundo para reconstruir y volver a implementar el contenedor. Sin embargo, esta es una preferencia personal y su kilometraje puede variar

Espero que esto ayude un poco.

Answer 2

Eso depende de sus necesidades. No hay una única respuesta de verdad que sea mejor.

Camel se puede adaptar a su infraestructura existente y plataforma de tiempo de ejecución. Así que empaquete sus aplicaciones con Camel incrustado de la forma en que esta plataforma puede hacerlo, y de la manera que usted lo desee.

Por ejemplo, para utilizar camello en una aplicación web (WAR) se puede ver en este enlace: http://camel.apache.org/tutorial-on-using-camel-in-a-web-application.html

Answer 3

Usted está considerando la incorporación de .ear, veo.

Te recomendaría que lo pienses dos veces antes de incluir Camel en un servidor Java EE con todas las funciones. Sin duda es factible, pero obtendrá algo de trabajo para conectarlos (con commonJ, WorkManagers, referencias JNDI, etc.). Específicamente, dejar que Camel maneje el roscado es una gran ventaja.

Incrustar Camel dentro de una aplicación web de primavera (.WAR) es mi favorito personal para implementar en Jetty o Tomcat. A continuación, tiene acceso a un contenedor servlet decente, un tiempo de ejecución que puede hacer algunas cosas, etc.

En realidad, he utilizado la descarga estándar de ActiveMQ en algunos entornos de producción con el Camel integrado, más para fines de adaptador y no tanto ESB, pero aún así, podría ser una opción válida si ActiveMQ es la columna vertebral de mensajería de su ESB.

Answer 4

Como en las otras respuestas, depende de sus necesidades, pero un ESB suele ser una combinación de diferentes procesos de integración que no necesariamente comparten el mismo ciclo de vida.

Si este es su caso, le sugiero usar un jar por enfoque de proceso de integración. De esta forma, puede tener diferentes ciclos de vida de desarrollo para cada uno de los diferentes jar y puede asegurarle a su cliente que no ha tocado ninguno de los códigos excepto el que está en ese jar.

Esto no significa que tenga que ir con la solución ear. Puede empaquetar perfectamente el código para sus diferentes procesos en un archivo war sin la sobrecarga ear.

Answer 5

Permítanme responder a sus preguntas una por una:

Proporciona una lista descriptiva, no vaga de factores generales que deben ser utilizados para determinar cómo implementar mejor un ESB (ya sea como un solo oído con cada punto final siendo un JAR incrustado o como un solo "monolítico" JAR);

Embeded o Monolithic jar no es importante. Lo que importa es la implementación de Bundled o war. En el caso de un paquete independiente puede terminar con un archivo de implementación muy grueso que tenga muchos contenedores para la resolución de la dependencia.

explica completamente por qué camello podría no jugar muy bien con la aplicación Java EE servidores como JBoss o GlassFish

1. Tema/Recursos/Gestión de Puertos del App-servidor/contenedor puede imponer restricciones.

2. Conflicto de uso común Versión Biblioteca

3. Conflicto en el mecanismo de carga de clases

Lógicamente, si el contenedor OSGi apoya entonces camello no debe hacer frente a cualquier problema.

1. Como Apache Camel es un mensaje muy ligera router, para que puedas sin duda se pueden agrupar en su oído junto con su aplicación web como un archivo guerra. Si está utilizando maven/Ivy y su contenedor web es compatible con osgi, entonces ¡Bingo! La vida será mucho más fácil.
2. La segunda opción es para implementar la aplicación como un paquete
3. y otro es independiente tarro de Java SE.

siga los siguientes enlaces [Sin embargo, lo suficientemente que ha sido superado], los que le dará paso a paso la dirección de embalaje, por lo menos-claridad sobre el mecanismo de empaquetamiento:

Camel Step By Step

Camel in a Web Application

Camel Real Life Packaging & Deployment in OSGi environment