menu icon

ESB (Enterprise Service Bus)

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 backend (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 reutilizarse en nuevas aplicaciones. El patrón ESB generalmente se implementa en un entorno de ejecución 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 esencial de SOA, o arquitectura orientada a servicios, una arquitectura que surgió a finales de la década de 1990. 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 entre sí, de tal manera que pueden 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 negocios completa y discreta (por ejemplo, verificar el crédito de un cliente, calcular el pago mensual de un préstamo o procesar una solicitud de hipoteca). Las interfaces de servicio brindan un acoplamiento suelto, lo que significa que se pueden llamar con poco o ningún conocimiento sobre la forma de implementación de la integración subyacente. Los servicios se exponen utilizando protocolos de red estándar, como SOAP (protocolo simple de acceso a objetos) /HTTP o JSON/HTTP, para enviar solicitudes para leer o modificar datos. Los servicios se publican de tal forma que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos, para ensamblar nuevas aplicaciones.

Estos servicios se pueden desarrollar desde cero, pero es común que se creen exponiendo funciones de sistemas heredados de registro como interfaces de servicio. Aquí es donde surge la necesidad de un ESB. Los sistemas heredados y los sistemas de registro suelen utilizar protocolos antiguos y formatos de datos privados que deben traducirse e integrarse para trabajar 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 una forma única de exponer las interfaces de servicio, lo que involucra mucho trabajo (incluso si las interfaces son finalmente reutilizables) y crea un importante reto de mantenimiento para el futuro.

Para obtener más información sobre SOA y la función que un ESB desempeña dentro de ella, consulte "Introducción a SOA (arquitectura orientada a servicios)”.

Beneficios

En teoría, un ESB centralizado podría ofrecer la capacidad de estandarizar, y simplificar drásticamente, tanto la comunicación como la integración de servicios en toda la empresa. Los costos 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, capacitado) de desarrollar y mantener las integraciones.

Los desarrolladores pueden usar un solo protocolo para "hablar" con el ESB y emitir comandos que dirijan las interacciones entre los servicios y dejar que el ESB traduzca los comandos, direccione los mensajes y transforme los datos según sea necesario para ejecutar los comandos. 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 y ahorros de productividad en todos los niveles.

Sin embargo, mientras que los ESB se implementaron con éxito en muchas organizaciones, en muchas otras organizaciones el ESB se convirtió en el cuello de botella en la implementación de SOA. Realizar cambios o mejoras en una integración generalmente desestabilizaban a otras. Las actualizaciones del middleware de ESB a menudo afectaban a las integraciones existentes. Debido a que el ESB se gestionaba de forma centralizada, los equipos de aplicaciones pronto se encontraban a la espera de sus integraciones. A medida que el volumen de integraciones aumentó, la implementación de alta disponibilidad y la recuperación de desastres para los servidores ESB se volvió más costosa. Y, como un proyecto entre empresas, el ESB resultó difícil de financiar, lo que hizo que estos desafíos técnicos fueran mucho más difíciles de resolver.

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 una visión más profunda sobre el ascenso y la caída del ESB, lea "El destino del ESB".

ESB frente a microservicios

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

  • Mayor agilidad y productividad de los desarrolladores, al permitirles 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 aportan al diseño de aplicaciones puede llevarse al proceso de integración, con beneficios similares. Esta es la idea detrás de la integración ágil, que desglosa el ESB en componentes de integración finos y descentralizados, sin interdependencias, las cuales los equipos de aplicaciones individuales pueden poseer y gestionar por si mismos.

Para una visión más profunda en todo lo que implican los microservicios, eche un vistazo a "Microservicios: Una guía completa, ""SOA frente a Microservicios: ¿Cuál es la diferencia?", o vea el video 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 nube híbrida, existe una alta probabilidad de que esté transformando diversas cargas de trabajo, incluidas las basadas en patrones SOA y ESB, a modelos de implementación más ligeros y flexibles. Estas transformaciones son solo una parte de la modernización de aplicaciones durante la ruta de cualquier organización hacia la nube.   

Dé el siguiente paso:

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

Empiece hoy mismo con una cuenta de IBM Cloud.