En arquitectura de software , publicación-suscripción es un patrón de mensajería en el que los editores clasifican los mensajes en clases que reciben los suscriptores. Esto contrasta con el modelo de patrón de mensajería típico en el que los editores envían mensajes directamente a los suscriptores.
De manera similar, los suscriptores expresan interés en una o más clases y solo reciben mensajes que son de su interés, sin saber qué editores, si los hay, los hay.
Publicar-suscribir es un hermano del paradigma de cola de mensajes y normalmente es una parte de un sistema de middleware orientado a mensajes más grande . La mayoría de los sistemas de mensajería admiten tanto el modelo pub/sub como el de cola de mensajes en su API ; por ejemplo, Servicio de mensajes Java (JMS).
Este patrón proporciona una mayor escalabilidad de la red y una topología de red más dinámica , lo que resulta en una menor flexibilidad para modificar el editor y la estructura de los datos publicados.
En el modelo de publicación-suscripción, los suscriptores normalmente reciben sólo un subconjunto del total de mensajes publicados. El proceso de selección de mensajes para su recepción y procesamiento se denomina filtrado . Hay dos formas comunes de filtrado: basado en temas y basado en contenido.
En un sistema basado en temas , los mensajes se publican en "temas" o canales lógicos con nombre. Los suscriptores de un sistema basado en temas recibirán todos los mensajes publicados en los temas a los que se suscriban. El editor es responsable de definir los temas a los que pueden suscribirse los suscriptores.
En un sistema basado en contenido , los mensajes sólo se entregan a un suscriptor si los atributos o el contenido de esos mensajes coinciden con las restricciones definidas por el suscriptor. El suscriptor es responsable de clasificar los mensajes.
Algunos sistemas admiten un híbrido de los dos; los editores publican mensajes sobre un tema mientras que los suscriptores registran suscripciones basadas en contenido a uno o más temas.
En muchos sistemas de publicación-suscripción, los publicadores publican mensajes en un corredor de mensajes intermediario o bus de eventos , y los suscriptores registran suscripciones con ese corredor, permitiendo que el corredor realice el filtrado. El intermediario normalmente realiza una función de almacenamiento y reenvío para enrutar mensajes de los editores a los suscriptores. Además, el corredor puede priorizar los mensajes en una cola antes de enrutarlos.
Los suscriptores pueden registrarse para recibir mensajes específicos en el momento de la compilación, el tiempo de inicialización o el tiempo de ejecución. En los sistemas GUI, los suscriptores pueden codificarse para manejar comandos de usuario (por ejemplo, hacer clic en un botón), lo que corresponde al registro del tiempo de construcción. Algunos marcos y productos de software utilizan archivos de configuración XML para registrar suscriptores. Estos archivos de configuración se leen en el momento de la inicialización. La alternativa más sofisticada es cuando se pueden agregar o eliminar suscriptores en tiempo de ejecución. Este último enfoque se utiliza, por ejemplo, en activadores de bases de datos , listas de correo y RSS .
El middleware del Servicio de distribución de datos (DDS) no utiliza un intermediario en el medio. En cambio, cada editor y suscriptor en el sistema de publicación/suscripción comparte metadatos entre sí a través de multidifusión IP . El editor y los suscriptores almacenan en caché esta información localmente y enrutan los mensajes basándose en el descubrimiento mutuo en el conocimiento compartido. De hecho, las arquitecturas sin intermediarios requieren un sistema de publicación/suscripción para construir una red superpuesta que permita un enrutamiento descentralizado eficiente de los editores a los suscriptores. Jon Kleinberg demostró que el enrutamiento descentralizado eficiente requiere topologías navegables de mundo pequeño . Estas topologías de mundo pequeño generalmente se implementan mediante sistemas de publicación/suscripción descentralizados o federados. [1] Los sistemas de publicación/suscripción que tienen en cuenta la localidad [2] construyen topologías de mundo pequeño que enrutan las suscripciones a través de enlaces de corta distancia y de bajo costo, reduciendo así los tiempos de entrega de las suscripciones.
Uno de los primeros sistemas pub/sub descritos públicamente fue el subsistema de "noticias" del Isis Toolkit, descrito en la conferencia del Simposio sobre principios de sistemas operativos (SOSP '87) de la Association for Computing Machinery (ACM) de 1987, en un artículo "Exploiting Virtual Sincronía en sistemas distribuidos 123-138. [3]
Los editores están estrechamente vinculados a los suscriptores y ni siquiera necesitan saber de su existencia. Al centrarse en el tema, los editores y suscriptores pueden ignorar la topología del sistema. Cada uno puede continuar funcionando normalmente independientemente del otro. En el paradigma tradicional cliente-servidor estrechamente acoplado , el cliente no puede publicar mensajes en el servidor mientras el proceso del servidor no se está ejecutando, ni el servidor puede recibir mensajes a menos que el cliente se esté ejecutando. Muchos sistemas de publicación/suscripción no sólo desacoplan las ubicaciones de los editores y suscriptores, sino que también los desacoplan temporalmente. Una estrategia común utilizada por los analistas de middleware con tales sistemas de publicación/subscripción es eliminar un editor para permitir que el suscriptor trabaje con el trabajo pendiente (una forma de limitación del ancho de banda ).
Pub/sub brinda la oportunidad de una mejor escalabilidad que el cliente-servidor tradicional, a través de operación paralela, almacenamiento en caché de mensajes, enrutamiento basado en árbol o en red, etc. Sin embargo, en ciertos tipos de entornos empresariales de alto volumen y estrechamente acoplados, como sistemas escalar hasta convertirse en centros de datos con miles de servidores que comparten la infraestructura pub/sub, los sistemas de los proveedores actuales a menudo pierden este beneficio; La escalabilidad de productos pub/sub bajo alta carga en estos contextos es un desafío de investigación.
Fuera del entorno empresarial, por otro lado, el paradigma pub/sub ha demostrado su escalabilidad a volúmenes mucho más allá de los de un único centro de datos, proporcionando mensajería distribuida en Internet a través de protocolos de sindicación web como RSS y Atom . Estos protocolos de distribución aceptan una mayor latencia y falta de garantías de entrega a cambio de la capacidad de incluso un servidor web de gama baja de distribuir mensajes a (potencialmente) millones de nodos de suscriptores separados.
Los problemas más graves con los sistemas pub/sub son un efecto secundario de su principal ventaja: la desvinculación entre el editor y el suscriptor.
Un sistema pub/sub debe diseñarse cuidadosamente para poder proporcionar propiedades de sistema más sólidas que una aplicación particular podría requerir, como una entrega segura.
El patrón pub/sub se adapta bien a redes pequeñas con una pequeña cantidad de nodos de editor y suscriptor y un volumen de mensajes bajo. Sin embargo, a medida que crece el número de nodos y mensajes, aumenta la probabilidad de inestabilidades, lo que limita la escalabilidad máxima de una red pub/sub. Ejemplos de inestabilidades de rendimiento a gran escala incluyen:
Para los sistemas pub/sub que utilizan intermediarios (servidores), el argumento para que un intermediario envíe mensajes a un suscriptor está dentro de banda y puede estar sujeto a problemas de seguridad. Se podría engañar a los corredores para que envíen notificaciones al cliente equivocado, amplificando la denegación de solicitudes de servicio contra el cliente. Los propios corredores podrían verse sobrecargados al asignar recursos para rastrear las suscripciones creadas.
Incluso con sistemas que no dependen de intermediarios, un suscriptor podría recibir datos que no está autorizado a recibir. Un editor no autorizado puede introducir mensajes incorrectos o dañinos en el sistema de publicación/subscripción. Esto es especialmente cierto con los sistemas que transmiten o multidifunden sus mensajes. El cifrado (por ejemplo, Seguridad de la capa de transporte (SSL/TLS)) puede impedir el acceso no autorizado, pero no puede evitar que los editores autorizados introduzcan mensajes dañinos. Las arquitecturas distintas a pub/sub, como los sistemas cliente/servidor, también son vulnerables a remitentes de mensajes autorizados que se comportan de manera maliciosa.