¿Qué es un ESB?

Un bus de servicios de empresa (ESB) es, en esencia, una arquitectura. Se trata de un conjunto de reglas y principios destinados a integrar diferentes aplicaciones mediante una infraestructura que remeda un bus. Los productos ESB permiten a los usuarios construir este tipo de arquitectura, pero difieren en la forma de hacerlo y las funciones que ofrecen. El concepto fundamental de la arquitectura ESB es la integración de numerosas aplicaciones mediante un bus de comunicación, con el que cada una puede comunicarse. De esta forma, los sistemas se desconectan entre sí y pueden comunicarse sin dependencia ni conocimiento de los otros sistemas del bus. El concepto de ESB nació de la necesidad de alejarse de la integración de punto a punto, que resulta difícil de gestionar con el tiempo. La integración de punto a punto tiene como resultado la dispersión del código de integración personalizado entre las aplicaciones y la ausencia de un método centralizado de supervisión y resolución de problemas. Este fenómeno se conoce a menudo como "código espagueti" y carece de escalabilidad porque crea fuertes dependencias entre las aplicaciones.

Uno de los motivos más habituales por los que las empresas implementan los ESB como columna vertebral de su infraestructura de TI es que incrementan la agilidad organizativa mediante la reducción del tiempo de comercialización de las nuevas iniciativas. Una arquitectura de ESB facilita este proceso mediante un sistema conectable, sencillo, bien definido y con escalabilidad. Asimismo, proporciona una forma de aprovechar los sistemas existentes y exponerlos a las nuevas aplicaciones, gracias a sus funciones de comunicación y transformación.

La arquitectura ESB presenta una serie de principios clave que ofrecen agilidad y escalabilidad a las empresas. El objetivo principal es desvincular los sistemas, a la par que fomentar la comunicación entre los mismos de forma homogénea y gestionable.

• El concepto de "bus" anula la vinculación entre sistemas. Para lograrlo, normalmente se recurre a servidores de mensajería como JMS o AMQP.
• Los datos que se transmiten por el bus presentan un formato canónico, casi siempre XML.
• Existe un "adaptador" que dirige la transferencia de datos entre la aplicación y el bus.
• Este adaptador es responsable de comunicarse con la aplicación de back‑end y transformar los datos del formato de la aplicación al formato del bus. Además, el adaptador también realiza muchas otras tareas relacionadas con la gestión de transacciones de enrutamiento de mensajes, la seguridad, la supervisión, el tratamiento de errores, etc.
• A menudo, los ESB carecen de estado, ya que este viene incorporado en los mensajes que pasan por el bus.
• El formato de mensaje canónico puede entenderse como un contrato entre sistemas. En la práctica, ello hace que el formato de mensaje que pasa por el bus sea siempre el mismo y que todas las aplicaciones presentes en el bus puedan comunicarse entre sí.

Echemos un vistazo a cómo se adapta la arquitectura ESB a nuestros cinco principios esenciales de la integración:

• Coordinación: combinar los componentes existentes de granularidad fina en un único servicio compuesto de orden superior. El objetivo es alcanzar el nivel de granularidad adecuado de los servicios y promover la reutilización y la capacidad de gestión de los componentes subyacentes.
• Conversión: conversión de datos entre formatos canónicos y formatos específicos requeridos por cada conector de ESB. Un ejemplo sería la conversión de formatos CSV, copybooks Cobol o EDI a SOAP/XML o JSON. Los formatos de datos canónicos permiten simplificar en gran medida los requisitos de conversión asociados a grandes implementaciones de ESB donde existen muchos usuarios y proveedores, cada uno con sus propios formatos y definiciones de datos.
• Transporte: negociación de los protocolos de transporte entre diferentes formatos (como HTTP, JMS o JDBC). Nota: Mule trata las bases de datos como un servicio más al hacer de JDBC otro elemento de transporte (o punto de conexión) a través del cual se puede acceder a los datos.
• Mediación: proporcionar diversas interfaces con los siguientes fines: a) admitir diferentes versiones de un servicio para ofrecer retrocompatibilidad, o b) permitir diversos canales para la misma implementación de componente subyacente. Este segundo requisito puede implicar la provisión de varias interfaces al mismo componente, una heredada (archivo plano) y una que sea compatible con los estándares (SOAP/XML).
• Consistencia no funcional: en el caso de una iniciativa corriente de ESB, este principio alude a la forma en que se aplican las políticas de seguridad y supervisión. Asimismo, los objetivos de escalabilidad y disponibilidad se pueden alcanzar utilizando varias instancias de un ESB para proporcionar un rendimiento mejorado (escalabilidad) y eliminar los puntos únicos de fallo (SPOFs), que es el objetivo principal de los sistemas de alta disponibilidad.

