En nuestros proyectos de integración, un patrón de diseño habitual y que es muy fructífero es la cola de mensajes.
En nuestros proyectos de integración, un patrón de diseño habitual y que es muy fructífero es la cola de mensajes. Esta cola nos permite lograr conexión entre distintos softwares, sin que cada uno de ellos conozca demasiado del otro.
La cola de mensajes funciona como cualquier cola en la vida real. Pensemos en el supermercado. Vamos a comprar. Recorremos las góndolas, cada cliente por separado. Cuando terminamos de comprar, nos ponemos en la fila de una caja determinada y esperamos a que la caja vaya procesando, en orden de llegada, cada uno de los clientes que están en la fila. Esto significa que tenemos distintos actores en el proceso:
– El subsistema de autoservicio, donde cada cliente obtiene las cosas que quiere comprar, las pone en un carrito y en algún momento determina que quiere terminar la compra
– El subsistema de cobranza, donde cada cliente paga por las cosas que compró
La comunicación entre ambos subsistemas se da a través de la cola. El primer subsistema “pone” en la fila a un cliente, para que lo “consuma” el otro subsiste.
Cuando hablamos de integrar softwares, el concepto es exactamente eso. Buscamos que un sistema ponga en una cola mensajes, y que esos mensajes sean consumidos por el otro sistema. Entonces hablamos de una solución que generalmente involucra desarrollar distintos elementos. En primer lugar, procesos que pongan cosas en cola. Estos procesos son los que deben saber qué sucede en el sistema de origen, y validar que estos eventos se repliquen a la cola. En segundo lugar, desarrollar procesos que consuman una cola e interactúen con el segundo sistema. Estos procesos son los responsables de validar que el mensaje es correcto y se puede procesar, o que no es correcto. En este caso, deben poder informar las causas del error, para que quien administra la cola tenga la información y pueda tomar decisiones. Un caso habitual de error es el de mensaje duplicado. Este caso es clave y debe ser tratado en toda integración. Por otro lado, también hay que consensuar un diseño de mensaje, que involucre una cantidad de información estructurada. Nuestra recomendación es que el mensaje sea siempre lo más abarcativo posible, y no sesgarlo a las necesidades puntuales de cada caso. Esto nos permitirá que ante nuevas necesidades del sistema que consume la cola, no necesariamente tengamos que pensar en modificar el sistema que la alimenta.
Adicionalmente, la cola nos permite pensar en conceptos como monitorear el estado de cada mensaje o de un conjunto de mensajes y reprocesar un mensaje ante un error de ejecución.
Este diseño nos ahorra el tener que hacer que un sistema hable directamente con el el otro y nos ahorramos:
– Que un sistema caído nos haga caer a otro sistema, porque este segundo habla con el primero
– Que si modificamos un sistema (por ejemplo, agregamos un nuevo dato) tengamos que modificar también el otro sistema
A esto le decimos, en sistemas, disminuir el acoplamiento. Una solución de bajo acoplamiento va a tener menores costos de mantenimento y evolución a futuro.
Para implementar un sistema de colas, se puede:
1. Desarrollar un sistema propio de colas
2. Contratar un sistema de colas de un proveedor. Todos los grandes jugadores (Microsoft Azure, Google Cloud Platform, Amazon Web Services) tienen propuestas de servicios de cola. En general con pago por uso
Diseñar los sistemas que interactúan con la cola de mensajes es tema para otro capítulo.
