java - example - jms receiver

Middleware y SOA por ejemplo

Question

Soy un desarrollador de Java sin experiencia que trata de comprender algunos conceptos y tecnologías fundamentales de middleware / SOA, específicamente:

• Arquitectura Orientada a Servicios (SOA)
• Middleware orientado a mensajes (MOM)
• Cola de mensajes
• Camel Apache
• Mula
• EJBs
• Puntos finales y rutas
• Bus de servicio / ESB
• JMS

Después de buscar cada uno de estos en línea / en Wikipedia, pude obtener (en su mayor parte) definiciones decentes para cada uno de ellos. Lo que no entiendo es cómo todas estas tecnologías / conceptos trabajan juntos en el backend para proporcionar una solución de nivel 2 / empresarial.

¿Alguien puede dar un ejemplo de una arquitectura que utilice todas estas tecnologías / conceptos, y explicar qué papel juega cada uno de ellos en la solución general? Una vez que vea un ejemplo de trabajo, estoy seguro de que me ayudará a conectar la mayoría de los puntos.

Edición : desde que agregué la recompensa, he tenido varias respuestas que sugieren leer libros. Aunque aprecio todos los comentarios aquí, simplemente no puedo separarme de los 300 puntos de reputación por una respuesta que, esencialmente, se reduce a "RTM" (¡especialmente cuando no puedo pagar el manual!) Reiterar , la recompensa y la respuesta definitiva irán a alguien que pueda golpear todas estas balas en un ejemplo práctico y significativo. ¡Esto no tiene que ser un compendio de middleware! Solo uno o dos párrafos que muestran cómo todos estos se pueden usar juntos en armonía para producir una solución de nivel empresarial de Java. Gracias de nuevo.

Answer 1

Clases de Java / ejemplo para cada tecnología. puede que no sea posible en una sola publicación porque lo que usted pidió es la evolución que atravesó la industria en la última década y sigue evolucionando. Entonces, lo que sucedió en la última década no puede ser cubierto en una publicación. Sin embargo, es bueno comprender cómo pasó esta fase y por qué se necesita nueva tecnología y qué tipo de problema resuelve.

• Arquitectura de componentes del servidor EJBs Enterprise Java Beans. Permite un desarrollo rápido y simplificado de

  1) distribuido (donde el servidor de aplicaciones múltiples se comunica entre sí, los componentes del servidor (por ejemplo, un servicio que llama a otro servicio alojado en un servidor diferente).

  2) transational - persistance bean (DB TXNs), la parte más importante de cualquier aplicación simple / web / distribuida. Fácil desarrollo, por ejemplo, base de configuración. Escriba XML que se encargue de la transacción, por ejemplo, cuándo se debe confirmar, cuándo revertir (en excepciones), etc. Las API de persistencia JPA de JPA proporcionan la asignación de relaciones de objetos. Tal como la fila de la tabla se asigna a su objeto java a través de la configuración xml.

  3) secure - authentication (uid / pwd) y autorización (role based- who is logged in user y ¿qué tarea puede hacer?).

Esto se ve bien en un punto para desarrollar cualquier aplicación empresarial, sin embargo, tiene algunas desventajas, por ejemplo, es muy pesada (todos los contenedores incluidos). Las clases utilizadas como bean deben confirmar los estándares EJB (las clases deberían haber implementado cierta interfaz para que el motor EJB entienda qué tipo de bean es).

Para superar tales escenarios, hay muchas alternativas disponibles en la industria para los EJB, por ejemplo, Hibrnate hace lo mismo, como el mapeo OR, el manejo de TXN lo mismo que el bean de persistencia en EJB. El marco de Spring, ligero y simplifica la lógica de negocios (puede usar su clase de compilación que no necesita implementar ninguna interfaz, excepciones comprobadas o ampliar algunas de las clases abstractas obligatorias).

Hoy en día, la mayoría de las compañías realmente trabajan en marcos ligeros como Spring, Hibernate, IBatis, Axis-2.

