Enterprise service bus

En informática un Bus de Servicio Empresarial (ESB por sus siglas en inglés) es un modelo de arquitectura de software que gestiona la comunicación entre servicios web. Es un componente fundamental de la Arquitectura Orientada a Servicios.

ESB

Un ESB generalmente proporciona una capa de abstracción construida sobre una implementación de un sistema de mensajes de empresa que permita a los expertos en integración explotar el valor del envío de mensajes sin tener que escribir código. Al contrario que sucede con la clásica integración de aplicaciones de empresa (IAE) que se basa en una pila monolítica sobre una arquitectura hub and spoke, un bus de servicio de empresa se construye sobre unas funciones base que se dividen en sus partes constituyentes, con una implantación distribuida cuando se hace necesario, de modo que trabajen armoniosamente según la demanda.

Un ESB no implementa en sí mismo una arquitectura orientada a servicios (SOA), sino que proporciona las características mediante las cuales sí se puede implementar. Un ESB debería basarse ^{[cita requerida]} en normas y proporcionar flexibilidad, dando cobertura a distintos medios de transporte que sean capaces de implementar tanto patrones de SOA tradicionales como arquitectura de negocios con una SOA 2.0 enriquecida. El ESB trata de aislar el acoplamiento entre el servicio solicitado y el medio de transporte. La mayoría de los proveedores de ESB incorporan principios de SOA y permiten formatos de mensaje independientes.

Definiciones y alcance

No hay acuerdo sobre si se debe definir un bus de servicios de empresa como un estilo de arquitectura, como un producto de software o como un grupo de productos de software. Si bien es cierto que la utilización de un ESB implica ciertamente ajustarse a una arquitectura determinada, el término "bus de servicios de empresa" casi siempre se refiere a la infraestructura de software que hace posible tal arquitectura y, en esencia, se considera al ESB como una plataforma para realizar una arquitectura orientada a los servicios.

Un Bus de Servicios de Empresa (ESB) conlleva conceptos relacionados con flujos, como la transformación y el enrutamiento en una Arquitectura Orientada a los Servicios. Un ESB también puede proporcionar una abstracción para endpoints. Con esto se consigue flexibilidad en la capa de abstracción y una fácil conexión entre los servicios.^{[cita requerida]}

Arquitectura de ESB

El uso de la palabra "bus" viene del bus que transporta los bits entre los distintos dispositivos de un ordenador. El bus de servicio de empresa proporciona una función análoga a un nivel superior de abstracción. En una arquitectura de empresa que hace uso de un ESB una aplicación se comunicará a través del bus, que actúa como "intermediario de mensajes" (message broker) entre las aplicaciones. Este enfoque tiene la ventaja de que reduce el número de conexión punto-a-punto que se necesitan para permitir que se comunique una aplicación. Esto, a su vez, simplifica el "análisis de impacto" (impact analysis) de la mayor parte del software. Reduciendo el número de puntos de contacto de una aplicación determinada, el proceso de adaptación de un sistema a los cambios de uno de sus componentes se hace más sencillo.

ESB como software

En una arquitectura tan compleja, el ESB representa el elemento de software que media entre las aplicaciones empresariales y permite la comunicación entre ellas. Idealmente el ESB tendría que ser capaz de sustituir todo contacto directo con las aplicaciones en el bus, de modo que toda la comunicación tenga lugar a través del bus. Para lograr este objetivo, el bus debe encapsular la funcionalidad que ofrecen las aplicaciones que lo componen de un modo significativo. Esto sucede normalmente con la implantación de un modelo de mensajes de empresa. El modelo de mensajes define un conjunto de mensajes normalizado que el ESB recibe y transmite. Cuando un ESB recibe un mensaje, lo encamina hacia la aplicación apropiada. A menudo sucede que, como esa aplicación se ha desarrollado sin el mismo modelo de mensajes, el ESB tendrá que transformar el mensaje a un formato de compatibilidad (legacy format) que la aplicación sea capaz de interpretar. Un "adaptador" de software lleva a cabo la tarea de efectuar estas transformaciones (al igual que lo hace un adaptador físico). No hay acuerdo en si se debe considerar este adaptador como constituyente del ESB o no.

