He revisado diferentes preguntas / artículos sobre corredores de mensajes y ESB (incluso en stackoverflow). ¿Aún no tiene idea de cuál es la clara diferencia demarcación entre un intermediario de mensajes y un ESB? ¡Ahora estoy tratando de comparar productos, Websphere Broker y Mule ESB!
En primer lugar, ¿es (cualquier versión) Webshere Broker un ESB? ¡Nuestros muchachos de productos de IBM afirman que es un ESB! (No estoy sorprendido por eso).
Mi información limitada me dice que un Message Broker funciona en un modelo HUB-SPOKE. Sin embargo, el ESB funciona en una arquitectura de bus. ¿Qué se supone que significa eso? He leído que si el HUB falla (no disponible, supongo), entonces el corredor falla por completo. Que no es el caso de un ESB (eso dicen esos tipos). Lo que no entiendo aquí es "¿Qué pasa si el BUS" falla?
Ahora, lo habitual sobre un ESB y Brokers es que proporcionan enrutamiento, transformación, orquestación, etc. Entonces, si ambos proporcionan esto, ¿por qué elegiría uno sobre el otro?
Otra área de conflicto es con respecto a la TRANSFORMACIÓN. ¿Los ESB lo facilitan de manera diferente en comparación con los corredores de mensajes? Realmente me encantaría tener una idea de esto.
Ahora hablando de escalado HORIZONTAL. ¿Quién supera a quién? O ambos son igualmente escalables en términos de complejidad (o cualquier otro factor). Por supuesto, en cuanto al costo, Webshpere Broker le cobrará por cada caja (y mucho menos cada CPU). Creo que incluso el comercial MULE ESB no hace eso. Dejando a un lado la parte del costo, ¿cuáles son las implicaciones del escalado de ESB y el escalado de Message Broker? Sé que puedes escalar al nivel de servicio en ESB. ¿Es esto posible en un Message Broker?
fuente
Respuestas:
Puede usar un intermediario de transformación sin un bus de servicio y viceversa. En términos de productos específicos, no creo que ninguno sea puramente uno u otro debido a la forma en que cada uno complementa al otro. Algunos productos son más fuertes en un área, otros más fuertes en otra. Quizás deba hacerse una elección basada en qué función cubre mejor un problema individual.
Un corredor puede tener mejores "bloques de lego" incorporados para construir una cadena de transformación que un producto ESB. Un corredor presionado en servicio como un ESB puede ser aplastado bajo carga y no escalar bien, o puede carecer de un diario robusto y herramientas para lidiar con las revistas.
Algunos ESB permiten que las actualizaciones de la base de datos se reviertan y las colas se reproduzcan en una aplicación corregida una vez que se ha descubierto y reparado un error grave en la lógica. No creo que la mayoría de los corredores integren ese nivel de soporte transaccional. Para que esto funcione en todas sus "transacciones" casi tienen que ser eventos comerciales (una venta, una renovación, un cambio de propiedad, etc.) en lugar de algo así como "actualizaciones de la base de datos" de RPCish.
fuente
Descargo de responsabilidad: soy consultor de IBM y me especializo en WebSphere ESB. Este comentario no se deja en ninguna capacidad oficial.
Un ESB es más un patrón o concepto arquitectónico que un producto, en términos generales, una forma basada en servicios de ingeniería de acoplamiento flexible. Su definición es discutida y no exactamente grabada en piedra. En general, un ESB es un conjunto de servicios no relacionados (en un sentido técnico): exponen interfaces y las consumen de otros servicios. En general, no hay un centro y arquitectura de radios involucrados, aunque puede haberlo.
IBM ciertamente comercializa tanto WebSphere Message Broker como WebSphere ESB como productos que facilitan la creación de un ESB (junto con el dispositivo de hardware DataPower). Tienen diferentes raíces tecnológicas, pero tienen cierta superposición en el propósito. Además, eso no quiere decir que no pueda construir un ESB con muchas otras cosas que no están marcadas como un 'producto ESB'.
Eso no responde a todas sus preguntas, pero con suerte aborda la parte de IBM.
fuente
La diferencia entre un Message Broker y un ESB (Enterprise Service Bus) es principalmente la palabra 'bus'.
Para mí, un Message Broker es un proceso (usualmente grande) que transforma datos de una estructura a otra estructura o modifica el contenido.
Un ESB es un middleware orientado a mensajes (MOM) más servicios adicionales, uno de los cuales podría ser un intermediario de mensajes. Por lo tanto, un ESB puede incluir un intermediario de mensajes como uno de sus componentes. Un bus consta de más de un proceso, de lo contrario no lo llamaría 'bus'. La naturaleza de un bus es que hay múltiples componentes que sirven diferentes tareas, cada uno de los cuales se comunica a través de una MOM y se adhiere a alguna forma de "formato de datos común". Un bus consistiría en: aplicaciones que envían datos al MOM, adaptadores de bases de datos, corredores de mensajes, puentes MOM, etc.
La separación es un poco gradual, pero la mayor diferencia entre una arquitectura de Message Broker y un Bus es la granularidad . Si su tarea es integrar las aplicaciones A, B, ..., Z y un par de bases de datos, puede hacerlo con un gran Message Broker que conecta a todos y cada uno. O con un ESB donde múltiples componentes pequeños se hacen cargo de pequeñas tareas. Por ejemplo, un adaptador se conecta a A, otro a B (pero no hacen transformación), luego cada uno envía sus cosas a uno (o más) Message Broker, cada uno de los cuales debe ser lo más simple posible, por ejemplo, no tener que saber sobre el modelo de datos de 'A' o 'B'. Un buen ESB debe tener una definición de datos común en el bus, abstrayéndose de la "diferencia" de las aplicaciones individuales.
TRANSFORMACIÓN: un ESB no ayuda con la transformación, a menos que venga con un intermediario de mensajes. Pero cada buen ESB debe incluir un intermediario de mensajes de todos modos. Message Broker debería ser el experto de su autobús para las transformaciones, pero nada más.
Escalado HORIZONTAL: si solo tiene 3 cosas para conectarse (ahora y para siempre), probablemente no valga la pena el esfuerzo para obtener un ESB completo. Un Message Broker tiene la ventaja de ser solo un gran proceso. Puede configurar todo allí y tener una ubicación central para todas sus asignaciones de datos, filtrado y enrutamiento.
Pero si tiene 30 aplicaciones para conectarse, un Message Broker probablemente se detendrá. Por supuesto, puede comprar más instancias, ejecutar cosas redundantes, etc., pero debe cambiar su estrategia para 'localizar' trabajos. El adaptador de cada aplicación (podría ser una pequeña instancia de Message Broker cada una) debería poder generar y / o recibir un modelo de datos comunes abstraídos (por ejemplo, XML con un XSD compartido). También podría haber un intermediario de mensajes central para las tareas de transformación, pero esa instancia no debe conocer el modelo de datos A o B. Por lo tanto, un ESB debe trasladar el procesamiento al componente experto en lugar de mantener todo en un lugar central.
fuente
Acabo de leer este artículo de Udi Dahan hace unos días, que podría darle una visión más clara de lo que siento es una diferencia fundamental.
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
Citando:
...
Espero eso ayude.
fuente
Un Enterprise Service Bus proporciona tres valores clave para la empresa:
Los ESB proporcionan un acoplamiento flexible de los servicios, permiten que los servicios se reconstituyan en contextos de aplicación completamente diferentes a los que se imaginaron o desarrollaron por primera vez, y promueven la reutilización de aplicaciones sin la necesidad de volver a codificar las aplicaciones. WebSphere Message Broker (o ahora se llama IBM Integration Bus) es un excelente ejemplo de Enterprise Service Bus. Para ver un ejemplo de simplicidad de código que tiene un gran poder en pocas líneas, puede ver mi publicación aquí: http://soabus.org/viewtopic.php?f=3&t=13 . La construcción fundamental dentro del tiempo de ejecución IIB se llama Árbol de mensajes lógicos(LMT) Todo lo que el desarrollador quiere hacer es algún tipo de operación en el LMT. ESQL es el lenguaje más eficiente que un desarrollador puede usar para realizar estas operaciones en el LMT, aunque se admiten muchos otros lenguajes (por ejemplo, Java, PHP, Python, etc.) Ningún otro producto se acerca a la eficiencia y facilidad de desarrollar ESB aplicaciones que IBM Integration Bus, ya que el 90 por ciento de la codificación de estas aplicaciones se realiza arrastrando y soltando nodos en una paleta. Eso deja solo el 10 por ciento de la codificación que debe realizar el desarrollador de Message Flow. Por cierto, WebSphere ESB ha sido descontinuado por IBM y muchos de los productos competidores de IBM Integration Bus no han visto ningún desarrollo nuevo en ellos desde hace varios años. Se puede ver una lista de varias ofertas de productos ESB en soabus.org.
fuente
IBM ha cambiado desde entonces los nombres de su oferta de ESB, por lo que no entraría en los nombres o proveedores.
ESB permite que la información comercial fluya entre aplicaciones dispares a través de múltiples plataformas de hardware y software. ESB es más una capa de middleware que contiene la lógica de conectividad de la aplicación y una lógica de negocio mínima o nula. Esto permite que las aplicaciones hagan lo que mejor hace sin preocuparse por incorporar ninguna lógica de conectividad sobre cómo interactuar con otras N aplicaciones que requieren los datos. La arquitectura ESB intenta resolver el desorden de espagueti punto a punto en una empresa.
ESB y Message Broker son sinónimos entre sí, sin embargo, como una de las respuestas anteriores ha resaltado que el patrón de Message Broker es una parte del dominio ESB más grande. La letra "B" en ESB es análoga al bus (hardware) en la arquitectura de la computadora. El bus en la placa base o en una computadora conecta varios componentes para el funcionamiento de la computadora. ESB es un bus basado en software que conecta varios servicios en una empresa. Hub y habló es uno de los patrones admitidos por la arquitectura ESB. En el mundo monolítico, cada proveedor tiene su propia arquitectura de implementación de alta disponibilidad para garantizar que el ESB esté disponible. Las ofertas recientes de cualquier proveedor de ESB son en términos de modelo de implementación basado en microservicios o alojado en su propia nube conocida como iPAAS. Por lo tanto, esto garantiza que el Bus nunca fallará o fallará temporalmente con la autocuración según el modelo de implementación seleccionado. Con la implementación basada en microservicios o iPAAS, los ESB ahora tienen capacidades de escalado automático (horizontal o vertical) con características que varían según el proveedor seleccionado.
Para obtener capacidades de muy alto nivel que proporciona ESB, puede pasar por el siguiente enlace => https://en.wikipedia.org/wiki/Enterprise_service_bus
fuente