|
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 alcanceNo 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 ESBEl 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 softwareEn 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 relevantesLa 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:
² "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
Principales beneficios
Principales desventajas
- El desarrollo debe de basarse en eventos, que vienen desde los clientes y la transformación se hace en el ESb[2] Principales Implementaciones
Véase también
Libros
Referencias
Enlaces externos
|
