Entender la integración empresarial de aplicaciones: las ventajas del ESB para la EAI

En la infraestructura empresarial de la actualidad, la integración de aplicaciones y sistemas es una preocupación cada vez más frecuente e importante. La amplia variedad de enfoques e ideas destinados a alcanzar este objetivo son la prueba de ello. Cuando se empiezan a investigar las soluciones de integración de datos y aplicaciones, es fácil perderse en un maremágnum de siglas, opiniones y una jerga confusa de marketing.  

Los rápidos avances en la tecnología de EAI para hacer frente a la creciente demanda de integración empresarial a menudo dan lugar a discusiones sobre lo que es o no es la EAI, o sobre cómo las pequeñas diferencias entre el enfoque de una marca u otra hacen de ella la única solución viable.

En este artículo, disiparemos la confusión en torno a la evolución de la EAI con un análisis estructurado y fácil de comprender.  

Empezaremos por una breve historia de los orígenes de la EAI, haremos un recorrido por los principales avances en la arquitectura de EAI y descubriremos cómo los sistemas EAI "hub and spoke" basados en intermediarios tradicionales están siendo sustituidos por arquitecturas de bus de servicios de empresa ágiles, distribuidas y basadas en estándares.

Índice

I. Los orígenes de la EAI

A. Cuando la integración de punto a punto no es suficiente

B. El enfoque de EAI

II. EAI tradicional

A. El modelo de intermediario

B. Ventajas y desventajas

III. ESB: el siguiente paso en la EAI

A. Funciones esenciales

B. Ventajas

C. Cuándo usar un ESB

I. Los orígenes de la EAI

La integración de aplicaciones empresariales, EAI por sus siglas en inglés, ha existido como tecnicismo desde principios de los años 2000, pero el problema central que trata de resolver se remonta a mucho antes. En pocas palabras, la EAI es una categoría general de enfoques que proporcionan interoperabilidad entre los sistemas dispares que típicamente componen las infraestructuras.

Las arquitecturas empresariales, por naturaleza, suelen estar compuestas por numerosos sistemas y aplicaciones, que proporcionan servicios de los que depende la empresa para llevar a cabo su actividad diaria. Una sola organización puede utilizar sistemas independientes, ya sean desarrollados internamente o utilizados con licencia de un proveedor externo, para gestionar su cadena de suministro, las relaciones con los clientes, la información de los empleados y la lógica empresarial. Esta modularización es a menudo un aspecto deseable. En teoría, dividir la tarea de dirigir una empresa en pequeñas funciones permite implementar fácilmente los mejores y más recientes avances tecnológicos en cada ámbito, así como una adaptación rápida a las cambiantes necesidades empresariales.  

No obstante, para cosechar los frutos de este sistema modular y distribuido, una organización debe implementar tecnologías capaces de lidiar con los problemas asociados a esta arquitectura:

• Interoperabilidad: es posible que los diferentes componentes de la infraestructura utilicen distintos sistemas operativos, formatos de datos y lenguajes, lo que impide la conexión mediante una interfaz estándar.
• Integración de datos: para que un sistema distribuido y modular sea funcional, es imprescindible disponer de un método estandarizado para la gestión del flujo de datos entre las aplicaciones y los sistemas, a fin de garantizar la coherencia en la base de datos.
• Solidez, estabilidad y escalabilidad: son el pegamento de una infraestructura, por lo que las soluciones de integración deben tener estas características.

Cuando la integración de punto a punto no es suficiente

Antes del desarrollo de los enfoques de tipo EAI, los problemas de integración se gestionaban utilizando integraciones de punto a punto. Según este modelo, se implementa un conector único para cada par de aplicaciones o sistemas que deben comunicarse entre sí. Este conector gestiona la transformación e integración de datos, así como otros servicios de mensajería, que deben producirse únicamente entre el par específico de componentes para el que se ha diseñado.

Cuando se utiliza en infraestructuras pequeñas, en casos donde solo hay que integrar dos o tres sistemas, este modelo funciona bastante bien y proporciona una solución de integración ligera y a medida de las necesidades de la infraestructura. Sin embargo, a medida que se añaden nuevos componentes a la infraestructura, el número de conexiones de punto a punto necesarias para crear una arquitectura de integración completa empieza a crecer exponencialmente.

