Un ESB, o bus de servicio empresarial, es un patrón arquitectónico mediante el cual un componente de software centralizado realiza integraciones entre aplicaciones.  Realiza transformaciones de modelos de datos, maneja la conectividad, realiza enrutamiento de mensajes, convierte protocolos de comunicación y potencialmente gestiona la composición de varias solicitudes. El ESB puede hacer que estas integraciones y transformaciones estén disponibles como interfaz de servicio para su reutilización por aplicaciones nuevas. 

El patrón ESB suele implementarse utilizando un tiempo de ejecución y un conjunto de herramientas de integración especialmente diseñados (esto es, un producto esb) que garantizan la mejor productividad posible.

Un ESB es un componente esencial de la SOA, o arquitectura orientada a servicios, una arquitectura de software que surgió a finales de la década de 1990. La SOA define una forma de hacer que los componentes de software sean reutilizables a través de interfaces de servicio. Estos servicios suelen utilizar interfaces estándar (es decir, servicios web) de tal manera que se pueden incorporar rápidamente en nuevas aplicaciones sin tener que duplicar la funcionalidad realizada por el servicio en nuevas aplicaciones.

Cada servicio de una SOA incorpora el código y los datos necesarios para ejecutar una función empresarial completa y discreta (p. ej. comprobar el crédito de un cliente, calcular el pago mensual de un préstamo o tramitar una solicitud de hipoteca). Las interfaces de servicio proporcionan acoplamiento dinámico, lo que significa que se pueden llamar con poco o ningún conocimiento de cómo se implementa el servicio por debajo, reduciendo las dependencias entre las aplicaciones. Las aplicaciones detrás de la interfaz de servicio pueden escribirse en Java, Microsoft .Net, Cobol o cualquier otro lenguaje de programación, suministrarse como paquetes de aplicaciones empresariales por un proveedor (p. ej., SAP), aplicaciones SaaS (p. ej., Salesforce CRM) u obtenerse como aplicaciones de código abierto .  

Las interfaces de servicio se definen con frecuencia mediante el lenguaje de definición de servicios web (WSDL), que es una estructura de etiquetas estándar basada en xml (lenguaje de marcas extensible).  Los servicios se exponen mediante protocolos de red estándar, como SOAP (protocolo simple de acceso a objetos)/HTTP o JSON/HTTP, para enviar peticiones de lectura o cambio de datos. El gobierno del servicio controla el ciclo de vida del desarrollo y, en la etapa adecuada, 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 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 servicio empresarial protege la nueva aplicación de la interfaz heredada. Un ESB realiza la transformación y enrutamiento necesarios para conectarse al servicio del sistema heredado .

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

En teoría, un ESB centralizado ofrece el potencial de estandarizar y simplificar drásticamente la comunicación, la mensajería y la integración entre los servicios en toda la empresa. Los costes de hardware y software se pueden compartir, suministrando los servidores según sea necesario para el uso combinado, proporcionando una solución centralizada escalable.  Un único equipo de especialistas puede ser encargado (y, si es necesario, capacitado) para desarrollar y mantener las integraciones.

Las aplicaciones de software simplemente se conectan ("hablan") al ESB y lo dejan que el ESB transforme los protocolos, enrute los mensajes y los transforme en los formatos de datos según sea necesario, proporcionando la interoperabilidad para ejecutar las transacciones. El método arquitectónico de bus de servicio empresarial 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 empresariales.  Esto permite a los desarrolladores dedicar mucho menos tiempo a la integración y mucho más tiempo a ofrecer y mejorar sus aplicaciones. Y la capacidad de reutilizar estas integraciones de un proyecto a otro ofrecía la posibilidad de aumentar aún más la productividad y el ahorro en sentido descendente.

Pero aunque los ESB se implementaron con éxito en muchas organizaciones, en muchas otras el ESB llegó a considerarse el cuello de botella. La realización de cambios o mejoras en una integración podría desestabilizar a otras que utilizaran esa misma integración. Las actualizaciones del middleware de ESB a menudo afectaban a las integraciones existentes, por lo que era necesario realizar pruebas importantes para realizar cualquier actualización. Como el ESB se gestionaba de forma centralizada, los equipos de aplicaciones no tardaron en hacer cola para sus integraciones. A medida que crecía el volumen de integraciones, la implementación de alta disponibilidad y recuperación ante desastres para los servidores ESB se volvió más costosa. Y como proyecto interempresarial, el ESB resultó difícil de financiar, lo que hizo que estos retos técnicos fueran mucho más difíciles de resolver.

En última instancia, los retos de mantener, actualizar y ampliar un ESB centralizado resultaron ser tan abrumadores y costosos que el ESB a menudo retrasó las mismas ganancias de productividad que él, y la SOA, estaban destinados a producir, frustrando a los equipos de la línea de negocio que esperaban un mayor ritmo de innovación.

Para profundizar en el auge y la caída del ESB, lea "El destino del ESB".

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

• Se mejoró la agilidad y la productividad de los desarrolladores al permitirles 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. 
•  Escalabilidad más sencilla y rentable al permitir escalar cualquier componente independientemente de los demás, para responder con la mayor rapidez posible a las demandas de carga de trabajo y hacer un uso más eficiente de los recursos informáticos.
• Mayor resiliencia, ya que el fallo de un componente no afecta a los demás y cada microservicio puede cumplir sus propios requisitos de disponibilidad sin limitar los demás componentes al requisito de "máxima disponibilidad común".

La misma granularidad que los microservicios aportan al diseño de aplicaciones se puede llevar a la integración, con beneficios similares. Esta es la idea detrás de la integración ágil, que divide el ESB en componentes de integración precisos y descentralizados, sin interdependencias, que los equipos de aplicaciones individuales pueden poseerse y gestionarse ellos mismos.