Un bus de servicios empresariales ( ESB ) implementa un sistema de comunicación entre aplicaciones de software que interactúan entre sí en una arquitectura orientada a servicios (SOA). Representa una arquitectura de software para computación distribuida y es una variante especial del modelo cliente-servidor más general , en el que cualquier aplicación puede comportarse como servidor o cliente. ESB promueve la agilidad y la flexibilidad con respecto a la comunicación de protocolos de alto nivel entre aplicaciones. Su uso principal es en la integración de aplicaciones empresariales (EAI) de entornos de servicios heterogéneos y complejos.
El concepto de bus de servicios empresariales es análogo al concepto de bus que se encuentra en la arquitectura de hardware de computadoras combinado con el diseño modular y concurrente de sistemas operativos de computadoras de alto rendimiento. La motivación para el desarrollo de la arquitectura fue encontrar un concepto estándar, estructurado y de propósito general para describir la implementación de componentes de software acoplados de manera flexible (llamados servicios ) que se espera que se implementen de forma independiente, se ejecuten, sean heterogéneos y dispares dentro de una red. ESB también es un patrón de implementación común para la arquitectura orientada a servicios , incluido el diseño de red intrínsecamente adoptado de la World Wide Web .
No existen estándares globales para los conceptos o implementaciones de bus de servicios empresariales. [1] La mayoría de los proveedores de middleware orientado a mensajes han adoptado el concepto de bus de servicios empresariales como estándar de facto para una arquitectura orientada a servicios. Las implementaciones de ESB utilizan middleware orientado a mensajes basado en estándares y controlado por eventos en combinación con colas de mensajes como marcos tecnológicos. [2] Sin embargo, algunos fabricantes de software reetiquetan las soluciones de comunicación y middleware existentes como ESB sin adoptar el aspecto crucial de un concepto de bus.
Un ESB aplica el concepto de diseño de los sistemas operativos modernos a servicios independientes que se ejecutan dentro de redes de computadoras dispares e independientes. Al igual que los sistemas operativos concurrentes, un ESB proporciona servicios básicos además de la adopción, la traducción y el enrutamiento de las solicitudes de los clientes a los servicios de respuesta adecuados.
Las principales funciones de un ESB son:
El primer uso publicado del término "bus de servicios empresariales" se atribuye a Roy W. Schulte, del Gartner Group, en 2002, y al libro The Enterprise Service Bus de David Chappell. Aunque varias empresas se atribuyen el mérito de haber acuñado la frase, en una entrevista, Schulte dijo que la primera vez que escuchó la frase fue de una empresa llamada Candle y continuó diciendo: "El antecesor más directo del ESB fue el producto Roma de Candle de 1998" [3] cuyo arquitecto jefe y titular de la solicitud de patente fue Gary Aven. Roma se vendió por primera vez en 1998, lo que lo convirtió en el primer ESB comercial del mercado, pero el producto de Sonic de 2002 también fue uno de los primeros ESB del mercado. [4]
El ESB se implementa en software que opera entre las aplicaciones empresariales y permite la comunicación entre ellas. Idealmente, el ESB debería poder reemplazar todo contacto directo con las aplicaciones en el bus, de modo que toda la comunicación se realice a través del ESB. Para lograr este objetivo, el ESB debe encapsular la funcionalidad ofrecida por sus aplicaciones componentes de una manera significativa. Esto ocurre típicamente mediante el uso de un modelo de mensajes empresariales . El modelo de mensajes define un conjunto estándar de mensajes que el ESB transmite y recibe. Cuando el ESB recibe un mensaje, enruta el mensaje a la aplicación apropiada. A menudo, debido a que esa aplicación evolucionó sin el mismo modelo de mensajes, el ESB tiene que transformar el mensaje en un formato que la aplicación pueda interpretar. Un adaptador de software cumple la tarea de efectuar estas transformaciones, de manera análoga a un adaptador físico . [5]
Los ESB se basan en la construcción precisa del modelo de mensajes empresariales y en el diseño adecuado de la funcionalidad que ofrecen las aplicaciones. Si el modelo de mensajes no encapsula por completo la funcionalidad de la aplicación, es posible que otras aplicaciones que deseen esa funcionalidad tengan que pasar por alto el bus e invocar directamente las aplicaciones no compatibles. Hacerlo viola los principios del modelo ESB y anula muchas de las ventajas de utilizar esta arquitectura.
La belleza de ESB reside en su naturaleza independiente de la plataforma y en la capacidad de integrarse con cualquier cosa en cualquier condición. Es importante que los proveedores de gestión del ciclo de vida de las aplicaciones apliquen realmente todas las capacidades de ESB en sus productos de integración al adoptar SOA . Por lo tanto, los desafíos y las oportunidades para los proveedores de EAI son proporcionar una solución de integración que sea de bajo costo, fácilmente configurable, intuitiva, fácil de usar y abierta a cualquier herramienta que elijan los clientes.
¹ Algunos no consideran que la coreografía de procesos sea una función del ESB. Por ejemplo, véase M. Richards. [6]
² Mientras que la coreografía de procesos admite la implementación de procesos comerciales complejos que requieren la coordinación de múltiples servicios comerciales (generalmente mediante BPEL ), la orquestación de servicios permite la coordinación de múltiples servicios de implementación (más adecuadamente expuestos como un servicio agregado) para atender solicitudes individuales.
Estas soluciones a menudo se centran en funciones ESB de bajo nivel, como conectividad, enrutamiento y transformación, y requieren codificación o scripts para implementar la orquestación. [7] Los desarrolladores que operan a nivel de proyecto o táctico, por ejemplo, simplemente tratando de solucionar un problema, a menudo gravitan hacia tecnologías de bus de servicio livianas, pero a menudo existe una tensión constante entre estas iniciativas y una arquitectura empresarial cuyo objetivo es optimizar la infraestructura en múltiples proyectos. [8]
Si el agente de mensajes, el software ESB, traduce un mensaje de un formato a otro, entonces, como con cualquier traducción, existe el problema de la semántica del mensaje. Por ejemplo, un registro se puede traducir de JSON a XML, pero el mismo conjunto de campos puede ser interpretado de manera diferente por diferentes aplicaciones, específicamente en el caso de los diversos casos especiales que generalmente solo conocen los desarrolladores que tienen una amplia experiencia con la aplicación que está conectada al ESB. Para los casos especiales conocidos, la cantidad de pruebas que cubren todos los casos especiales aumenta exponencialmente con cada aplicación que se conecta al ESB, porque cada aplicación conectada al ESB debe probarse con cada otra aplicación que esté conectada al ESB.
Los productos destacados incluyen:
no existe un estándar global para ESB.
No considero que la coreografía de procesos sea parte de un ESB, si consideramos un ESB como un middleware de mensajería de alta velocidad. Sin embargo, considero que la coreografía de procesos es parte de la *plataforma* del ESB. Afortunadamente, la mayoría de los proveedores de ESB separan estos componentes principales en diferentes productos, pero los empaquetan bajo una oferta ESB consolidada. Por lo tanto, en el sentido más estricto de la palabra, no, no lo consideraría como parte de un ESB. Es una capacidad relacionada.