En informática un bus de servicios de empresa (BSE) consiste en un combinado de arquitectura de software que proporciona servicios fundamentales para arquitecturas complejas a través de un sistema de mensajes (el bus) basado en las normas y que responde a eventos. Los desarrolladores normalmente implementan un BSE utilizando tecnologías de productos de infraestructura de middleware que se basan en normas reconocidas.

Un BSE 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 BSE no implementa en sí mismo una arquitectura orientada a servicios (AOS), sino que proporciona las características mediantes las cuales sí se puede implementar. Un BSE 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 AOS tradicionales como arquitectura de negocios con una AOS 2.0 enriquecida. El BSE trata de aislar el acoplamiento entre el servicio solicitado y el medio de transporte. La mayoría de los proveedores de BSE incorporan principios de AOS y permiten formatos de mensaje independientes.

Contenido 1 Definiciones y alcance 1.1 Arquitectura de BSE 1.2 BSE como software 2 Características más relevantes 3 Principales beneficios 4 Principales desventajas 5 Véase también 6 Libros 7 Referencias 8 Enlaces externos

Definiciones y alcance

No ha 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 BSE 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 BSE como una plataforma para realizar una arquitectura orientada a los servicios.

Un Bus de Servicios de Empresa (BSE) conlleva conceptos relacionados con flujos, como la transformación y el enrutamiento en una Arquitectura Orientada a los Servicios. Un BSE 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 BSE

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 BSE una aplicación se comunicará a través del bus, que actúa como "divisor 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.

BSE como software

En una arquitectura tan compleja, el BSE representa el elemento de software que media entre las aplicaciones empresariales y permite la comunicación entre ellas. Idealmente el BSE 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 BSE recibe y transmite. Cuando un BSE 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 BSE 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 BSE o no.

Los BSE 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 BSE.

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 BSE como un producto tangible o como un estilo de arquitectura y cómo debe implementarse exactamente un BSE (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 aceptar algunas capacidades centrales como funciones de un BSE:

Categoría	Funciones
Invocación	soporte para protocolos de transporte síncrono y asíncrono, mapeo de servicios (localización y emparejamiento)
Encaminamiento (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]	implemantación de procesos de empresa complejos
Orquestració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 transaciones
Administración	monitorización, auditoría, registro, medición, consola de administración, BAM ("Monitorización de la actividad empresarial").

² While process choreography supports implementation of complex business processes that require coordination of multiple business services (usually using BPEL), service orchestration enables coordination of multiple implementation services (most suitably exposed as an aggregate service) to serve individual requests.

Además, un BSE 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
• 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 BSE
• 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
• Escala de soluciones puntuales a una implementación 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 BSE.
• Mayor latencia general causada por los mensajes que atraviesan la capa extra del BSE, especialmente si se compara con las comunicaciones punto-a-punto. La mayor latencia también se origina por un procesamiento de XML extra (el BSE normalmente utiliza XML como lenguaje de comunicación).
• El BSE se convierte en un elemento único de fallo.
• Aunque los sistemas de BSE pueden requerir un esfuerzo significativo para ser implementados, no producen un valor comercial sin el consiguiente desarrollo de servicios AOS para el BSE.^[2]

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 2009-06-04. "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 (2007-09-27). «ESB-oriented architecture: The wrong approach to adopting SOA». developerWorks. IBM. Consultado el 2009-06-22. «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?" (Nicolas Farges, 2003)
• Enterprise service buses hit the road: Infoworld Test Center (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)
• "Services Fabric—Fine Fabrics for New Era Systems" (Binildas A. Christudas, 2007)
• "ESBs in 2007: Taking the Open Source Bus to SOA" (Dennis Byron, 20 de septiembre de 2007)
• The SOA Stack and the ESB (Noviembre 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 (2008-07-02). «Choosing between Routing and Orchestration in an ESB». InfoQ. Consultado el 2009-07-02.

• Todo o parte de este artículo fue creado a partir de la traducción del artículo Enterprise Service Bus de la Wikipedia en inglés, bajo licencia Creative Commons Compartir Igual 3.0. y GFDL.