Bus de servicios empresariales

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:

• Enrutar mensajes entre servicios
• Supervisar y controlar el enrutamiento del intercambio de mensajes entre servicios
• Resolver conflictos entre componentes de servicio que se comunican
• Controlar la implementación y el control de versiones de los servicios
• Uso eficiente de servicios redundantes
• Proporcionar servicios básicos como manejo de eventos, transformación y mapeo de datos, puesta en cola y secuenciación de mensajes y eventos, seguridad o manejo de excepciones , conversión de protocolos y aplicación de la calidad adecuada del servicio de comunicación.

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]

• Servicio: denota programas no iterativos y de ejecución autónoma que se comunican con otros servicios a través del intercambio de mensajes.
• Bus: se utiliza en analogía con un bus de hardware de computadora.
• Empresa: el concepto se inventó originalmente para reducir la complejidad de la integración de aplicaciones empresariales dentro de una empresa; la restricción se ha vuelto obsoleta ya que la comunicación moderna por Internet ya no se limita a una entidad corporativa.

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.

• Escala desde soluciones puntuales hasta implementación en toda la empresa (bus distribuido)
• Más configuración que codificación de integración
• No hay un motor de reglas central ni un intermediario central
• Fácil conexión y desconexión y sistema de acoplamiento flexible

• Velocidad de comunicación más lenta, especialmente para aquellos servicios ya compatibles
• Un único punto de fallo puede hacer que se caigan todas las comunicaciones de la empresa.
• Alta complejidad de configuración y mantenimiento

Los productos destacados incluyen:

• Patrones de integración empresarial
• Mensajería basada en eventos
• Integración empresarial con Java
• Gestión de procesos de negocio
• Plataforma de integración universal
• Integración de aplicaciones empresariales
• Proveedor de servicios empresariales
• Entorno de integración médica
• Middleware orientado a mensajes
• Procesamiento de eventos complejos
• Procesamiento de flujo de eventos
• Programación basada en eventos
• Comparación de software de integración empresarial
• Comparación de motores BPEL
• Comparación de motores BPMN 2.0
• Aplicación compuesta
• SOA basada en eventos
• Plataforma de integración como servicio (iPaaS)

• David Chappell, "Enterprise Service Bus" (O'Reilly: junio de 2004, ISBN 0-596-00675-6 ) 
• Binildas A. Christudas, "Integración empresarial Java orientada a servicios" (Packt Publishers: febrero de 2008, ISBN 1-84719-440-0 ; ISBN 978-1-84719-440-4 )  
• Michael Bell, "Modelado orientado a servicios: análisis, diseño y arquitectura de servicios" (2008 Wiley & Sons, ISBN 978-0-470-14111-3 ) 

• “¿Un concepto duradero o la última palabra de moda?” (Nicolas Farges, 2003)
• Los autobuses de servicio empresarial salen a la carretera: Centro de pruebas de Infoworld (22 de julio de 2005)
• JSR-208: Integración empresarial con Java (agosto de 2005)
• El papel del bus de servicios empresariales (InfoQ - Presentación en vídeo) (23 de octubre de 2006)
• Resumen del ESB, primera parte: Definición del ESB (InfoQ) (13 de julio de 2006)
• Resumen de ESB, segunda parte: casos de uso (InfoQ) (5 de julio de 2006)
• "Tejido de servicios: tejidos finos para sistemas de nueva era" (Binildas A. Christudas, 2007)
• "Los ESB en 2007: tomando el autobús del código abierto hacia SOA" (Dennis Byron, 20 de septiembre de 2007)
• Servicios agregados en ServiceMix JBI ESB: PACKT Publishers (Binildas A. Christudas, 30 de noviembre de 2007)
• Alternativas de topología ESB (InfoQ, A. Louis, 23 de mayo de 2008)
• Replanteando el ESB: construyendo un bus de servicio simple, seguro y escalable con una puerta de enlace SOA (Computerworld, J. Ryan, 2011)
• Louis, Adrien; Marc Dutoo (2010-07-02). "Elegir entre enrutamiento y orquestación en un ESB". InfoQ . Consultado el 2009-07-02 .
• El bus de servicios empresariales, reexaminado (IBM Developer Works, Greg Flurry y Kim Clark, mayo de 2011)