• Arquitectura orientada a servicios (SOA) La arquitectura orientada a servicios es una respuesta a la independencia de la plataforma a nivel empresarial. O Para integrar su aplicación más rápido, para comunicarse entre diferentes servidores de aplicaciones.

  Simplemente piense que desea implementar una solución en la que esté brindando la opción de reservar un hotel en todo el mundo. Su requerimiento es verificar la disponibilidad de habitaciones en esos hoteles. Ahora, significa que necesita interactuar con varias aplicaciones de hoteles a la vez. No es necesario que cada hotel esté usando el mismo estándar o que su aplicación (servidor, lenguaje de programación) se pueda implementar en los diferentes servidores de aplicaciones. Al mismo tiempo, no es práctico escribir diferentes aplicaciones que puedan comunicarse con todos los diferentes tipos de servidores de aplicaciones. Necesitamos una solución estándar que pueda resolver este problema. Es posible a través de los servicios web.

Es posible porque los servicios web están enviando mensajes en el SOAP (Protocolo simple de acceso a objetos), basado en el XML. XML se utiliza para intercambiar datos a través de cualquier idioma, plataforma o protocolo de red.

Los servicios web pueden ser clasificados por SOAP y REST. Servicio basado en SOAP JAX-RPC y JAX-WS ( http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html )

Los servicios web se pueden desarrollar en primer lugar, primero escriba WSDL. código primero - primer código de escritura.

Ahora, vamos a hablar de cómo iniciar prácticamente los servicios web.

El servicio web más simple o hola mundo (JAXWS) se puede escribir de la siguiente manera: - http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/java_first_jaxws/

• Middleware orientado a mensajes (MOM)
• JMS

• Message Queue (punto a punto)

  Se requiere que MOM supere las desventajas de la comunicación de estilo de solicitud-respuesta. El servidor necesita estar vivo cuando el cliente envía una respuesta. El cliente espera la respuesta hasta que el servidor se ejecuta y responde.

  Solicitud de respuesta: la aplicación fallará si el servidor o el cliente no funcionan. MOM: no se requiere que ninguno de los puntos finales esté a la hora de enviar el mensaje de solicitud para el procesamiento.

  MOM es un concepto y JMS es la especificación de este concepto. Muchos proveedores tienen implementación de esta especificación, por ejemplo, IBM tiene MQ, implementación de código abierto OpenJMS, EMS de Tibco, etc.

La especificación JMS tiene principalmente dos patrones. Pub / sub y ponin-to-point.

Pub / sub es un tema, su aplicación desea publicar cierta información a todas las partes interesadas. por ejemplo tablero de instrumentos. (La aplicación de stock quiere notificar cierto mensaje a todos los oyentes registrados).

La comunicación punto a punto se realiza a través de la cola de mensajes.

Caso de uso comercial: creo que tiene una solicitud, por ejemplo, una solicitud del cliente a la atención al cliente Por otro lado, tiene varios representantes de atención al cliente y otros clientes a veces más que los representantes de atención al cliente; al mismo tiempo, solo un representante obtendrá la solicitud para ser procesada y él / ella no recibirá la siguiente solicitud hasta que finalice la tarea. (La misma cola de múltiples ventanas y cualquiera que sea la ventana libre procesará la solicitud). Puede pensar en otra complejidad en esto, por ejemplo, qué pasa si uno de los nodos falla, la solicitud no se procesa y un determinado tipo de solicitud debe ser procesada por un nodo particular. etc.

Produce el código: - http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleProducer.java

Código síncrono del consumidor: - (clases POJO) http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleSynchConsumer.java

http://www.java2s.com/Code/Java/J2EE/ThisexampleisasimpleJMSclientapplication.htm

Consumir código asíncrono: - (Spring by example - lee el mensaje desde el destino hasta que el programa no se detiene.) http://www.springbyexample.org/examples/simple-spring-jms-listener-config.html

Sin embargo, es simplemente básico que hay muchos aspectos que se deben cubrir en este MOM, por ejemplo, qué es el mecanismo de conmutación por error, qué es el selector, el mensaje duradero, los modos de confirmación de mensajes, etc.

• Bus de servicio / ESB
• Puntos finales y rutas
• Camel Apache
• Mula

Ahora, supongamos que hace tiempo que adoptó SOA y MOM, y tiene muchos servicios que se comunican entre sí para realizar tareas de toda la empresa. Imagínese administrar una lógica como el destino múltiple, a quien se debe redirigir desde donde será muy engorroso. Algunas personas llaman a esta aplicación lógica. Los buses de servicio se utilizarán para reducir la lógica de la aplicación y centrarse más en la lógica empresarial (funcionalidad proporcionada por la aplicación).

