Un Enterprise Service Bus (ESB) es fundamentalmente una arquitectura. Se trata de un conjunto de reglas y principios para integrar numerosas aplicaciones en una infraestructura tipo bus.
Los productos ESB permiten a los usuarios construir este tipo de arquitectura, pero varían en la forma en que lo hacen y en las capacidades que ofrecen. El concepto central de la arquitectura ESB es que se integran diferentes aplicaciones poniendo un bus de comunicación entre ellas y luego se permite que cada aplicación hable con el bus. Esto desacopla los sistemas entre sí, permitiéndoles comunicarse sin depender o conocer otros sistemas en el bus.
El concepto de ESB nació de la necesidad de alejarse de la integración punto a punto, que se vuelve frágil y difícil de gestionar con el tiempo. La integración punto a punto hace que el código de integración personalizado se distribuya entre las aplicaciones sin una forma centralizada de supervisar o solucionar los problemas. Esto se conoce a menudo como «código espagueti» y no es escalable porque crea estrechas dependencias entre las aplicaciones.
¿Por qué utilizar un ESB?
Aumentar la agilidad de la organización reduciendo el tiempo de comercialización de nuevas iniciativas es una de las razones más comunes por las que las empresas implementan un ESB como columna vertebral de su infraestructura de TI. Una arquitectura ESB facilita esto al proporcionar un sistema simple, bien definido y «enchufable» que se adapta muy bien. Además, un ESB proporciona una forma de aprovechar sus sistemas existentes y exponerlos a nuevas aplicaciones utilizando sus capacidades de comunicación y transformación.
Implementación
La arquitectura ESB tiene algunos principios clave que permiten la agilidad y la escala del negocio. El objetivo principal es desacoplar los sistemas entre sí y permitir que se comuniquen de forma coherente y manejable.
- El concepto de «bus» desacopla las aplicaciones entre sí. Para ello se suele utilizar un servidor de mensajería como JMS o AMQP.
- Los datos que viajan por el bus tienen un formato canónico y casi siempre son XML.
- Hay un «adaptador» entre la aplicación y el bus que se encarga de casar los datos entre las dos partes.
- El adaptador es el responsable de hablar con la aplicación backend y de transformar los datos del formato de la aplicación al formato del bus. El adaptador también puede llevar a cabo una serie de otras actividades, como la gestión de transacciones de enrutamiento de mensajes, la seguridad, la supervisión, la gestión de errores, etc.
- Los ESBs son generalmente sin estado; el estado está incrustado en los mensajes que pasan por el bus.
- El formato canónico de los mensajes es el contrato entre los sistemas. El formato canónico significa que hay un formato de mensaje consistente que viaja por el bus y que todas las aplicaciones del bus pueden comunicarse entre sí
Principios básicos de la integración
Veamos cómo una arquitectura ESB se corresponde con nuestros cinco principios básicos de integración:
- Orquestación: La composición de varios componentes de grano fino existentes en un único servicio compuesto de orden superior. Esto puede hacerse para lograr una «granularidad» adecuada de los servicios y promover la reutilización y la capacidad de gestión de los componentes subyacentes.
- Transformación: Transformación de datos entre formatos de datos canónicos y formatos de datos específicos requeridos por cada conector ESB. Un ejemplo de esto sería la transformación entre los formatos CSV, Cobol copybook o EDI a SOAP/XML o JSON. Los formatos de datos canónicos pueden simplificar en gran medida los requisitos de transformación asociados a una gran implementación de ESB en la que hay muchos consumidores y proveedores, cada uno con sus propios formatos y definiciones de datos.
- Transporte: Negociación del protocolo de transporte entre múltiples formatos (como HTTP, JMS, JDBC). Nota: MuleSoft trata las bases de datos como otro «servicio» haciendo que JDBC sea sólo otro transporte (o punto final) donde se puede acceder a los datos.
- Mediación: Proporcionar múltiples interfaces con el fin de a) soportar múltiples versiones de un servicio para la compatibilidad hacia atrás o, alternativamente, b) para permitir múltiples canales a la misma implementación del componente subyacente. Este segundo requisito puede implicar la provisión de múltiples interfaces para el mismo componente, una interfaz heredada (archivo plano) y una interfaz conforme a los estándares (SOAP/XML).
- Coherencia no funcional: Para una iniciativa típica de ESB, esto puede incluir la coherencia en torno a la forma en que se aplican e implementan las políticas de seguridad y supervisión. Además, los objetivos de escalabilidad y disponibilidad pueden alcanzarse mediante el uso de múltiples instancias de un ESB para proporcionar un mayor rendimiento (escalabilidad) y eliminar los puntos únicos de fallo (SPOF), que es el objetivo clave de los sistemas de alta disponibilidad.
Elección de una plataforma ESB
Existen muchas plataformas ESB, desde grandes proveedores propietarios hasta proveedores de nicho y de código abierto. Sobre el papel, hay muchas similitudes. He aquí algunos puntos que hay que tener en cuenta a la hora de elegir un ESB.
Peso ligero
Mule es la plataforma de integración más ligera disponible, con una distribución completamente cargada que pesa 40 MB. Su diseño es modular, por lo que puede eliminar los módulos no deseados si necesita reducir el tamaño. La «ligereza» no es sólo una cuestión de tamaño; también es el coste de realizar cambios en las integraciones existentes y la cantidad de trabajo pesado que hay que hacer para realizarlos. El tiempo de ejecución de Mule ofrece modularización y un despliegue en caliente superrápido, así como un modelo de configuración que facilita la reordenación y la adición/cambio de funcionalidad.
No sólo mediación
La mayoría de los proveedores piensan en un ESB como una mera mediación entre sistemas y tienen productos separados para alojar la lógica empresarial y publicar servicios. Esto es una complejidad innecesaria. Mule proporciona un contenedor de servicios ligero y escalable para publicar servicios REST y SOAP. Dado que Mule se integra estrechamente con Spring, los desarrolladores también pueden aprovechar las capacidades de Spring para implementar la lógica empresarial.
Accesible – cualquier desarrollador puede aprender Mule
Mule utiliza herramientas comunes con las que todos los desarrolladores de Java están familiarizados, como Maven, Eclipse, JUnit y Spring. Mule utiliza un modelo de configuración XML (similar al de Spring) para definir la lógica, y el código personalizado puede escribirse en diversos lenguajes, como Java, Groovy, JavaScript, Ruby o Python. Además, Anypoint Studio ayuda a los nuevos desarrolladores a ponerse al día rápidamente con un entorno de desarrollo gráfico.
Escalar, reducción de la escala
Mule ha sido diseñado para escalar horizontalmente en hardware básico, sin necesidad de grandes equipos. El tiempo de ejecución de Mule es fácilmente integrable en una aplicación. También se puede incrustar en su servidor de aplicaciones, como Tomcat, JBoss o WAS, o directamente en su aplicación. Y lo que es más importante, Mule es compatible con JUnit, por lo que puede incrustarse en un caso de prueba de JUnit. Esto es poderoso porque significa que puede crear pruebas unitarias repetibles para las integraciones que se ejecutarán en un portátil de desarrollador y pueden incorporarse a una construcción continua.
Agnóstico a los mensajes
Una potente característica de Mule es que el contenedor es agnóstico a los mensajes. Esto significa que no fuerza los mensajes XML a sus usuarios. Aunque XML es común, hay muchos escenarios en los que querrás usar JSON, archivos planos, Copybooks Cobol, archivos adjuntos binarios y de archivo, flujos y objetos Java. Además, el streaming de Mule permite a los desarrolladores procesar grandes mensajes de forma eficiente.
Preparado para la nube
Si prefieres dejar la arquitectura de la aplicación, el alojamiento y la supervisión de su integración a los expertos en integración, entonces CloudHub™ es para ti. CloudHub es una plataforma de integración como servicio (iPaaS) que le permite ponerse en marcha en cuestión de minutos. CloudHub ofrece una plataforma elástica de múltiples arrendatarios con conectividad a más de 150 SaaS, medios sociales y servicios de infraestructura y la capacidad de conectarse a sus aplicaciones locales. Las aplicaciones de CloudHub se ejecutan en Mule standalone y viceversa. Esto significa que, tanto si se despliega on-premise como en la nube, no hay que aprender nuevos conceptos y la experiencia del desarrollador es la misma. No es necesario aprender una nueva forma de hacer las cosas.
Resumen
La mayoría de las organizaciones quieren aumentar la agilidad reduciendo el tiempo de comercialización de las nuevas iniciativas. Los ESBs promueven este objetivo mediante la implementación de un sistema simple, bien definido y «enchufable» que se escala realmente bien. En Disid entendemos que una arquitectura ESB es exactamente eso: una arquitectura y no simplemente un producto que se puede comprar de la estantería. No sólo abarca la infraestructura, sino también el diseño de las aplicaciones.
Explore la solución ESB más flexible del mundo, Mule, el motor de ejecución de Anypoint Platform, y aprenda cómo puede ayudar a las organizaciones a construir una arquitectura basada en la agilidad y la velocidad. Puede ponerse en contacto con nuestros especialistas de MuleSoft que se lo explicarán y demostrarán.
Esto es una adaptación al castellano del interesante post publicado por Mulesoft en su blog en inglés: «What is an ESB?«
