Publicación - Suscripción

    Las principales entidades en un sistema publicación-suscripción son los editores y suscriptores de contenido [1]. Un publicador (publisher) detecta un evento y luego lo publica en forma de notificación. Una notificación encapsula información relacionada con el evento observado. La notificación denota que ha ocurrido un evento observado. Un evento representa cualquier transición de estado discreta que ha ocurrido y se señala desde una entidad a un número de otras entidades.

    Un suscriptor, por ejemplo, podría expresar interés en todos los eventos relacionados con este libro de texto, como la disponibilidad de una nueva edición o actualizaciones del sitio web relacionado. La tarea del sistema de publicación y suscripción es hacer coincidir las suscripciones con los eventos publicados y garantizar la entrega correcta de las notificaciones de eventos. Un evento dado se entregará potencialmente a muchos suscriptores y, por lo tanto, en publicación y suscripción se usan paradigmas de comunicaciones de uno a muchos.

Aplicaciones de los sistemas de publicación-suscripción

Los sistemas de publicación-suscripción se utilizan en una variedad de dominios de aplicación, en particular los relacionados con la difusión de eventos a gran escala. Ejemplos  incluyen [1]:

• GUI, en las que los sistemas pub/sub se aplica como el pegamento que conecta los diversos componentes entre sí. Un ejemplo es el patrón de diseño MVC (Modelo Vista Controlador) muy utilizado en GUIs y su componente el patrón de observador.  

• Push de información, en el que se publica el contenido al usuario. Este es un requisito para aplicaciones que dependen de datos en tiempo real o casi en tiempo real. 

• Filtrado de información y entrega dirigida utilizada por los servicios de alerta y presencia (Google Alerts, etc.), tiendas de aplicaciones, servicios de corretaje de RSS, etc. Los ejemplos incluyen XMPP Pub/sub, Pubsubhubbub, Facebook  Messenger and Chat y Twitter.  

• Plano de señalización, en el que pub/sub asegura que los eventos asíncronos se entregan en en tiempo real o casi en tiempo real desde la publicación de componentes hasta la suscripción de componentes. Las aplicaciones de ejemplo incluyen sistemas industriales y tácticos. DDS (Data Distribution Systems) es el estándar clave para estos sistemas.  

• La arquitectura orientada a servicios (SOA) y las aplicaciones comerciales se basan en publicación/suscripción en el bus de servicios empresariales (ESB). El ESB normalmente se implementa con un broker de mensaje XML.  

• Procesamiento de Eventos Complejos (CEP) para análisis de datos. CEP se utiliza ampliamente en varios aplicaciones comerciales, por ejemplo, comercio algorítmico y detección de fallas. 

• Computación en la nube, en la que pub/sub y colas de mensajes se utilizan para conectar los componentes de la nube. 

• Internet de las cosas, en el que pub/sub conecta los sensores y actuadores entre sí con recursos de Internet.  

• Juegos multijugador en línea, en los que pub/sub se usa para sincronizar el estado del juego en jugadores y servidores

Modelo de Programación

    El modelo de programación en los sistemas de publicación-suscripción se basa en un pequeño conjunto de operaciones, ver Figura 1. Los editores difunden un evento e a  través de una operación de publicacion(e) y los suscriptores expresan su interés en un conjunto de eventos a través de suscripciones. En particular, logran esto a través de una operación de suscripcion( f ) donde f se refiere a un filtro, es decir, un patrón definido sobre el conjunto de todos los eventos posibles.

Figura 1: Paradigma Publicación Suscripción

    La expresividad de los filtros está determinada por modelo de la suscripción. Los suscriptores pueden revocar este interés mediante la correspondiente operación de cancelacion−suscripcion( f ). Cuando los eventos llegan a un suscriptor, los eventos se entregan usando una operación de notificacion(e).

    Algunos sistemas complementan el conjunto de operaciones anuncios. Con los anuncios, 

los editores tienen la opción de declarar la naturaleza de los eventos futuros a través de una operación de anuncios( f ). 

Modelo de Subscripción 

    La expresividad de los sistemas de publicación-suscripción está determinada por el modelo de suscripción, que cuentan con una serie de esquemas o filtros [1] [2]:

• Basado en canales : en este enfoque, los editores publican eventos en canales con nombre y los suscriptores luego se suscriben a uno de estos canales para recibir todos los eventos enviados a ese canal. Este esquema es el único que se define en un canal físico. 

• Basado en temas : se asume que cada notificación se expresa en términos de varios campos, con un campo que denota el tema. Las suscripciones se definen en función del tema de interés. Este enfoque es equivalente a los enfoques basados en canales con la diferencia de que los temas se definen implícitamente, pero se declaran como parte de un campo en el enfoque basados en temas. 

• Basado en contenidos : son una generalización de enfoques basados en temas que permiten la expresión de suscripciones en una variedad de campos en solo una notificación del evento. Más específicamente, un filtro basado en contenido es una consulta definida en términos de composiciones de restricciones sobre los valores de los atributos del evento. Por ejemplo, un suscriptor podría expresar interés en eventos relacionados con el tema de los sistemas de publicación-suscripción, donde el sistema en cuestión es el Servicio de eventos CORBA y el autor es Tim Kindberg o Gordon Blair.  

• Basado en tipo : las suscripciones se definen en términos de tipos de eventos y la coincidencia se define en términos de tipos o subtipos del filtro dado. Este enfoque puede expresar una variedad de filtros, desde un filtrado basado en nombres de tipo generales hasta consultas más detalladas que definen atributos y métodos de un objeto dado. Estos filtros detallados son similares en expresividad a los enfoques basados en contenido.

Bibliografia:

[1] Sasu Tarkoma. Publish/Subscribe Systems: Design and Principles. Edited by Joe

Sventek David Hutchison Serge Fdida. 2012. 

[2]  George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA:

Addison-Wesley Publishing Company, 2011. ISBN: 0132143011 

[3] Roberto Vitillo. Understanding Distributed Systems. 2021

¿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.