ESB (bus de servicio empresarial)

menu icon

ESB (bus de servicio empresarial)

Esta guía le ofrece más información sobre el ESB (un componente esencial de SOA), los beneficios que ofrece y cómo se relaciona con la arquitectura de microservicios.

¿Qué es un ESB (bus de servicio empresarial)?

Un ESB, o bus de servicio empresarial, es un patrón mediante el cual un componente de software centralizado realiza integraciones a sistemas de fondo (y traducciones de modelos de datos, conectividad profunda, direccionamiento y solicitudes) y hace que esas integraciones y traducciones estén disponibles como interfaces de servicio para que puedan reutilizarlas nuevas aplicaciones. El patrón de ESB se implementa normalmente utilizando un ejecutable de integración especialmente diseñado y un conjunto de herramientas que garantizan la mejor productividad posible.

ESB y SOA

Un ESB es un componente fundamental de SOA, o arquitectura orientada a servicios, una arquitectura que surgió a finales de los años 90. SOA define una forma de hacer que los componentes de software sean reutilizables mediante interfaces de servicio. Estas interfaces utilizan estándares de comunicación comunes de tal manera que puedan incorporarse rápidamente a nuevas aplicaciones sin tener que realizar una integración profunda cada vez.

Cada servicio de una SOA incorpora el código y las integraciones de datos necesarias para ejecutar una función de negocio completa y discreta (por ejemplo, comprobar el crédito de un cliente, calcular un pago de préstamo mensual o procesar una solicitud de hipoteca). Las interfaces de servicio proporcionan un acoplamiento débil, lo que significa que se pueden llamar sin apenas conocimientos, o incluso ningún conocimiento, de cómo se implementa la integración por debajo. Los servicios se exponen utilizando protocolos de red estándar, como SOAP (Simple Object Access Protocol) /HTTP o JSON/HTTP, para enviar solicitudes para leer o cambiar datos. Los servicios se publican de una forma que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas aplicaciones.

Estos servicios se pueden crear desde cero, pero a menudo se crean exponiendo funciones desde sistemas de registro existentes como interfaces de servicio. Aquí es donde surge la necesidad de un ESB. Los sistemas existentes y los sistemas de registro suelen utilizar protocolos antiguos y formatos de datos de propiedad que tienen que traducirse e integrarse para que funcionen con los protocolos de red de SOA. Un ESB realiza estas traducciones e integraciones sobre la marcha. Podría implementar una SOA sin un ESB, pero los propietarios de las aplicaciones tendrían que encontrar su propia forma específica de exponer las interfaces de servicio, lo que supone mucho trabajo (incluso si las interfaces son finalmente reutilizables) y acarrea un importante reto de mantenimiento en el futuro.

Para obtener más información sobre SOA y el rol de un ESB dentro de ella, consulte "Introducción a SOA (arquitectura orientada a servicios)".

Ventajas

En teoría, un ESB centralizado ofrece el potencial de estandarizar, y simplificar drásticamente, la comunicación y la integración de servicios en toda la empresa. Los costes de hardware y software se pueden compartir, el suministro de los servidores solo se tiene que realizar una vez, y un único equipo de especialistas puede ser el encargado (y, si es necesario, formado) de desarrollar y mantener las integraciones.

Los desarrolladores pueden utilizar un único protocolo para "hablar" con el ESB y emitir mandatos que dirigen las interacciones entre servicios y dejarlo en el ESB para traducir los mandatos, direccionar los mensajes y transformar los datos según sea necesario para que se ejecuten los mandatos. Esto permitiría a los desarrolladores pasar mucho menos tiempo integrando y mucho más tiempo configurando y mejorando sus aplicaciones. Y la capacidad de reutilizar estas integraciones de un proyecto a otro ofrece el potencial para mayores ganancias de productividad y un ahorro en sentido descendente.

Sin embargo, mientras que los ESB se desplegaron con éxito en muchas organizaciones, en muchas otras organizaciones el ESB se convirtió en el cuello de botella en el despliegue de SOA. Realizar cambios o mejoras en una integración a menudo desestabilizó a otras. Las actualizaciones del middleware de ESB con frecuencia afectaban a las integraciones existentes. Debido a que el ESB se gestionaba de forma centralizada, los equipos de aplicaciones pronto se encontraron a la espera de sus integraciones. A medida que el volumen de integraciones creció, la implementación de la alta disponibilidad y la recuperación tras desastre para los servidores ESB se volvió más costosa. Y como proyecto entre empresas, el ESB resultó difícil de financiar, dificultando aún más la resolución de las complejidades técnicas.

En última instancia, los retos de mantener, actualizar y escalar un ESB centralizado resultaron tan abrumadores y costosos que el ESB a menudo retrasó las ganancias de productividad que tanto él como SOA tenían previsto impulsar, frustrando a los equipos de línea de negocio que habían anticipado un mayor ritmo de innovación.

Para consultar un análisis más exhaustivo sobre el auge y la caída del ESB, lea "The fate of the ESB".

ESB frente a microservicios

La arquitectura de microservicios permite descomponer los elementos internos de una sola aplicación en pequeñas piezas que se pueden cambiar, escalar y administrar de forma independiente. Los microservicios surgieron y ganaron fuerza con el auge de la virtualización, cloud computing, las prácticas de desarrollo Agile y DevOps. En estos contextos, los microservicios ofrecen lo siguiente:

  • Mayor agilidad y productividad para los desarrolladores ya que permiten a los desarrolladores incorporar nuevas tecnologías en una parte de una aplicación sin tocar el resto de la aplicación.
  • Escalabilidad más sencilla y rentable, porque permiten que cualquier componente se escale independientemente de otros. De esta manera, se garantiza la respuesta más rápida posible a las demandas de carga de trabajo y el uso más eficiente de los recursos informáticos.
  • Mayor resiliencia, debido a que la anomalía de un componente no afecta a los demás, y cada microservicio puede realizar sus propios requisitos de disponibilidad sin estancar a los demás componentes a un requisito de "mayor disponibilidad común".

La misma granularidad que los microservicios aplicada al diseño de aplicaciones puede aplicarse a la integración, con ventajas similares. Esta es la idea en la que se basa la integración ágil, que divide el ESB en componentes de integración descentralizados y detallados, sin interdependencias, que los equipos de aplicaciones individuales pueden tener en propiedad y gestionar ellos mismos.

Para obtener un análisis más detallado sobre los microservicios, consulte "Microservicios: una guía completa", "SOA frente a microservicios: ¿cuál es la diferencia?" y vea el vídeo de Dan Bettinger, "¿Qué son los microservicios?”:

ESB e IBM Cloud

A medida que su empresa cambia su infraestructura de TI hacia un enfoque de  cloud híbrido, existe una alta probabilidad de que esté transformando diversas cargas de trabajo, incluidas las basadas en patrones de SOA y ESB, a modelos de despliegue más ligeros y flexibles. Estas transformaciones son solo una parte de la modernización de aplicaciones en la transición al cloud de cualquier organización.   

Dé el siguiente paso:

  • Descubra cómo puede aprovechar, ampliar y modernizar sus inversiones de middleware con IBM Cloud Pak for Integration.
  • Descubra cómo puede conectar todas sus aplicaciones y datos a través de múltiples clouds privados y públicos para conseguir experiencias del cliente personalizadas visitando IBM Cloud Integration.

Empiece hoy mismo con una cuenta de IBM Cloud.