En la arquitectura de software , publicar-suscribir 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 sólo reciben los mensajes que les interesan, sin saber qué editores existen, si los hay.
El modelo de publicación y suscripción es un modelo hermano del paradigma de cola de mensajes y, por lo general, forma 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 de publicación y suscripción como el de cola de mensajes en su API ; por ejemplo, Java Message Service (JMS).
Este patrón proporciona una mayor escalabilidad de la red y una topología de red más dinámica , con la consiguiente reducción de la flexibilidad para modificar el publicador y la estructura de los datos publicados. Según Gregor Hohpe, en comparación con los patrones de mensajería sincrónica (como RPC ) y los patrones de mensajería punto a punto , la publicación-suscripción proporciona el mayor nivel de desacoplamiento entre los componentes arquitectónicos, sin embargo, también puede acoplarlos de otras maneras (como el formato y el acoplamiento semántico) por lo que se vuelven desordenados con el tiempo. [1]
En el modelo de publicación-suscripción, los suscriptores suelen recibir solo un subconjunto del total de mensajes publicados. El proceso de selección de mensajes para su recepción y procesamiento se denomina filtrado . Existen 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 los suscriptores pueden suscribirse.
En un sistema basado en contenido , los mensajes solo 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 ambos: los editores publican mensajes en un tema mientras que los suscriptores registran suscripciones basadas en contenido a uno o más temas.
En muchos sistemas de publicación y suscripción, los editores publican mensajes en un agente de mensajes intermediario o bus de eventos , y los suscriptores registran suscripciones con ese agente, lo que permite que el agente realice el filtrado. El agente normalmente realiza una función de almacenamiento y reenvío para enrutar los mensajes de los editores a los suscriptores. Además, el agente puede priorizar los mensajes en una cola antes de enrutarlos. [ cita requerida ]
Los suscriptores pueden registrarse para recibir mensajes específicos en el momento de la compilación, la inicialización o la ejecución. En los sistemas GUI, los suscriptores pueden codificarse para que gestionen comandos de usuario (por ejemplo, hacer clic en un botón), lo que corresponde al registro en el momento de la compilació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 los suscriptores se pueden agregar o eliminar en el momento de la ejecución. Este último enfoque se utiliza, por ejemplo, en activadores de bases de datos , listas de correo y RSS . [ cita requerida ]
El middleware del Servicio de Distribución de Datos (DDS) no utiliza un intermediario en el medio. En su lugar, cada publicador y suscriptor en el sistema de publicación/suscripción comparte metadatos entre sí a través de multidifusión IP . El publicador y los suscriptores almacenan en caché esta información localmente y enrutan los mensajes en función del descubrimiento mutuo en el conocimiento compartido. En efecto, las arquitecturas sin intermediarios requieren que el sistema de publicación/suscripción construya una red superpuesta que permita un enrutamiento descentralizado eficiente de los publicadores a los suscriptores. Jon Kleinberg demostró que el enrutamiento descentralizado eficiente requiere topologías de mundo pequeño navegables . Dichas topologías de mundo pequeño generalmente se implementan mediante sistemas de publicación/suscripción descentralizados o federados. [2] Los sistemas de publicación/suscripción con reconocimiento de localidad [3] construyen topologías de mundo pequeño que enrutan las suscripciones a través de enlaces de corta distancia y bajo costo, lo que reduce los tiempos de entrega de suscripciones.
Uno de los primeros sistemas de publicación y suscripción descritos públicamente fue el subsistema de "noticias" del kit de herramientas Isis, descrito en la conferencia del Simposio sobre principios de sistemas operativos (SOSP '87) de la Asociación para Maquinaria Computacional (ACM) de 1987, en un artículo "Explotación de la sincronía virtual en sistemas distribuidos . 123–138". [4]
Los publicadores están débilmente acoplados a los suscriptores, y ni siquiera necesitan saber de su existencia. Con el tema como foco, los publicadores y suscriptores pueden permanecer ignorantes de la topología del sistema. Cada uno puede continuar operando normalmente independientemente del otro. En el paradigma tradicional de cliente-servidor estrechamente acoplado , el cliente no puede enviar mensajes al 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 desacoplan no solo las ubicaciones de los publicadores y suscriptores, sino que también los desacoplan temporalmente. Una estrategia común utilizada por los analistas de middleware con dichos sistemas de publicación/suscripción es derribar un publicador para permitir que el suscriptor trabaje a través del atraso (una forma de limitación del ancho de banda ).
Pub/sub ofrece la oportunidad de lograr una mejor escalabilidad que el cliente-servidor tradicional, a través de operaciones paralelas, almacenamiento en caché de mensajes, enrutamiento basado en árboles o en red, etc. Sin embargo, en ciertos tipos de entornos empresariales de gran volumen y muy acoplados, a medida que los sistemas se amplían para convertirse en centros de datos con miles de servidores que comparten la infraestructura de pub/sub, los sistemas de los proveedores actuales a menudo pierden este beneficio; la escalabilidad de los productos de pub/sub bajo carga elevada en estos contextos es un desafío de investigación.
Por otra parte, fuera del entorno empresarial, el paradigma de publicación y suscripción ha demostrado su escalabilidad a volúmenes que van mucho más allá de los de un único centro de datos, proporcionando mensajería distribuida en toda Internet a través de protocolos de sindicación web como RSS y Atom . Estos protocolos de sindicación aceptan una mayor latencia y la falta de garantías de entrega a cambio de la capacidad de que incluso un servidor web de gama baja sindique mensajes a (potencialmente) millones de nodos suscriptores separados.
Los problemas más graves de los sistemas de publicación/suscripción son un efecto secundario de su principal ventaja: la disociación entre editor y suscriptor.
Un sistema de publicación/suscripción 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 asegurada.
El patrón de publicación/suscripción se adapta bien a redes pequeñas con una pequeña cantidad de nodos de publicación y suscripción y un volumen de mensajes bajo. Sin embargo, a medida que aumenta la cantidad de nodos y mensajes, aumenta la probabilidad de inestabilidades, lo que limita la escalabilidad máxima de una red de publicación/suscripción. Algunos ejemplos de inestabilidades de rendimiento a gran escala son:
En el caso de los sistemas de publicación y suscripción que utilizan intermediarios (servidores), el argumento para que un intermediario envíe mensajes a un suscriptor es in-band y puede estar sujeto a problemas de seguridad. Los intermediarios pueden ser engañados y enviar notificaciones al cliente equivocado, lo que amplifica las solicitudes de denegación de servicio contra el cliente. Los intermediarios mismos pueden verse sobrecargados, ya que asignan recursos para realizar un seguimiento de las suscripciones creadas.
Incluso en el caso de sistemas que no dependen de intermediarios, un suscriptor podría recibir datos que no está autorizado a recibir. Un editor no autorizado podría introducir mensajes incorrectos o dañinos en el sistema de publicación/suscripción. Esto es especialmente cierto en el caso de sistemas que difunden o multidifunden sus mensajes. El cifrado (por ejemplo, la seguridad de la capa de transporte (SSL/TLS)) puede impedir el acceso no autorizado, pero no puede impedir que los editores autorizados introduzcan mensajes dañinos. Las arquitecturas distintas de la publicación/suscripción, como los sistemas cliente/servidor, también son vulnerables a los remitentes de mensajes autorizados que se comportan de forma maliciosa.