Enterprise Service Bus,.NET Service Bus, NServiceBus y las ruedas en el bus
esb (2)
Enterprise Service Bus (ESB), .NET Service Bus (Windows Azure AppFabric Service Bus), NServiceBus, RhinoServiceBus, Mass transit, etc.
Estoy tratando de entender lo que cada una de estas tecnologías tiene en común o no en común.
Hoy asistí a la presentación de Juval Löwy en el Bus de Servicio .NET y él dijo que el Bus de Servicio .NET podría usarse como la versión de un hombre pobre de un ESB, por lo que entendería que el Bus de Servicio .NET NO es un ESB, ¿alguno de los otros es un verdadero ESB?
Si alguno de los otros es un verdadero ESB, ¿qué los haría un verdadero ESB en lugar del Bus de Servicios .NET?
Creo que es necesario comprender que ESB es más un término de marketing que un término técnico. Muchos vendedores están presentando tecnologías bajo esa bandera.
Lo que hay que tener en cuenta es el estilo arquitectónico del bus, en el que colaboran las fuentes de eventos y los sumideros. NServiceBus, RhinoServiceBus y MassExit tienen el concepto de publicación y suscripción a eventos integrados, el Bus de servicio .NET no.
Las diferencias entre los tres anteriores son más en forma que en función: estabilidad, documentación, comunidad, etc.
Espero que ayude.
Estoy de acuerdo con el otro póster: ESB es un poco como SOA, una definición general que se usa principalmente como un punto de venta de marketing más que como un estándar estricto que debe cumplir.
De Wikipedia:
Los comentaristas no están de acuerdo sobre si definir un Enterprise Service Bus (ESB) como un estilo arquitectónico, un producto de software o un grupo de productos de software. Si bien el uso de un ESB ciertamente implica adherencia a una arquitectura particular, el término "bus de servicio empresarial" casi siempre denota la infraestructura de software que permite tal arquitectura, y en esencia, el ESB se considera una plataforma para realizar una arquitectura orientada a servicios.
Un ESB aporta conceptos relacionados con el flujo, como la transformación y el enrutamiento, a una arquitectura orientada a servicios. Un ESB también puede proporcionar una abstracción para los puntos finales.
El término ESB parece haber sido acuñado por Dave Chappel, quien es (¿era?) Evangelista técnico de Sonic Software (y autor "Enterprise Service Bus" - O''Reilly: junio de 2004, ISBN 0-596-00675-6). He leído el libro y he asistido a un par de seminarios por Chappell, y me temo que el libro en sí no es de mucha ayuda para ayudarlo a decidir si el Producto X es un ESB "verdadero".
En general, debe buscar algo basado en el mensaje (esta fue la intención original, aparentemente, incluso si otras compañías, como webMethods, usan el término para su producto, que está más orientado a servicios web).
La idea es tener todos los "servicios" en su infraestructura de TI que puedan recibir y enviar mensajes entre sí. El ESB proporciona el enrutamiento y tiene puntos finales de interfaz de modo que si su aplicación original funcionó, por ejemplo, al invocar una página JSP a través de una publicación HTTP, tiene un pequeño programa que puede recibir un mensaje, use su carga útil para publicarlo a través de HTTP. Interpreta el resultado y construye una respuesta de mensaje con estos.
Básicamente, imagine que en lugar de usar servicios web para todo, use colas de mensajes, construya estaciones de enrutamiento e interfaz entre las colas de mensajes y otros sistemas. Este es un ESB.
Esto es largo, pero instructivo: https://plus.google.com/112678702228711889851/posts/eVeouesvaVX