Una infraestructura de tres componentes solo requiere tres conexiones de punto a punto para que su integración pueda considerarse completa. Pero si se le quieren añadir tan solo dos componentes más, hay que incrementar el número de conectores a 10. Nos acercamos entonces a un nivel de complejidad intratable, y una vez que la infraestructura incluye 8 o 9 sistemas componentes y el número de conexiones ascienda a la treintena, la integración de punto a punto deja de ser una opción viable. 

Si tenemos en cuenta que cada uno de estos conectores debe desarrollarse y mantenerse de manera independiente ante los cambios de versión del sistema y de escala, entre otros (en algunos casos deben incluso comprarse a un proveedor a un alto precio), entonces queda perfectamente claro que las integraciones de punto a punto no son adecuadas para situaciones empresariales complejas.

El enfoque de EAI para la integración

Para evitar la complejidad y los errores propios de la integración de infraestructuras complejas a través de un enfoque de punto a punto, las soluciones de EAI utilizan varios modelos de middleware pare centralizar y estandarizar prácticas de integración en toda la infraestructura.  

Así, cada aplicación deja de necesitar un conector aparte para vincularse al resto de conectores; en su lugar, los componentes de una infraestructura basada en EAI utilizan métodos estandarizados para conectarse a un sistema común que es responsable de proporcionar funciones de integración, entrega de mensajes y fiabilidad a toda la red.

En otras palabras, la EAI resuelve el problema de la integración de sistemas modulares al tratarla como una tarea del sistema como cualquier otra, en lugar de una maraña de enrevesadas conexiones. Los sistemas de EAI agrupan los adaptadores para mejorar la conectividad, los motores de transformación de datos para convertir datos a un formato adecuado para el usuario, los motores de integración modular para gestionar simultáneamente numerosas situaciones de enrutamiento complejas, y otros componentes para presentar una solución de integración unificada.

La EAI relaja las apretadas conexiones de la integración de punto a punto. Una aplicación puede enviar un mensaje sin conocimiento de la ubicación del usuario ni de sus requisitos de datos o el propósito del mensaje: toda esta información se gestiona a través de la implementación de EAI. Así, la arquitectura es más flexible, y las partes se pueden añadir y eliminar según sea necesario; solo hay que cambiar la configuración del proveedor de EAI. Además, se simplifica el desarrollo modular, con el cual un servicio puede ser reutilizado por varias aplicaciones.

Muchos enfoques de EAI modernos también aprovechan la oportunidad que supone añadir un mecanismo de integración central para aglutinar aún más las tareas de mensajería. Además de la integración de datos, una EAI moderna también incluye funciones de administración, seguridad, aceleración y escalabilidad de redes, entre otras.

II. EAI tradicional

Las primeras soluciones de EAI del mercado partían de la idea de unificar la integración literalmente, e incorporaban todas las funciones necesarias para la integración en centros de recursos, llamados intermediarios.  

En esta sección, analizaremos las ventajas y desventajas de este modelo, y descubriremos por qué se ha abandonado en favor de la arquitectura ESB. 

El modelo de intermediario

En un enfoque de intermediario para la EAI, un motor de integración central, llamado intermediario, reside en el centro de la red, y proporciona todas las funciones de transformación, enrutamiento y otras funcionalidades cruzadas de aplicaciones. Toda la comunicación entre las aplicaciones debe pasar por el centro de recursos, lo que permite mantener la simultaneidad de los datos para toda la red. 

Normalmente, las implementaciones del modelo de intermediario también proporcionan herramientas de supervisión y auditoría que permiten a los usuarios acceder a información sobre el flujo de mensajes por los sistemas, así como herramientas que aceleran la complicada tarea de configurar la asignación y el enrutamiento entre grandes cantidades de sistemas de aplicaciones.

Ventajas

Al igual que todos los enfoques de EAI para la integración, el modelo de intermediario permite una conexión más suelta entre las aplicaciones.  

En otras palabras, las aplicaciones pueden comunicarse de manera asíncrona, enviando mensajes y trabajando sin necesidad de esperar una respuesta por parte del receptor, siempre con el conocimiento exacto de cómo llegará el mensaje al punto de conexión y, en algunos casos, del propio punto de conexión del mensaje.

El enfoque de intermediario también permite realizar toda la configuración de integración dentro de un repositorio central, lo que implica una configuración menos repetitiva.

Desventajas

Como en cualquier otro modelo de arquitectura que utilice un motor central, el intermediario puede convertirse en un punto único de fallo para la red. Dado que el intermediario es responsable de mantener la simultaneidad entre todos los conjuntos de datos y estados de las aplicaciones, todos los mensajes entre solicitantes deben pasar por él.  

