JMS y ESB-¿Cómo se relacionan?
(8)
Para mí, JMS y ESB parecen ser cosas muy relacionadas y estoy tratando de entender cómo se relacionan exactamente.
He visto una frase en la que se puede usar JMS como transporte para ESB. ¿Qué otra cosa, excepto el transporte, debería estar presente en dicho ESB? ¿Es JMS un ESB simple o, en caso contrario, qué carece del ESB real?
ESB ofrece integración con muchos protocolos diferentes además de JMS.
La mayoría utiliza JMS detrás de escena para transferir, almacenar y mover mensajes. Una de estas soluciones OpenESB, utiliza mensajes en formato XML.
Hay ESB de código abierto que se puede retirar -
La implementación de JMS como ActiveMQ viene con Camel incorporado en ellos.
Esta transformación no ocurre automáticamente. Necesitas configurar el servicio de transformación de mapeo o escritura.
Un saludo, Raja Nagendra Kumar, CTO www.tejasoft.com
Hay intermediarios de mensajes JMS que puede configurar fácilmente con ESB. https://docs.wso2.com/display/ESB470/JMS+Transport
JMS es un protocolo para comunicarse con una capa de mensajería subyacente. ESB opera a un nivel superior, ofreciendo integración con múltiples tecnologías y protocolos, uno de los cuales sería JMS, de una manera uniforme que hace que la administración de flujos complejos sea mucho más simple.
JMS ofrece un conjunto de API para mensajería: poner un mensaje en una cola, alguien más, en algún momento más tarde, tal vez geográficamente lejos toma el mensaje de la cola y lo procesa. Hemos desacoplado el tiempo y la ubicación del proveedor de mensajes y del consumidor. Incluso si el consumidor de mensajes está inactivo durante un tiempo, podemos seguir produciendo mensajes.
JMS también ofrece una capacidad de publicación / suscripción donde el productor pone el mensaje en un "tema" y cualquier parte interesada puede suscribirse a ese tema, recibiendo mensajes cuando se producen, pero por el momento se centran solo en la capacidad de cola.
Hemos desacoplado algunos aspectos de la relación entre proveedor y consumidor. Sin embargo queda algo de acoplamiento. Primero, como están las cosas, cada mensaje se procesa de la misma manera. Supongamos que queremos introducir diferentes tipos de procesamiento para diferentes tipos de mensajes:
if ( message.customer.type == Platinum )
do something special
Obviamente, podemos escribir código así, pero una alternativa sería tener un sistema de mensajería que pueda enviar diferentes mensajes a diferentes lugares donde configuramos tres colas:
Request Queue, the producer(s) puts their requests here
Platinum Queue, platinum consumer processing reads from here
Standard Queue, a standard consumer reads messages from here
Y todo lo que necesitamos es un poco de inteligencia en el propio sistema de colas para transferir el mensaje de la Cola de solicitudes a la Cola de platino o la Cola estándar.
Así que esta es una capacidad de enrutamiento basado en contenido, y es algo que proporciona un ESB. Tenga en cuenta que el ESB utiliza las capacidades fundamentales de puesta en cola que ofrece JMS.
Un segundo tipo de cupping es que el consumidor y el productor deben estar de acuerdo con el formato del mensaje. En casos simples eso está bien. Pero cuando empiezas a tener muchos productores que ponen todos los mensajes en la misma cola, empiezas a tener problemas de versiones. Se introducen nuevos formatos de mensajes, pero no desea cambiar todos los proveedores existentes.
Request Version 1 Queue Existing providers write here
Request Version 2 Queue New provider write here, New Consumer Reads here
Y el ESB recoge los mensajes de la Cola de la versión 1, los transforma en mensajes de la Versión 2 y los coloca en la cola de la Versión 2.
La transformación de mensajes es otra posible capacidad de ESB.
Eche un vistazo a los productos ESB, vea lo que pueden hacer. Como trabajo para IBM, estoy más familiarizado con WebSphere ESB
Yo diría que ESB es como una fachada en una serie de protocales ... JMS es uno de ellos.
JMS y ESB proporcionan una forma de comunicación entre diferentes aplicaciones. Pero el contexto para JMS y ESB es diferente . JMS es por simple necesidad. JMS es implementado por el proveedor JMS. Es específico de Java.
Algunos ejemplos de proveedores JMS son: Apache Active MQ, IBM MQ, HornetQ, etc.
ESB es para necesidades complejas. ESB es un componente en EAI que proporciona facilidad de comunicación para varias aplicaciones. Es genérico y no específico de Java . JMS es uno de los protocolos soportados.
Ejemplos de proveedores de ESB son: MuleESB, Apache Camel, OpenESB
Caso de uso: puede ser una sobrecarga utilizar ESB, si todas nuestras aplicaciones comunicativas están en Java y utilizan el mismo formato de mensaje. Aquí JMS puede ser suficiente.
- Una adición a la lista anterior es la última versión de código abierto de ESB - UltraESB
JMS no es adecuado para la integración de servicios REST, sistemas de archivos, S / FTP, correo electrónico, arpillera, SOAP, etc., que se manejan mejor con un ESB que admite estos tipos de forma nativa. Por ejemplo, si tiene un proceso que descarga un archivo CSV de 500 MB a medianoche, y desea que otro sistema recoja el archivo, analice CSV e importe en una base de datos, esto puede lograrse fácilmente mediante un ESB, mientras que una solución con solo JMS será malo. De manera similar, la integración de los servicios REST, con balanceo de carga / conmutación por error a múltiples instancias de backend, se puede hacer mejor con un ESB que soporte HTTP / S de forma nativa.