Enterprise service bus

En informática, un bus de servicio empresarial (BSE, del inglés Enterprise Service Bus o ESB) 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 (del inglés Service-Oriented Architecture o SOA).

Un ESB proporciona una capa de abstracción que permite enviar mensajes a sus distintos servicios sin tener que escribir código. A diferencia de la integración de aplicaciones 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, 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 una definición de bus de servicios de empresa aceptada mayoritariamente. 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, 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, algunos expertos en AOS dicen 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
Zato (open-source, en Python)

Véase también

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

↑ 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."
↑ 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.»