Un  ESB, o  bus de servicios empresariales, es un patrón arquitectónico mediante el cual un componente de software realiza integraciones entre aplicaciones.  Realiza transformaciones de modelos de datos , se encarga de la  conectividad, de la mensajería , realiza enrutamientos, convierte protocolos de comunicación y potencialmente gestiona la composición de múltiples solicitudes. Los  ESB  pueden encargarse de estas integraciones y transformaciones  disponibles como interfaces de servicio para su reutilización por 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  (por ejemplo, productos de  esb ) que garantizan la mejor productividad posible.

Un  ESB  es un componente esencial de la  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. Estos servicios suelen utilizar interfaces estándar (es decir, servicios web) de tal manera que se puedan incorporar rápidamente a nuevas aplicaciones sin tener que duplicar la  funcionalidad  realizado por el servicio en nuevas aplicaciones.

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, 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 acoplamiento suelto, lo que significa que se pueden invocar con poco o ningún conocimiento de cómo el servicio  se implementa de manera subyacente, reduciendo las dependencias entre aplicaciones. Las aplicaciones detrás de la interfaz de servicios se pueden escribir en  Java,  Microsoft .Net, Cobol o en cualquier otro lenguaje de programación, suministrado como aplicaciones de software empaquetadas por un proveedor (por ejemplo,  SAP),  aplicaciones SaaS  (por ejemplo, Salesforce  CRM) u obtenidas como aplicaciones de  código abierto .  

Las interfaces de servicio se definen con frecuencia utilizando un  Lenguaje de Descripción de Servicios Web  (WSDL), que es una estructura de etiqueta estándar basada en  xml  (lenguaje de marcado extensible).  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 cambiar datos. El gobierno del servicio controla el ciclo de vida para el desarrollo y, en la etapa que corresponde, los servicios se publican en un registro  que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas aplicaciones o  procesos de negocio.

Los servicios se pueden crear desde cero, pero a menudo se crean exponiendo funciones de sistemas heredados  de registro. Las empresas pueden optar por proporcionar una interfaz de servicio basada en estándares frente a los  sistemas heredados, utilizar el ESB para conectarse directamente al  sistema heredado a través de un adaptador o conector, o la aplicación puede proporcionar su propia  API. En cualquier caso,  el bus de servicios empresariales  protege la nueva aplicación de la interfaz heredada. Un  ESB realiza la transformación necesaria y los  enrutamientos  precisos para conectarse al sistema de  Servicio heredado.

Es posible implementar una  SOA sin  una arquitectura  ESB , pero esto equivaldría a tener un montón de servicios.  Cada responsable de la aplicación debería conectarse directamente a cualquier servicio que necesite y realizar las transformaciones de datos necesarias para cumplir con cada una de las  interfaces de servicio. Esto es mucho trabajo (incluso si las interfaces son reutilizables) y crea importantes desafíos de mantenimiento en el futuro, ya que cada conexión es punto a punto.

En teoría, un  ESB  centralizado podría ofrecer la capacidad de estandarizar, y simplificar drásticamente  tanto la comunicación, la mensajería y la integración de servicios en toda la empresa. Los costos de hardware y software se pueden compartir al incorporarlos a los servidores según sea necesario para el uso combinado, proporcionando una solución centralizada escalable.  Un solo equipo de especialistas puede tener la tarea (y, si es necesario, capacitarse) para desarrollar y mantener las integraciones.

Aplicaciones de software simplemente conecte ('hablar') al ESB y deje que  ESB transforme los protocolos, enrute los mensajes y que los transforme en formatos de datos  según sea necesario, proporcionando la interoperabilidad para ejecutar las transacciones. El  enfoque arquitectónico orientado  al servicio admite escenarios para la integración de aplicaciones , la integración de datos  y la automatización del estilo  de  orquestación  de servicios de los procesos de negocio o  flujos de trabajo .  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. Hacer cambios o mejoras en una integración podría desestabilizar a otras  que usó esa misma integración. Las actualizaciones del middleware de  ESB  a menudo ha afectado a las integraciones existentes,  por lo que se requirieron pruebas importantes para realizar cualquier actualización. 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 conocer más detalles sobre el ascenso y la caída del ESB, lea "El destino de la ESB . "

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 cobraron fuerza con el auge de la  virtualización,  la computación en la nube, las prácticas de desarrollo de Agile y los  DevOps. En estos contextos, los  microservicios  ofrecen lo siguiente:

• Mayor agilidad y productividad del desarrollador , al permitir a los desarrolladores incorporar nuevas tecnologías en una parte de una aplicación sin tocar o "ponerse al día" con el resto de la aplicación. 
• Tiene una escalabilidad más simple y más eficiente en costos , pues permite  que se escale independientemente de otros, por lo que 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 más detalles sobre los microservicios, eche un vistazo "Microservicios: una guía completa, ""SOA  vs. Microservicios: ¿Cuál es la diferencia?"y mire el video de Dan Bettinger," ¿Qué son los  Microservicios? ":

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 parte  de la modernización de aplicaciones requerida  ya que la demanda de mejores experiencias de los clientes y más aplicaciones impacta en sus operaciones comerciales y de TI. Cuando se trata de satisfacer tales demandas, también ayuda un movimiento hacia una mayor automatización. Lo ideal sería comenzar con pequeños proyectos cuyo éxito sea mensurable, que luego pueda escalar y optimizar para otros procesos y en otras partes de su organización.

Al trabajar con IBM, usted tendrá acceso a  funcionalidades de automatización basadas en IA, incluyendo flujos de trabajo preintegrados, para ayudar a acelerar la innovación haciendo que cada proceso sea más inteligente. 

Dé el siguiente paso:

• Vea cómo puede aprovechar, ampliar y modernizar sus inversiones en middleware conIBM Cloud Pak for Integration, una solución de integración híbrida que proporciona un ciclo de vida automatizado y de ciclo cerrado en múltiples estilos de integración empresarial.
• Descubra cómo puede conectar todas sus aplicaciones y datos en múltiples nubes  privada  y públicapara crear experiencias personalizadas para los clientes visitando Integración de IBM en la nube.
• Obtenga la Guía de campo de modernización de aplicaciones de IBM para descubrir cómo acelerar la modernización, mejorar la productividad de los desarrolladores y mejorar la eficiencia operativa y la estandarización.
• Realice nuestra evaluación de madurez de la integración para evaluar el nivel de  madurez de su integración en dimensiones críticas y descubra las acciones que puede llevar a cabo para pasar al  siguiente nivel. 
• Descargue nuestraguía de integración de Agile, que explora los méritos de un enfoque basado en contenedores, descentralizado y alineado con microservicios para la integración de soluciones. 
• Lea acerca de los cinco puntos "imprescindibles" para el éxito de la automatización (enlace externo a ibm.com)  en este informe de HFS Research.

Empiece con una cuenta de IBM Cloud hoy mismo.