Los ESB se basan en la conexión precisa de un modelo de mensajes de empresa y la funcionalidad ofrecida por las aplicaciones. Si el modelo de mensajes no encapsula completamente la funcionalidad de las aplicaciones, entonces otras aplicaciones que desean esa funcionalidad pueden tener que rodear el bus e invocar directamente a las aplicaciones no emparejadas. Esto supone violar todos los principios señalados más arriba y desprecia muchas de las ventajas de la utilización de un ESB.

Características más relevantes

La expresión "Bus de servicio de empresa" sirve a modo de término comodín para un conjunto de capacidades que los sistemas pueden implementar de distinta manera. No existe consenso en si se debe considerar un ESB como un producto tangible o como un estilo de arquitectura y cómo debe implementarse exactamente un ESB (por ejemplo, centralizado (broker o hub) o descentralizado (endpoints inteligentes)). Por ejemplo, que SOAP + WS-Addressing es el bus. De cualquier modo parece haber acuerdo en aceptar algunas capacidades centrales como funciones de un ESB:

Categoría	Funciones
Invocación	soporte para protocolos de transporte síncrono y asíncrono, mapeo de servicios (localización y emparejamiento)
Enrutamiento(Routing)	addressability, encaminamiento estático/determinista, encaminamiento basado en contenidos, encaminamiento basado en normas, encaminamiento basado en políticas
Mediación	adaptadores, transformación de protocolos, mapeo de servicios
Transmisión de mensajes	procesamiento de mensajes, transformación de mensajes y mejora de mensajes
Coreografía de procesos^[1]​	implementación de procesos de empresa complejos
Orquestación de servicios²	coordinación de múltiples servicios de implementación presentados como un único servicio agregado
Procesamiento de eventos complejo	interpretación de eventos, correlación, emparejamiento de patrones
Otros servicios de calidad	seguridad (cifrado y firma), entrega confiable, administración de transacciones
Administración	monitorización, auditoría, registro, medición, consola de administración, BAM ("Monitorización de la actividad empresarial").

² "Mientras que la coreografía de procesos soporta la implementación de procesos de negocio complejos que requieren coordinación de múltiples servicios de negocio (usualmente usando BPEL), la orquestación de servicios permite la coordinación de múltiples implementaciones de servicios (la mayoría expuestos como un solo servicio agregado) para servir consultas individuales"

Además, un ESB debe tener las siguientes características

