Para mí, JMS y ESB parecen ser cosas muy relacionadas y estoy tratando de entender cómo se relacionan exactamente.JMS y ESB: ¿cómo están relacionados?
He visto una oración que dice que JMS se puede usar como transporte para ESB. ¿Qué otra cosa, excepto el transporte, debería estar presente en un ESB de este tipo? ¿Es JMS un ESB simple o, en caso negativo, qué le falta al ESB real?
JMS ofrece un conjunto de API para la mensajería: poner un mensaje en una cola, alguien más, en algún momento más tarde, tal vez geográficamente lejos, saca el mensaje de la cola y lo procesa. Nos hemos desacoplado en el tiempo y la ubicación del proveedor de mensajes y el consumidor. Incluso si el consumidor de mensajes está inactivo por un tiempo, podemos seguir produciendo mensajes.
JMS también ofrece una función de publicación/suscripción donde el productor coloca el mensaje en un "tema" y cualquier parte interesada puede suscribirse a ese tema, recibir mensajes a medida que se producen, pero por el momento centrarse solo en el cola capacidad.
Hemos desacoplado algunos aspectos de la relación entre el proveedor y el 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 de esa manera, pero una alternativa sería tener un sistema de mensajería que permite enviar diferentes mensajes a diferentes lugares que nos propusimos hasta 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 entonces todo lo que necesitamos es un poco de inteligencia en el propio sistema de colas para transferir a continuación messsage de la cola de solicitudes a la cola de platino o de la cola estándar.
Así que esta es una capacidad de Enrutamiento Basada en Contenido, y es algo que proporciona un ESB. Tenga en cuenta que el ESB utiliza las capacidades fundamentales de cola ofrecidas por JMS.
Un segundo tipo de acoplamiento es que el consumidor y el productor deben estar de acuerdo con el formato del mensaje. En casos simples, eso está bien. Pero cuando comienzas a tener muchos productores que ponen mensajes en la misma cola, comienzas a tener problemas con las versiones. Se presentan nuevos formatos de mensaje 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 la ESB recoge los mensajes de la cola de la versión 1 y los transforma en la versión 2 mensajes y los pone en la cola de la versión 2.
La transformación de mensajes es otra posibilidad posible de ESB.
Eche un vistazo a los productos de ESB, vea lo que pueden hacer. Como trabajo para IBM, estoy familiarizado con WebSphere ESB
Así que JMS solo ofrece capacidades básicas de puesta en cola. ESB ofrece muchas más capacidades para administrar esas colas, sus suscriptores y proveedores, y se puede basar en el bajo nivel de JMS. O hay algo más en ESB excepto eso? – nucleo
Existe un área de debate sobre qué se debe hacer "en el autobús" y qué se debe hacer fuera del ESB. Diferentes proveedores tienen diferentes respuestas. Creo que es mejor comenzar con ESB como un conjunto de patrones arquitectónicos, y luego ver qué productos de bits considera que pueden hacer por usted. – djna
ESB ofrece integración con muchos protocolos diferentes además de JMS.
La mayoría utiliza JMS entre bastidores para transferir, almacenar y mover mensajes. Una de esas soluciones OpenESB usa mensajes de formato XML.
No son de código abierto ESB que se podía checkout -
implementación de JMS como ActiveMQ vienen con Camel incorporado en ellos.
JMS no es muy adecuado para la integración de servicios REST, sistemas de archivos, S/FTP, correo electrónico, Hesse, 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. Del mismo modo, la integración de los servicios REST, con balanceo de carga/conmutación por error a múltiples instancias backend se puede hacer mejor con un ESB compatible con HTTP/S nativamente.
Dumping CSV y recogiendo para el procesamiento se puede hacer de varias otras maneras .. No es necesaria una solución costosa de ESB para eso. Cualquier caso de uso mejor y más complejo que ESB pueda manejar va a ser un buen candidato para él. –
Yo diría que ESB es como una fachada en varios protocolos ... JMS es uno de ellos.
Esta transformación no ocurre automáticamente. Es necesario configurar el mapeo o escribir Servicio de transformación de
Saludos, Raja Nagendra Kumar, director de tecnología www.tejasoft.com
JMS es un protocolo para la comunicación con una aplicación de mensajería subyacente capa. 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.
Hay intermediarios de mensajes JMS, que puede configurar fácilmente con ESB. https://docs.wso2.com/display/ESB470/JMS+Transport
El cínico entre nosotros diría que JMS es una API de Java específica, donde "ESB" es un término de comercialización que cubre una multitud de tecnologías relacionadas y métodos de diseño, y significa muy poco. – skaffman
@skaffman incluso algunos optimistas de ojos brillantes podrían estar de acuerdo contigo ;-) – djna