En palabras simples, considere el punto final como URL expuesta en el servidor. Utilizará este url / punto final para invocar su servicio.

por ejemplo, http://localhost:8888/Context/MyService?wsdl

en codigo:-

 String endpointAddress = "http://localhost:8080/jaxws/services/hello_world?wsdl";
// Add a port to the Service
service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);
HelloWorld hw = service.getPort(HelloWorld.class);
System.out.println(hw.sayHi("World"));

Rutas Cuando el bus de servicio recibe un mensaje en particular, lo enrutará a través de un n. ° de destinos de servicios / intermediarios como cola / temas. Esta ruta se conoce como ruta.

Por ejemplo, su aplicación de stock tiene alguna entrada por parte del analista, se procesará a través de la aplicación / componente web y luego se publicará el resultado a todos los miembros interesados ​​/ registrados para una actualización de stock particular.

Apache Camel y Muel http://camel.apache.org/how-does-camel-compare-to-mule.html proporciona una solución para la integración empresarial.

Answer 2

Mezclas muchos conceptos y tecnologías diferentes con diferentes niveles de abstracción. Pero todos sus conceptos tienen algo que ver con la integración de aplicaciones (empresariales). Trataré de comentar tus definiciones:

• Arquitectura orientada a servicios (SOA)
  SOA proporciona un conjunto de principios y metodologías para integrar las aplicaciones existentes como unidades débilmente acopladas. De los Patrones de Integración Empresarial (ver más abajo): "Las SOA desenfocan la línea entre la integración y las aplicaciones distribuidas ".
• Bus de servicio / ESB
  El ESB es un concepto principal de SOA para reducir las dependencias dentro de las aplicaciones en una SOA. En lugar de muchas dependencias entre las aplicaciones, cada aplicación está conectada al ESB.
• Middleware orientado a mensajes (MOM)
  MOM es una infraestructura para enviar y recibir mensajes entre sistemas distribuidos. Esto se usa para integrar aplicaciones. MAMÁ fue el martillo de oro antes de que surgiera el bombo de la SOA Dado que ambos son útiles, las suites de integración grandes proporcionan ESB y MOM (o usan MOM dentro de su ESB).
• Cola de mensajes
  Una cola de mensajes es solo un aspecto de detalle técnico en la arquitectura de MOM. Cuando el envío / recepción de mensajes se desacopla, los mensajes se almacenan en colas hasta que el destinatario está listo.
• Camel Apache
  Cuando el libro Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions llega al mercado, se han creado algunas soluciones de software que proporcionan implementación para los patrones de este libro. Apache Camel es uno de ellos. Camel también es parte de Apache ServiceMix, que también es un ESB de fuente abierta. FuseSource y Talend empaquetan Apache ServiceMix, Apache Camel y Apache Active MQ (MOM) en paquetes con soporte comercial.
• Mula
  Mule también es una plataforma de integración y ESB de código abierto.
• EJB
  De Wikipedia: Enterprise JavaBeans (EJB) es una arquitectura de componentes administrada del lado del servidor para la construcción modular de aplicaciones empresariales. Esto significa que EJB es un componente dentro de una aplicación y no tiene nada que ver con la integración de aplicaciones.
• Puntos finales y rutas
  Cuando trabaja con Apache Camel, está diseñando rutas entre puntos finales, consulte un tutorial . En resumen, los mensajes ingresan / salen de su sistema a través de puntos finales y se procesan en un flujo definido por una ruta.
• JMS
  JMS o Java Message Service es un middleware orientado a mensajes (MOM) con una API Java estandarizada.

Answer 3

Principios principales de SOA: Construir sistemas como un conjunto de servicios donde cada servicio es

• De grano grueso
• Interoperable
• Débilmente acoplado

Una compañía ofrece una gran cantidad de servicios comerciales (de grano grueso) desarrollados durante muchos años y expuestos a los usuarios (humanos u otros sistemas) de alguna forma. Hay más posibilidades de que cada una de estas características haya sido diseñada y desarrollada sin tener en cuenta los tres principios anteriores. Además, cada una de esas características podría estar ejecutándose en plataformas heterogéneas dispares, utilizando diferentes tecnologías, etc.

¿Qué sucede si desea integrar estas características dispares para crear nuevas soluciones (por ejemplo, frente de la tienda de Amazon es un nuevo servicio compuesto por su servicio de catálogo, servicio de carrito de compras, etc.)?