• Agnosticismo general respecto a sistemas operativos y lenguajes de programación; por ejemplo, debería proporcionar interoperatividad entre aplicaciones Java y .NET
• Uso general de XML como lenguaje de comunicación normalizado^{[cita requerida]}
• Soporte para normas de servicios web
• Soporte para varios MEP (Patrones de intercambio de mensajes) (por ejemplo, petición/respuesta asíncronas, petición/respuesta síncronas, send-and-forget, publicación/suscripción)
• Adaptadores para permitir la integración con sistemas de compatibilidad, posiblemente basados en normas como la (Java_EE_Connector_Architecture|JCA)
• Un modelo de seguridad normalizado para autorizar, autenticar y auditar el uso del ESB
• Facilitación de la transformación de formatos y valores de datos, inclusive los servicios de transformación (normalmente por medio de XSLT o XQuery entre los formatos de la aplicación emisora y la aplicación receptora
• Validación de esquemas para la emisión y recepción de mensajes
• Posibilidad de aplicar normas de empresa uniformemente
• Mensajes enriquecidos de otras fuentes
• La división y combinación de múltiples mensajes y el manejo de excepciones
• La provisión de una abstracción unificada sobre múltiples capas
• Encaminamiento o transformación de mensajes de modo condicional, basándose en una política no-centralizada (sin necesidad de un sistema de normal centralizado)
• Encolamiento y retención de mensajes si las aplicaciones no están temporalmente disponibles

Principales beneficios

• Acomodación de sistemas existentes más rápida y barata
• Mayor flexibilidad; más fácil de cambiar si hay nuevos requisitos.
• Basado en normas
• Posibilidad de escalar desde soluciones puntuales hasta implementaciones de empresa (bus distribuido).
• Tipos de servicio listos-para-funcionar (ready-to-use) predefinidos
• Mayor configuración en vez de tener que codificar la integración.
• Sin motor de normas central, sin divisor central
• Parches incrementales con tiempo de apagado instantáneo; la empresa se hace "refactorizable".

Principales desventajas

• Normalmente requiere un Modelo de Mensajes de Empresa, lo cual exige una administración adicional.
• Requiere una administración constante de versiones de mensajes para asegurar el pretendido beneficio de un emparejamiento flexible. Una administración incorrecta, insuficiente o incompleta de las versiones de mensaje puede ocasionar un emparejamiento estricto en lugar del pretendido emparejamiento flexible.
• Normalmente precisa más hardware que para un simple sistema de mensajes de punto-a-punto.
• Se precisan conocimientos en el análisis de middleware para configurar, administrar y operar un ESB.
• Mayor latencia general causada por los mensajes que atraviesan la capa extra del ESB, especialmente si se compara con las comunicaciones punto-a-punto. La mayor latencia también se origina por un procesamiento de XML extra (el ESB normalmente utiliza XML como lenguaje de comunicación).
• El ESB se convierte en un elemento único de fallo.
• Aunque los sistemas de ESB pueden requerir un esfuerzo significativo para ser implementados, no producen un valor comercial sin el consiguiente desarrollo de servicios AOS para el ESB.

- El desarrollo debe de basarse en eventos, que vienen desde los clientes y la transformación se hace en el ESb^[2]​

Principales Implementaciones

• CX Messenger (Aurea)
• OpenESB implementación en Java.
• Oracle ESB
• Oracle Service Bus (BEA AquaLogic Service Bus)
• Microsoft BizTalk Server
• Windows Azure Service Bus
• IBM WebSphere ESB
• IBM Integration Bus (IBM WebSphere Message Broker)
• JBoss Fuse
• Spring Integration
• Phoenix Service Bus implementación en C#.
• Apache ServiceMix

Véase también

• Java Business Integration
• Business Process Management
• Enterprise application integration
• Programación dirigida por eventos

Libros

• Dave Chappell, "Enterprise Service Bus" (O’Reilly: June 2004, ISBN 0-596-00675-6)
• Binildas A. Christudas, "Service Oriented Java Business Integration" (Packt Publishers: February 2008, ISBN 1-84719-440-0; ISBN 978-1-84719-440-4)
• Michael Bell, "Service-Oriented Modeling: Service Analysis, Design, and Architecture" (2008 Wiley & Sons, ISBN 978-0-470-14111-3)
• Rademakers, Tijs, Dirksen, Jos, "Open-Source ESBs in Action" (2008 Manning, ISBN 1-933988-21-5), http://manning.com/rademakers/

Referencias

1. Richards, Mark. «The Role of the Enterprise Service Bus (presentation)». Consultado el 4 de junio de 2009.  "I do not consider process choreography part of an ESB, if we consider an ESB as a high-speed messaging middleware. However, I do consider process choreography part of the ESB *platform*. Fortunately most ESB vendors separate out these major components into different products, but package them under a consolidated ESB offering. So, in the strictest sense of the word, no, I would not consider it as part of an ESB. It is a related capability."
2. Woolf, Bobby (27 de septiembre de 2007). «ESB-oriented architecture: The wrong approach to adopting SOA». developerWorks. IBM. Consultado el 22 de junio de 2009. «An ESB-oriented architecture doesn't produce business value. A project based on ESB-oriented architecture needs to be made into one based on SOA to help ensure that it successfully delivers business value. » 

Enlaces externos

• "Lasting concept or latest buzzword?" (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). (Nicolas Farges, 2003)
• (22 de julio de 2005)
• JSR-208: Java Business Integration (agosto de 2005)
• The Role of the Enterprise Service Bus (InfoQ - Video Presentation) (23 de octubre de 2006)
• ESB Roundup Part Two: Use Cases (InfoQ) (5 de julio de 2006)
• ESB Roundup Part One: Defining the ESB (InfoQ) (13 de julio de 2006)
• (Binildas A. Christudas, 2007)
• "ESBs in 2007: Taking the Open Source Bus to SOA" (Dennis Byron, 20 de septiembre de 2007)
• Aggregate Services in ServiceMix JBI ESB: PACKT Publishers (Binildas A. Christudas, 30 de noviembre de 2007)
• ESB Topology alternatives (InfoQ, A. Louis, 23 de mayo de 2008)
• Louis, Adrien; Marc Dutoo (2 de julio de 2008). «Choosing between Routing and Orchestration in an ESB». InfoQ. Consultado el 2 de julio de 2009. 

• Esta obra contiene una traducción derivada de «Enterprise Service Bus» de Wikipedia en inglés, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.

•   Datos: Q1061460
•   Multimedia: Enterprise service bus / Q1061460