Un bus de servicio empresarial ( ESB ) implementa un sistema de comunicación entre aplicaciones de software que interactúan mutuamente 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 protocolo de alto nivel entre aplicaciones. Su uso principal es la integración de aplicaciones empresariales (EAI) de entornos de servicios heterogéneos y complejos.
Arquitectura
El concepto de bus de servicio empresarial es análogo al concepto de bus que se encuentra en la arquitectura de hardware de computadora combinado con el diseño modular y simultáneo de sistemas operativos de computadora 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 débilmente acoplados (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 servicio empresarial 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 basado en eventos en combinación con colas de mensajes como marcos tecnológicos. [2] Sin embargo, algunos fabricantes de software vuelven a etiquetar las soluciones de comunicación y middleware existentes como ESB sin adoptar el aspecto crucial de un concepto de bus.
Funciones
Un ESB aplica el concepto de diseño de sistemas operativos modernos a servicios independientes que se ejecutan dentro de redes de computadoras independientes y dispares. Al igual que los sistemas operativos simultáneos, un ESB proporciona servicios básicos además de la adopción, traducción y enrutamiento de las solicitudes de los clientes a los servicios de respuesta adecuados.
Los deberes principales de un ESB son:
- Enrutar mensajes entre servicios
- Supervisar y controlar el enrutamiento del intercambio de mensajes entre servicios
- Resolver la disputa entre los componentes del servicio en comunicación
- Controlar la implementación y el control de versiones de los servicios
- Uso de Marshal 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, manejo de seguridad o excepciones , conversión de protocolo y cumplimiento de la calidad adecuada del servicio de comunicación.
Historia
El primer uso publicado del término "bus de servicio empresarial" se atribuye a Roy W. Schulte de Gartner Group 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 antepasado más directo de la ESB fue el producto Roma de Candle. desde 1998 " [3] cuyo arquitecto jefe y titular de la solicitud de patente era Gary Aven. Roma se vendió por primera vez en 1998, lo que lo convierte en el primer ESB comercial en el mercado, pero el producto de Sonic de 2002 también fue uno de los primeros ESB en el 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 usa de manera análoga a 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
ESB como software
El ESB se implementa en un software que opera entre las aplicaciones comerciales 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 suele ocurrir mediante el uso de un modelo de mensaje empresarial . El modelo de mensaje define un conjunto estándar de mensajes que el ESB transmite y recibe. Cuando el ESB recibe un mensaje, lo enruta a la aplicación correspondiente. A menudo, debido a que esa aplicación evolucionó sin el mismo modelo de mensaje, el ESB tiene que transformar el mensaje en un formato que la aplicación pueda interpretar. Un adaptador de software cumple la función de efectuar estas transformaciones, de forma análoga a un adaptador físico . [5]
Los ESB se basan en la construcción precisa del modelo de mensaje empresarial y en el diseño adecuado de la funcionalidad que ofrecen las aplicaciones. Si el modelo de mensaje no encapsula completamente la funcionalidad de la aplicación, entonces otras aplicaciones que deseen esa funcionalidad pueden tener que pasar por alto el bus e invocar las aplicaciones que no coinciden directamente. Hacerlo viola los principios del modelo ESB y niega muchas de las ventajas de usar esta arquitectura.
La belleza del ESB radica en su naturaleza independiente de la plataforma y 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 realmente apliquen todas las capacidades de ESB en sus productos de integración mientras adoptan SOA . Por lo tanto, los desafíos y 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.
Caracteristicas
Categoría | Funciones |
---|---|
Invocación | soporte para protocolos de transporte síncronos y asíncronos, mapeo de servicios (localización y enlace) |
Enrutamiento | direccionabilidad, enrutamiento estático / determinista, enrutamiento basado en contenido, enrutamiento basado en reglas, enrutamiento basado en políticas |
Mediación | adaptadores, transformación de protocolos, mapeo de servicios |
Mensajería | procesamiento de mensajes, transformación de mensajes y mejora de mensajes |
Coreografía de proceso ¹ | implementación de procesos comerciales complejos |
Orquestación de servicios ² | coordinación de múltiples servicios de implementación expuestos como un solo servicio agregado |
Procesamiento de eventos complejos | interpretación de eventos, correlación, coincidencia de patrones |
Otra calidad de servicio | seguridad (cifrado y firma), entrega confiable, gestión de transacciones |
Gestión | monitoreo, auditoría, registro, medición, consola de administración, BAM (BAM no es una capacidad de administración, en otras palabras, el ESB no reacciona a un umbral específico. Es una capacidad de servicio comercial que se muestra a los usuarios finales). |
Agnosticismo | agnosticismo general a los sistemas operativos y lenguajes de programación; por ejemplo, debería permitir la interoperabilidad entre aplicaciones Java y .NET |
Conversión de protocolo | Soporte integral para estándares de servicio de protocolos de comunicación de actualidad. |
Patrones de intercambio de mensajes | soporte para varios MEP ( patrones de intercambio de mensajes ) (por ejemplo: solicitud / respuesta sincrónica, solicitud / respuesta asincrónica, enviar y olvidar, publicar / suscribirse) |
Adaptadores | adaptadores para admitir la integración con sistemas heredados, posiblemente basados en estándares como JCA |
Seguridad | un modelo de seguridad estandarizado para autorizar, autenticar y auditar el uso del ESB |
Transformación | Facilitación de la transformación de formatos y valores de datos, incluidos los servicios de transformación (a menudo a través de XSLT o XQuery ) entre los formatos de la aplicación de envío y la aplicación de recepción. |
Validación | validación contra esquemas para enviar y recibir mensajes |
Gobernancia | la capacidad de aplicar las reglas comerciales de manera uniforme |
Enriquecimiento | enriquecimiento de mensajes de otras fuentes |
Dividir y fusionar | la división y combinación de múltiples mensajes y el manejo de excepciones |
Abstracción | la provisión de una abstracción unificada a través de múltiples capas |
Enrutamiento y transformación | enrutar o transformar mensajes de forma condicional, basándose en una política no centralizada (sin la necesidad de un motor de reglas central) |
Servicios de productos básicos | Suministro de funciones de uso común como servicios compartidos según el contexto. |
¹ Algunos no consideran la coreografía de procesos como una función de ESB. Por ejemplo, consulte M.Richards. [6]
² Si bien la coreografía de procesos admite la implementación de procesos comerciales complejos que requieren la coordinación de múltiples servicios comerciales (generalmente usando 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 la conectividad, el enrutamiento y la transformación, y requieren codificación o secuencias de comandos 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 todo múltiples proyectos. [8]
Si el intermediario 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 de esquina que generalmente son conocidos solo por desarrolladores que tienen una amplia experiencia con la aplicación. que está conectado al ESB. Para los casos de esquina conocidos, el número de pruebas que cubren todos los casos de esquina aumenta exponencialmente con cada aplicación que está conectada al ESB, porque cada aplicación conectada a ESB debe probarse con todas las demás aplicaciones que están conectadas al ESB.
Beneficios clave
- Escala desde soluciones puntuales hasta implementación en toda la empresa (bus distribuido)
- Más configuración en lugar de codificación de integración
- Sin motor de reglas central, sin intermediario central
- Fácil de enchufar y desenchufar y sistema de acoplamiento holgado
Desventajas clave
- Velocidad de comunicación más lenta, especialmente para aquellos servicios que ya son compatibles
- Un solo punto de falla , puede interrumpir todas las comunicaciones en la empresa
- Alta complejidad de configuración y mantenimiento
Productos
Los productos notables incluyen:
- Propiedad
- Candle's Roma ESB: comprado por IBM y convertido en WebSphere ESB
- IBM App Connect, anteriormente IBM Integration Bus e IBM WebSphere ESB
- Conjunto de InterSystems
- Information Builders iWay Service Manager
- Bus de servicio de Microsoft Azure
- Microsoft BizTalk Server
- Mula ESB
- Bus de servicio empresarial de Oracle
- Progress Software Sonic ESB (adquirido por Trilogy )
- Integración de procesos de SAP
- Software TIBCO ActiveMatrix BusinessWorks
- bus de servicio empresarial webMethods (adquirido por Software AG )
- Sonic ESB de Aurea
- Software de código abierto
- Camello apache
- Apache ServiceMix
- Apache Synapse
- Fuse ESB de Red Hat
- JBoss ESB
- NetKernel
- ESB abierto
- Pétalos ESB
- Integración de primavera
- UltraESB
- WSO2 ESB
Ver también
- Patrones de integración empresarial
- Mensajería impulsada por eventos
- Integración empresarial de Java
- Gestión de Procesos de Negocio
- Plataforma de integración universal
- Integración de aplicaciones empresariales
- Proveedor de servicios comerciales
- Middleware orientado a mensajes
- Procesamiento de eventos complejos
- Procesamiento de flujo de eventos
- Programación impulsada por 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 impulsada por eventos
- Plataforma de integración como servicio (iPaaS)
Referencias
- ^ Lapeira, Raúl. "¿ESB es un estilo arquitectónico, un producto de software o un grupo de productos de software?" . Consultoría de artefactos. Archivado desde el original el 8 de agosto de 2014 . Consultado el 16 de abril de 2010 .
Lo primero que debe tener en cuenta un arquitecto de ESB es que a partir de 2010 no existe un estándar global para ESB.
- ^ Curry, Edward. 2004. "Middleware orientado a mensajes" [ enlace muerto permanente ] . En Middleware para comunicaciones , ed. Qusay H. Mahmoud, 1º a 28. Chichester, Inglaterra: John Wiley and Sons. doi : 10.1002 / 0470862084.ch1 . ISBN 978-0-470-86206-3
- ^ McKendrick, Joe. "La gran pelea de la ESB de 2005" . ZDNet . Consultado el 31 de diciembre de 2020 .
- ^ "Diferencia entre un Message Broker y un ESB" . Consultado el 19 de julio de 2017 .
- ^ http://shop.oreilly.com/product/9780596006754.do
- ^ Richards, Mark. "El papel de Enterprise Service Bus (presentación)" . Consultado el 4 de junio de 2009 .
No considero que la coreografía de procesos sea parte de un ESB, si consideramos un ESB como un middleware de mensajería de alta velocidad. Sin embargo, considero que la coreografía de procesos es parte de la plataforma ESB *. Afortunadamente, la mayoría de los proveedores de ESB separan estos componentes principales en diferentes productos, pero los empaquetan en una oferta ESB consolidada. Entonces, en el sentido más estricto de la palabra, no, no lo consideraría parte de un ESB. Es una capacidad relacionada.
- ^ Feraga, Matthias (6 de junio de 2011). "Cómo: elegir entre ESB ligeros y tradicionales" . Octo . Consultado el 23 de abril de 2014 .
- ^ Fulton, Larry (12 de septiembre de 2007). "Aprenda a adoptar ESB ligeros" . Fo2014.
Otras lecturas
- 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 )
enlaces externos
- "¿Concepto duradero o última palabra de moda?" (Nicolas Farges, 2003)
- Los autobuses de servicio empresarial salen a la carretera: Infoworld Test Center (22 de julio de 2005)
- JSR-208: Java Business Integration (agosto de 2005)
- El papel del Bus de servicios empresariales (InfoQ - Presentación en video) (23 de octubre de 2006)
- Resumen de ESB, primera parte: Definición de ESB (InfoQ) (13 de julio de 2006)
- Resumen de ESB, segunda parte: casos de uso (InfoQ) (5 de julio de 2006)
- "Tejidos de servicios: tejidos finos para sistemas de la nueva era" (Binildas A. Christudas, 2007)
- "ESB en 2007: llevar el bus de código abierto a 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 de ESB (InfoQ, A. Louis, 23 de mayo de 2008)
- Repensar el ESB: construir un bus de servicio simple, seguro y escalable con una puerta de enlace SOA (Computerworld, J. Ryan, 2011)
- Louis, Adrien; Marc Dutoo (2 de julio de 2010). "Elección entre enrutamiento y orquestación en un ESB" . InfoQ . Consultado el 2 de julio de 2009 .
- Enterprise Service Bus, reexaminado (IBM developer Works, Greg Flurry y Kim Clark, mayo de 2011)