En el mercado abundan las plataformas de ESB, que van desde grandes proveedores a empresas de nicho y código abierto. Sobre el papel, tienen muchas similitudes. Estos son algunos de los puntos a tener en cuenta al elegir un ESB.

Mule es la plataforma de integración más ligera del mercado, pues la carga completa de su distribución solo ocupa 40 MB. Su naturaleza es inherentemente modular, lo que permite desconectar módulos si hay necesidad de reducir espacio. "Ligereza" no solo hace referencia al tamaño; también al coste de modificar las integraciones existentes y al esfuerzo necesario para ello. El tiempo de ejecución de Mule ofrece una modularización y un despliegue en caliente superrápido, así como un modelo de configuración gracias al cual reordenar y añadir/modificar funciones resulta más fácil.

La mayoría de proveedores conciben el ESB como un elemento de mediación entre sistemas y tienen productos diferentes para alojar la lógica empresarial y publicar los servicios. Para nosotros, esto entraña una complejidad innecesaria. Mule proporciona un contenedor de servicios ligero y escalable para publicar servicios REST y SOAP. Gracias a la estrecha integración entre Mule y Spring, los desarrolladores pueden aprovechar las funciones de Spring para implementar la lógica empresarial.

La mayoría de proveedores conciben el ESB como un elemento de mediación entre sistemas y tienen productos diferentes para alojar la lógica empresarial y publicar los servicios. Para nosotros, esto entraña una complejidad innecesaria. Mule proporciona un contenedor de servicios ligero y escalable para publicar servicios REST y SOAP. Gracias a la estrecha integración entre Mule y Spring, los desarrolladores pueden aprovechar las funciones de Spring para implementar la lógica empresarial.

Mule usa herramientas que conocen todos los desarrolladores de Java, como Maven, Eclipse, JUnit y Spring. Utiliza un modelo de configuración XML (similar a Spring) para definir la lógica y permite escribir código personalizado en diferentes lenguajes, como Java, Groovy, JavaScript, Ruby y Python, entre otros. Asimismo, Anypoint Studio ayuda a los nuevos desarrolladores a ponerse al día rápidamente con un entorno de desarrollo gráfico.

Mule se ha diseñado para escalarlo horizontalmente en un hardware convencional, sin necesidad de superordenadores. El tiempo de ejecución de Mule se puede incorporar fácilmente en una aplicación. También puede integrarse en servidores de aplicaciones como Tomcat, JBoss y WAS, además de directamente en la aplicación. Y lo que es más importante: Mule ofrece compatibilidad con JUnit para su incorporación en un caso de pruebas de JUnit. Esto es importante porque permite crear pruebas unitarias repetibles para las integraciones que se ejecutan en los ordenadores portátiles de los desarrolladores y se pueden incorporar en versiones continuas.

Una propiedad útil de Mule es que el contenedor es independiente del mensaje. De esta manera, los usuarios no están limitados a los mensajes XML. Si bien el lenguaje XML es muy común, hay otras situaciones en las que es más recomendable utilizar JSON, archivos planos, copybooks Cobol, adjuntos binarios y de archivos, transmisiones y objetos Java. En el aspecto gráfico, Data Mapper ofrece una libertad similar en la ordenación de los datos. Además, la transmisión de Mule permite que los desarrolladores procesen mensajes grandes de manera eficiente.

Si se prefiere dejar la arquitectura de aplicación, el alojamiento y la supervisión de las integraciones a los expertos, CloudHub™ es la opción idónea. CloudHub es una plataforma de integración como servicio (iPaas) que puede iniciarse en cuestión de minutos. CloudHub ofrece una plataforma elástica y de tenencia múltiple con capacidad de conexión a más de 150 servicios de SaaS, redes sociales y arquitectura, así como a aplicaciones internas. Las aplicaciones de CloudHub se pueden ejecutar en Mule y viceversa. De esta manera, no importa si el despliegue se realiza en las instalaciones o en la nube: no hay que aprender nuevos conceptos y la experiencia del desarrollador es la misma. No es necesario aprender nuevos métodos.

La mayoría de organizaciones desean reducir el tiempo de comercialización de sus nuevas iniciativas para ganar agilidad. Los ESB favorecen este objetivo al implementar un sistema conectable, sencillo, bien definido y con gran escalabilidad. En MuleSoft somos conscientes de que una arquitectura de ESB es precisamente eso: una arquitectura y no simplemente un producto estandarizado. Y no solo abarca la infraestructura, sino también el diseño de aplicaciones.

Explora la solución ESB más flexible del mundo, Mule, el motor de tiempo de ejecución de Anypoint Platform, y descubre cómo ayuda a las organizaciones a crear una arquitectura basada en la agilidad y la velocidad.