Tienes dos opciones:

1. Construyendo la nueva característica desde cero, teniendo en mente los 3 principios. Pero es un esfuerzo muy costoso, y uno que casi nunca tiene éxito.
2. Una alternativa efectiva y menos arriesgada es ensamblar / componer a partir de servicios existentes, probados (bien probados).

La opción 2 es donde los ESB pueden ayudar con su soporte para enrutamiento, transformación, monitoreo, etc. Apache Camel , Mule son ESB de código abierto. Los extremos y las rutas son la terminología utilizada en EIP ( Enterprise Integration Patterns ) que implementan estos ESB. Los ESB pueden recibir ayuda de MOM ( Message-Oriented-Middleware ) cuando desean enrutar / integrar servicios que se ejecutan en plataformas heterogéneas (por ejemplo, el servicio de catálogo puede ejecutarse en un sistema mainframe pero el carro de la compra se implementa utilizando EJBs en ejecución en un servidor de aplicaciones Java). Message Queue es un concepto en MOM que actúa como un almacenamiento temporal del mensaje entre el emisor y el receptor. Este almacenamiento temporal ofrece muchos beneficios como entrega asíncrona, entrega garantizada, etc. Hay varios proveedores de MOM diferentes como IBM (WebSphere MQ), ActiveMQ de código abierto, etc. Podemos usar JMS para mantener su código independiente del proveedor.

Traté de relacionar todos los conceptos con un ejemplo. También traté de mantenerlo corto. Por favor, haga preguntas de seguimiento para obtener más información.

MOM no es un requisito para implementar SOA. Por ejemplo, si todos sus servicios están expuestos a través de SOAP a través de HTTP, entonces no necesita una MOM en este caso.

Answer 4

Puntos finales y rutas: de dónde proviene y va la información. Message Queue es un tipo de punto final. El otro tipo es un tema del mensaje.

Un punto final es un ''nombre lógico para una cosa'', por ejemplo, PRICE.MSFT, que es utilizado por un editor o aplicación de consumidor para obtener o enviar cosas desde. Los temas entregan información a todos los suscriptos (uno a uno o uno a muchos), las colas entregan mensajes al primero que lo recibe (generalmente uno a uno). Olvídese de las colas, todo también se puede hacer con Temas y los temas tienen varias ventajas.

Middleware orientado a mensajes (MOM): la infraestructura de software que entrega información entre temas o queus. Es ''orientado a mensajes'' no ''orientado a paquetes'' como lo es TCP. Por lo tanto, cada blob de información se entrega en un solo mensaje, es de esperar que se autodescriba. La implementación de tu MOM luego te da una API donde puedes hacer cosas como msg.get ("bid")

JMS y AMQP son ejemplos de especificaciones de MOM. Las implementaciones de MOM son los productos reales que implementan estas especificaciones: TIBCO EMS, Websphere MQ, MSMQ, Solace y muchas otras.

Apache Camel: enfoque muy interesante sobre cómo configurar flujos de trabajo en este mundo de MOM. Pero un concepto más avanzado.

La Arquitectura orientada a servicios (SOA), Bus de servicio / ESB son solo palabras nuevas que se llaman EAI (Integración de aplicaciones empresariales). Son recomendaciones sobre cómo usar ''MOM''s'' y una forma de pagar consultores de alto precio. Lo que ''ESB'' agrega a una MOM es la idea de pensar en sus editores como ''servicios'' que brindan un servicio. En otras palabras: no piense demasiado en lo que un consumidor quiere en este momento. Puede haber 5 consumidores en el futuro y ese editor debe proporcionar un servicio, no ''crear información que el consumidor A quiera''. (Se aclarará una vez que su arquitectura haya crecido a más de 5 aplicaciones). También debería tener algún modelo de objeto común, tal vez en XML para simplificar las cosas entre las aplicaciones.

Mule: una forma de ESB, pero no es exactamente main-stream. En 5 años, la mayoría de las acciones de middleware podrían haberse trasladado a AMQP o a alguna otra cosa por completo.

EJB: la idea de Sun de clases Java sofisticadas que se ejecutan en un contenedor. Se supone para facilitar el desarrollo de aplicaciones. Pero en muchos casos hizo las cosas más complejas. Una mejor alternativa sería ''Spring'', pero los EJB son sobre otra cosa (no solo MOM). Es más acerca de cómo desarrollar aplicaciones más grandes (ver patrón IoC).

