¿Cómo implementar un sistema Pub Sub?

Paradigma Pub-Sub

El paradigma de publicación-suscripción (Pub-Sub) [1]  es simple y fácil de entender:

• No requiere que el publicador y el suscriptor estén activos al mismo tiempo. Por lo tanto, admite lo que a menudo se denomina interacción asíncrona.
•  Es útil cuando los participantes tienen baja o esporádica conectividad. 
• Los componentes de la aplicación no se acoplan directamente, sino que se acoplan a través del bus de mensajes ( red de corredores) , resultando más fácil reconfigurar el sistema. Se puede cambiar el número, la identidad o la ubicación de los suscriptores sin cambiar los publicadores y viceversa. 

Un bus de mensajes [3] es una abstracción que permite que los procesos intercambien mensajes indirectamente, a través de un componente intermedio, llamado bus. En este modelo, los publicadores generan mensajes para el bus, mientras que los suscriptores consumen mensajes del bus. La mayoría de los buses de mensajes permiten que se produzca un mensaje en un momento, pero que solo se consuma más adelante. El bus de mensajes mantiene el mensaje en un almacén no volátil hasta que se consume.

¿Cómo implementar un sistema Pub Sub?

Para ejemplificar cómo se puede implementar el modelo pub-sub, se usa la arquitectura más simple, donde la abstracción del bus de mensaje se materializa en un servidor central, como se ilustra en la Figura  1.

Arquitectura Pub Sub. Adaptado de [3]

La actividad de publicación es muy sencilla:

• El publicador  envía un mensaje al servidor que lo almacena en la memoria no volátil. 

La suscripción de mensajes se puede implementar utilizando dos alternativas diferentes: 

• push: los suscriptores  registran en el servidor el interés en recibir una determinada clase de mensajes, y el servidor es responsable de difundir estos mensajes a los suscriptores interesados. Se puede usar  comunicación por multidifusión  para difundir los  mensajes de manera eficiente, cuando muchos suscriptores están interesados ​​en los mismos mensajes.
• pull:  depende del suscriptor ponerse en contacto con el servidor periódicamente para obtener los mensajes. Este segundo esquema puede parecer menos eficiente, pero tiene sus ventajas en sistemas donde los suscriptores no están permanentemente conectados y quieren recolectar los mensajes de forma diferida (no sincronizada).

 El problema con la arquitectura ejemplificada en la Figura 1, con  el servidor centralizado, es que el rendimiento puede verse afectado debido a que esta disposición representa un  cuello de botella  como un único punto de falla. Mediante el uso de la replicación, se pueden mejorar tanto el rendimiento como la confiabilidad de la aplicación.

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. Rodrigues, Luís and Veríssimo, Paulo. Advances in Distributed Computing and Middleware.