Si está sometido a una fuerte carga de trabajo, el intermediario puede convertirse en un cuello de botella para los mensajes. El hecho de ser un destino central único para todos los mensajes también dificulta utilizar el modelo de intermediario con éxito a lo largo de grandes distancias geográficas.  

Por último, las implementaciones del modelo de intermediario son a menudo productos pesados, patentados, cuyo objetivo es respaldar el subconjunto de tecnología concreto de un proveedor. Esta circunstancia puede suponer problemas si la situación de integración abarca productos de varios proveedores, sistemas desarrollados internamente y productos heredados que ya no son compatibles con el proveedor.

III. ESB: el siguiente paso en la EAI

El modelo de intermediario de EAI fue implementado con éxito por algunas empresas, pero la amplia mayoría de proyectos de integración que utilizaron este modelo acabaron fracasando. La falta de estándares claros para la arquitectura de EAI, sumada al hecho de que muchas de las primeras soluciones estaban patentadas, hizo que los productos de EAI fueran caros, pesados y que algunas veces no funcionaran como se deseaba a menos que el sistema fuera bastante homogéneo.  

Las consecuencias de estos problemas se vieron amplificadas por el hecho de que el modelo de intermediario hacía del sistema de EAI un punto único de fallo para la red. Si un solo componente dejaba de funcionar correctamente, toda la red fallaba. En 2003, un estudio estimó que el 70% de los proyectos de integración acabaron fracasando debido a los defectos de las primeras soluciones de intermediario.

Arquitectura de bus: un nuevo enfoque para la EAI

En un intento de eludir los problemas que causaba el enfoque de EAI "hub and spoke" con intermediario, surgió un nuevo modelo de EAI: el bus. A pesar de que seguía necesitando un componente de enrutamiento central para transferir mensajes entre sistemas, la arquitectura de bus buscó aliviar la carga de funcionalidad que sufrían los componentes individuales distribuyendo algunas de las tareas de integración a otras partes de la red.

Así, estos componentes se podían agrupar en distintas configuraciones mediante archivos de configuración para gestionar cualquier situación de integración de la manera más eficiente posible, así como alojarse en cualquier parte de la infraestructura o duplicarse para poder escalarse mejor entre grandes regiones geográficas.

El nacimiento del bus de servicio de empresa

Con la evolución de la EAI basada en bus, se identificaron una serie de funciones necesarias, como el procesamiento de transacciones de seguridad, la gestión de errores y muchas más. La arquitectura de bus no requería grandes esfuerzos de codificación para integrar estas funciones en la lógica de integración central, como sucedía en la arquitectura de intermediario, sino que permitía agregarlas en componentes separados.  

El resultado final fueron soluciones de integración ligeras y a medida que garantizaban fiabilidad, se abstraían completamente de la capa de aplicación, seguían un patrón coherente y se podían diseñar y configurar sin mucho código adicional ni modificaciones en los sistemas que iban a integrarse.

Esta versión madura de este modelo de EAI basado en bus terminó conociéndose como bus de servicios de empresa, o ESB por sus siglas en inglés.

Funciones centrales del ESB

En la actualidad, existen diferentes productos de ESB en el mercado. Algunos, como WebSphere Message Broker o TIBCO BusinessWorks, son productos de EAI tradicionales que se han rediseñado para ofrecer funcionalidades ESB, pero se siguen rigiendo por el modelo de intermediario.  

Otros, como Mule como ESB de MuleSoft, se han creado desde cero utilizando estándares abiertos de integración y mensajería para implementar el modelo ESB.  

A pesar de sus diferencias, la mayoría de ESB incluyen todas las funciones centrales, o "servicios", que se indican a continuación:

• Transparencia de ubicación: una forma de configurar de forma centralizada los puntos de conexión para los mensajes, de forma que la aplicación del usuario no necesite información sobre el productor del mensaje para recibir comunicaciones.
• Transformación: la capacidad del ESB de convertir mensajes a un formato utilizable por la aplicación del usuario.
• Conversión de protocolo: como ocurre con el requisito de transformación, el ESB debe ser capaz de aceptar los mensajes que se envían mediante todos los protocolos importantes, así como de convertirlos al formato requerido por el usuario final. 
• Enrutamiento: la capacidad de determinar el usuario o usuarios finales en función de reglas preconfiguradas y solicitudes creadas dinámicamente.
• Mejora: la capacidad de recuperar los datos que faltan en los mensajes entrantes en función de los ya existentes y adjuntarlos al mensaje antes de su entrega al destino final.
• Supervisión/administración: el objetivo de un ESB es hacer de la integración una tarea sencilla. Por definición, un ESB debe proporcionar un método sencillo para supervisar el rendimiento del sistema, el flujo de mensajes a través de la arquitectura ESB y una forma sencilla de gestionar el sistema a fin de ofrecer el valor propuesto a una infraestructura.
• Seguridad: la seguridad del ESB abarca dos componentes principales. El primero, garantizar que el propio ESB gestiona los mensajes de forma totalmente segura; y el segundo, mediar entre los sistemas de garantía de seguridad utilizados por cada uno de los sistemas que se integrarán.

Las ventajas del ESB

Estas son las ventajas que ofrece el enfoque de ESB a la integración de aplicaciones:

• Ligero: un ESB se compone de diferentes servicios que interactúan entre sí, en lugar de un solo centro de recursos para todos los servicios, por lo que puede ser tan ligero o pesado como necesite la organización. Es por ello que constituye la solución de integración más eficiente disponible.
• Fácil de ampliar: si una organización sabe que necesitará conectar aplicaciones o sistemas a su infraestructura en el futuro, un ESB le permite integrar sus sistemas inmediatamente y despreocuparse de si el nuevo sistema funcionará o no en la infraestructura existente. Cuando la nueva aplicación esté lista, solo hay que conectarla al bus para que funcione con el resto de la infraestructura.
• Escalable y distribuible: a diferencia de las arquitecturas de intermediario, la funcionalidad del ESB se puede propagar por una red distribuida geográficamente en función de las necesidades. Asimismo, dado que los componentes individuales se utilizan para ofrecer cada función, usar un ESB hace que resulte mucho más sencillo y rentable garantizar una alta disponibilidad y escalabilidad para las partes esenciales de una arquitectura. 
• Preparados para SOA: los ESB se diseñan teniendo en cuenta la arquitectura orientada a los servicios. Gracias a ello, cualquier organización que busque migrar a una arquitectura SOA puede hacerlo de manera progresiva, sin dejar de utilizar sus sistemas existentes y conectando servicios reutilizables a medida que se implementan.
• Adopción progresiva: a primera vista, el número de funciones que ofrecen los mejores ESB puede parecer intimidante. Por ello, es más recomendable pensar en los ESB como "plataformas" de integración que permiten utilizar solo los componentes necesarios para satisfacer las necesidades actuales de integración. La mayor parte de los componentes modulares ofrece una flexibilidad sin igual que permite una adopción progresiva de la arquitectura de integración a medida que los recursos pasan a estar disponibles, a la par que garantiza que futuras necesidades imprevistas no interferirán en el retorno de la inversión.

Cuándo usar un ESB: tomar decisiones fundadas en materia de EAI

Todas las soluciones de integración tienen sus puntos fuertes y débiles, que dependen a menudo del entorno en el que se despliegan. Por este motivo, tomar decisiones fundadas sobre la estrategia de EAI es fundamental para el éxito de la iniciativa de integración.  

Para que los esfuerzos de EAI y SOA tengan fruto, no solo hay que contar con la mejor tecnología disponible, también es necesario disponer de datos fiables sobre el caso de uso previsto, el rendimiento bajo carga y la madurez del producto, así como una profunda comprensión de los retos de integración presentes y futuros que debe superar la organización.

Antes de tomar una decisión en materia de EAI, es importante ser capaces de responder a preguntas como las siguientes:

• ¿Cuántas aplicaciones hace falta integrar?  
• ¿Será necesario añadir más aplicaciones en el futuro?
• ¿Cuántos protocolos de comunicación habrá que utilizar?
• ¿Las necesidades de integración incluyen aspectos de enrutamiento, bifurcación o agregación?
• ¿Cómo es de importante la escalabilidad para una organización?
• ¿Requiere la situación de integración funciones de mensajería asíncrona, modelos de mensajería de publicación/consumo u otras situaciones complejas de mensajería entre aplicaciones?

Ross Mason, fundador de MuleSoft y arquitecto original de Mule como ESB, ha escrito un artículo titulado "ESB o no ESB", que sirve de introducción para las organizaciones que están estudiando adoptar un enfoque de integración de ESB. El artículo incluye una versión ampliada de la lista anterior de preguntas para ayudar a decidir si un ESB es buena opción para las necesidades de integración de una empresa.