Si está buscando por dónde empezar: recomendaría aprender sobre JMS (todos los demás MOM son similares y JMS es la base de EJB / Mule, ...) y, a menos que tenga requisitos de rendimiento muy altos, considere los mensajes como un TextMessage que contiene XML. La mayoría de las herramientas están disponibles en esa área. O incluso más simple pero menos sofisticado, un MapMessage con pares clave / valor.

Answer 5

Tomando todos sus requisitos y empaquetándolos en una consulta, encontré un excelente estudio de caso que debería satisfacer sus necesidades:

• Arquitectura orientada a servicios: un plan de integración

Seguí adelante y busqué el libro a través de la función "Buscar en este libro" de Amazon. Cubre todos los casos de integración que ha discutido, parece ser exhaustivo y lo guía a través de todo el proceso de diseño e implementación.

Me avergüenza decir que no lo he leído yo mismo , pero recomiendo utilizar las mismas herramientas que usé para ver si se ajustan a sus necesidades antes de invertir en una copia. Parece más completo, más completo y más útil que simplemente inscribirte en una gran cantidad de documentación incompleta o poner contenido en una respuesta aquí.

Answer 6

Los Patrones de Integración Empresarial pueden ayudarlo a comprender cómo encaja todo.

[actualización:] Su pregunta de seguimiento en otra respuesta me hizo darme cuenta de que está confundido acerca de productos específicos. Esto se debe en parte a que el software en la práctica tiende a asociarse con más de un concepto y en parte porque diferentes compañías argumentan que ofrecen "todo", cuando en realidad no lo hacen.

Los ESB son kits de herramientas / bibliotecas que le permiten conectar todo entre sí. No son ni los servicios en sí mismos, ni las implementaciones de mensajería, sino la sustancia pegajosa que llena las pequeñas brechas intermedias. Si escribieras todo desde cero, es posible que ni siquiera necesites uno, porque lo mejor es solucionar el desajuste entre un montón de tecnologías diferentes, y si empiezas desde cero, puedes evitar ese desorden.

Los servicios son, bueno, los servicios. Puede usar algunos EJB al implementar uno (solo menciono esto porque, por alguna razón, los incluye en su pregunta).

El middleware de mensajería es un software que recibe mensajes de A a B. Es extremadamente útil, pero también complejo, y todos y su hermano han inventado el suyo. Entonces, necesitas algo de abstracción que te permita evitar el lock-in. Eso puede ser un ESB o, si eres todo Java, puede ser JMS. Pero incluso cuando está todo en Java con JMS, es posible que desee utilizar un ESB porque son bibliotecas de todos los bits de código Java que aún necesitaría escribir (bits aleatorios de lógica de enrutamiento, reformateo de mensajes, etc.).

Espero que ayude. Mi respuesta original es más acerca de los patrones abstractos que construyes con estas herramientas: cuando estás conectando cosas, los mismos problemas surgen una y otra vez.

Answer 7

La integración de aplicaciones empresariales (EAI) es clave para conectar aplicaciones comerciales con sistemas heterogéneos. Con los años, los arquitectos de las soluciones de integración han inventado su propia combinación de patrones en una variedad de formas. Pero la mayoría de estas arquitecturas tienen similitudes, iniciando un conjunto de estándares ampliamente aceptados en la arquitectura de patrones de integración. La mayoría de estos estándares se describen en el Catálogo de patrones de integración empresarial disponible en: http://www.eaipatterns.com/toc.html .

WSO2 ESB

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentación! WSO2 ESB es un ESB rápido, ligero, 100% de código abierto y fácil de usar distribuido bajo la Licencia de software Apache v2.0. WSO2 ESB permite a los administradores y desarrolladores de sistemas configurar convenientemente el enrutamiento de mensajes, la mediación, la transformación, el registro, la programación de tareas, la conmutación por error, el equilibrio de carga y más. Es compatible con los Patrones de Integración Empresarial (EIP) más utilizados y permite la conmutación de transporte, la generación de eventos, la mediación basada en reglas y la mediación basada en prioridades para requisitos de integración avanzados. El tiempo de ejecución de ESB está diseñado para ser completamente asíncrono, sin bloqueo y transmisión basada en el motor de mediación de Apache Synapse.