Integraciones con arquitecturas basadas en un bus de eventos

¿Cómo funcionan las integraciones con arquitecturas basadas en un bus de eventos?

La arquitectura basada en un bus de eventos o “EDA”, por sus siglas en ingles “Event-driven architecture”, es útil para sistemas activos, en los que el emisor y el destinatario pueden producir y consumir mensajes directamente utilizando un buzón, sin necesidad de que nadie más interactúe en la transferencia.

Este tipo de arquitecturas están tomando un gran protagonismo hasta el punto que existen artículos que consideran incluso que los motores ESB están obsoletos y por este motivo, llevamos un tiempo considerable evaluando Apache Kafka y la plataforma Confluent (versión empresarial de Apache Kafka).

En el siguiente vídeo podrás entender de manera gráfica cómo es el funcionamiento de esta arquitectura.

De forma resumida, se trata de que un sistema origen tiene que enviar un mensaje al sistema destino. Para realizar este traspaso de información, ambos sistemas acuerdan compartir el dato en un buzón accesible a ambos, en el que el emisor deposita el dato en el buzón y el destinatario lo recoge del mismo.

El sistema origen contiene la lógica para escribir el mensaje pactado en el buzón, mientras que el sistema destino contiene la lógica para leer el mensaje pactado.

Podemos decir que cada una de las partes se encarga de realizar la mitad del transporte; la lógica del que produce el dato en el buzón está en el emisor, mientras que la lógica del que lo consume está en los receptores.

Ejemplo de Integración con EDA: El vendedor deposita el pedido en un punto de recogida y el comprador lo recoge de ahí.

Este caso es una situación muy habitual en la vida real: Supongamos que un vendedor prepara una pizza y se encarga personalmente de depositarla en un punto de encuentro mientras que el comprador acude a este lugar y recoge el pedido.

El vendedor se encarga de confeccionar y depositar la pizza en un punto de encuentro mientras que el comprador acude a este lugar a recogerla.

Traducido en el ámbito del software, diríamos que el sistema origen (vendedor) escribe un mensaje (pizza) en un buzón y el sistema destino (comprador) lee el mensaje (pizza) del buzón que estaba escuchando.

A la hora de integrar, esta idea conduce a las siguientes conclusiones:

• El sistema origen tiene código para generar el mensaje y escribirlo en el buzón.
• El sistema destino tiene código para leer el mensaje del buzón y consumirlo.

La problemática de la integración se aborda de forma diferente al caso 1 (en el que existía un agente integrador que se encargaba de trasladar / transformar el dato) ya que ahora el sistema origen se encarga también de trasladar ‘parcialmente’ el mensaje producido (escribirlo en un buzón) y el sistema destino también se encarga de ‘trasladarse’ para consumir el mensaje (leerlo del buzón).

Proyectos

Uno de los proyectos más relevantes es el proyecto Apache Kafka y la plataforma Confluent (versión empresarial), que incluye además de soporte directo del fabricante una serie de proyectos complementarios a la hora de realizar integraciones. Como punto a destacar, es importante tener en cuenta que nos encontramos con un sistema de mensajería asíncrono escalable en entornos de alta disponibilidad.

Conclusiones

Estos proyectos aportan librerías SDK en diferentes lenguajes de programación para que los sistemas origen y destino puedan escribir / leer el mensaje en los buzones del sistema de mensajería asíncrono.

Obviamente, prescindir del repartidor es especialmente interesante cuando el vendedor y el comprador puede asumir la entrega y recepción del pedido por ellos mismos. Es decir, este planteamiento es especialmente útil en integraciones con sistemas que sí pueden asumir la escritura y lectura del mensaje en un sistema de mensajería asíncrono.

¿Cuando utilizar una arquitectura EDA?

• Los sistemas origen y destino no son pasivos, es decir que disponen de herramientas / librerías para trabajar contra sistemas de mensajería asíncrona.
• Es más ágil pactar el mensaje a compartir en EDA que hacer una integración en ESB.
• El volumen de datos a consumir / producir alcanza umbrales muy elevados.

Te puede interesar:

Servicios Open Source  |  Integración de sistemas