Para obtener información sobre la función Macintosh introducida con System 7, consulte Publicar y suscribir (Mac OS). Para obtener información sobre la práctica de pagar antes de que se complete un trabajo, consulte Modelo de negocio de suscripción. "PubSub" redirige aquí. Para el sitio web de búsqueda inexistente, consulte PubSub (sitio web). "Pub sub" redirige aquí. Para el sándwich que se vende en Publix, consulte Publix § Stores.

En 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. Del mismo modo, 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, hay. Publish–subscribe es un elemento del mismo nivel que el paradigma de cola de mensajes y, por lo general, forma parte de un sistema de middleware orientado a mensajes más grandes. La mayoría de los sistemas de mensajería admiten los modelos de publicación/suscripción y cola de mensajes en su API; por ejemplo, Java Message Service (JMS).

Este patrón proporciona una mayor escalabilidad de red y una topología de red más dinámica, con la consiguiente menor 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, publish-subscribe proporciona el nivel más alto de desacoplamiento entre los componentes de la arquitectura, sin embargo, también puede acoplarlos de otras maneras (como el acoplamiento de formato y semántico) para que se vuelvan 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 filtering. 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 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 los dos; 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-suscripción, los publicadores publican mensajes en un agente de message broker or event bus, y los suscriptores registran las suscripciones con ese agente, lo que permite que el agente realice el filtrado. Normalmente, el intermediario realiza una función de almacenamiento y reenvío para enrutar los mensajes de los editores a los suscriptores. Además, el intermediario puede dar prioridad a los mensajes de una queue antes de enrutarlos.

Los suscriptores pueden registrarse para recibir mensajes específicos en tiempo de recopilación, tiempo de inicialización o tiempo de ejecución. En los sistemas GUI, los suscriptores se pueden codificar para manejar comandos de usuario (por ejemplo, hacer clic en un botón), lo que corresponde al registro de tiempo de compilación. Algunos frameworks 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 tiempo de ejecución. Este último enfoque se utiliza, por ejemplo, en desencadenadores 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 su lugar, cada editor y suscriptor del sistema de publicación/suscripción comparten metadatos entre sí a través de la multidifusión de IP. El editor y los suscriptores almacenan en caché esta información localmente y enrutan los mensajes en función de la detección de cada uno en el conocimiento compartido. En efecto, 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 suelen implementarse mediante sistemas de publicación/suscripción descentralizados o federados. ^[2]​^[3]​Los sistemas de publicación/suscripción ^[4]​conscientes de la localidad 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 las suscripciones.

Uno de los primeros sistemas de publicación/suscripción descritos públicamente fue el subsistema de "noticias" del Isis Toolkit, descrito en la conferencia de 1987 de la Association for Computing Machinery (ACM) Symposium on Operating Systems Principles (SOSP '87), en un artículo "Exploiting Virtual Synchrony in Distributed Systems". 123–138."^[5]​

Los editores están débilmente acoplados a los suscriptores, y ni siquiera necesitan saber de su existencia. Dado que el tema es el centro, los editores y suscriptores pueden permanecer ignorantes de la topología del sistema. Cada uno puede seguir funcionando normalmente, independientemente del otro. En el client-server paradigm tradicional 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 editores y suscriptores, sino que también los desacoplan temporalmente. Una estrategia común utilizada por los analistas de middleware con este tipo de sistemas de publicación/suscripció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 ofrece la oportunidad de una mejor escalabilidad que el cliente-servidor tradicional, a través de la operación en paralelo, el almacenamiento en caché de mensajes, el enrutamiento basado en árboles o en redes, etc. Sin embargo, en ciertos tipos de entornos empresariales de gran volumen y estrechamente acoplados, a medida que los sistemas se amplían para convertirse en centros de datos con miles de servidores que comparten la infraestructura de publicación/suscripción, los sistemas de los proveedores actuales a menudo pierden este beneficio; La escalabilidad de los productos de Pub/Sub sometidos a una 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 solo 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 latencia más alta y la falta de garantías de entrega a cambio de la capacidad de incluso un servidor web de gama baja para sindicar mensajes a (potencialmente) millones de nodos de suscriptores separados.

• Los suscriptores redundantes en un sistema de publicación/suscripción pueden ayudar a garantizar la entrega de mensajes con una complejidad adicional mínima. Por ejemplo, una fábrica puede utilizar un sistema de publicación/suscripción en el que el equipo puede publicar problemas o fallos a un suscriptor que muestra y registra esos problemas. Si el registrador falla (se bloquea), los editores de problemas de equipo no necesariamente recibirán un aviso de la falla del registrador, y los mensajes de error no se mostrarán ni registrarán en ningún equipo del sistema de publicación/suscripción. En un sistema cliente/servidor, cuando falla un registrador de errores, el sistema recibirá una indicación de la falla del registrador de errores (servidor). Sin embargo, el sistema cliente/servidor tendrá que hacer frente a ese error teniendo servidores de registro redundantes en línea o generando dinámicamente servidores de registro de reserva.Esto añade complejidad a los diseños de cliente y servidor, así como a la arquitectura cliente/servidor en su conjunto. En un sistema de publicación/suscripción, se pueden agregar al sistema suscriptores de registro redundantes que son duplicados exactos del registrador existente para aumentar la confiabilidad del registro sin ningún otro equipo del sistema. La característica de registro de mensajes de error asegurado también se puede agregar de forma incremental, después de implementar la funcionalidad básica del registro de mensajes de problemas de equipos.

Los problemas más graves con los sistemas de publicación/suscripción son un efecto secundario de su principal ventaja: el desacoplamiento entre el editor y el suscriptor.

Un sistema de publicación/suscripción debe diseñarse cuidadosamente para poder proporcionar propiedades del sistema más sólidas que una aplicación en particular podría requerir, como la entrega garantizada.

• El agente en un sistema de publicación/suscripción puede estar diseñado para entregar mensajes durante un tiempo específico, pero luego dejar de intentar la entrega, independientemente de que haya recibido o no la confirmación de la recepción exitosa del mensaje por parte de todos los suscriptores. Un sistema de publicación/suscripción diseñado de esta manera no puede garantizar la entrega de mensajes a ninguna aplicación que pueda requerir dicha entrega garantizada. Se debe aplicar un acoplamiento más estrecho de los diseños de dicho par de editor y suscriptor fuera de la arquitectura de publicación/suscripción para lograr esa entrega garantizada (por ejemplo, exigiendo al suscriptor que publique mensajes de recibo).
• Un editor en un sistema de publicación/suscripción puede suponer que un suscriptor está escuchando, cuando en realidad no es así.

El patrón de publicación/suscripción se escala bien para redes pequeñas con un número reducido de nodos de editor y suscriptor 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. Entre los ejemplos de inestabilidades de rendimiento a gran escala se incluyen:

• Aumentos repentinos de carga: períodos en los que las solicitudes de los suscriptores saturan el rendimiento de la red, seguidos de períodos de bajo volumen de mensajes (ancho de banda de red infrautilizado)
• Ralentizaciones: a medida que más y más aplicaciones utilizan el sistema (incluso si se comunican en canales de publicación/suscripción separados), el flujo de volumen de mensajes a un suscriptor individual se ralentizará.

En el caso de los sistemas de publicación/suscripción que usan agentes (servidores), el argumento para que un agente envíe mensajes a un suscriptor está en banda y puede estar sujeto a problemas de seguridad. Los corredores pueden ser engañados para enviar notificaciones al cliente equivocado, amplificando las solicitudes de denegación de servicio contra el cliente. Los propios agentes podrían estar sobrecargados a medida que asignan recursos para realizar un seguimiento de las suscripciones creadas.

Incluso con sistemas que no dependen de intermediarios, un suscriptor podría recibir datos que no está autorizado a recibir. Es posible que un editor no autorizado pueda introducir mensajes incorrectos o dañinos en el sistema de publicación/suscripció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 evitar el acceso no autorizado, pero no puede evitar que los editores autorizados introduzcan mensajes dañinos. Las arquitecturas que no sean pub/sub, como los sistemas cliente/servidor, también son vulnerables a los remitentes de mensajes autorizados que se comportan de forma malintencionada.

• Atom, otro protocolo de sindicación web altamente escalable.
• Servicio de distribución de datos (DDS)
• Programación basada en eventos.
• Arquitectura de alto nivel.
• Protocolo de administración de grupos de Internet (IGMP)
• Agentes de mensajes.
• Cola de mensajes.
• Patrón de observación.
• Problema productor-consumidor.
• Tecnología de empuje.
• RSS, un protocolo de sindicación web altamente escalable
• Usenet.
• WebSub, una implementación de pub/sub.

1. ↑ Hohpe, Gregor (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional. ISBN 978-0321200686. 
2. ↑ «Chen, Chen; Tock, Yoav; Girdzijauskas, Sarunas (2018). "BeaConvey". Proceedings of the 12th ACM International Conference on Distributed and Event-based Systems.». 
3. ↑ ACM Press. pp. pp. 64-75. ISBN 9781450357821. 
4. ↑ Rahimian, Fatemeh (2012). Locality-Awareness in a Peer-to-Peer Publish/Subscribe Network. pp. pp. 45-58. ISBN 9783642308222. 
5. ↑ Birman, K.; Joseph, T (1987). Exploiting virtual synchrony in distributed systems. pp. pp. 123-138. ISBN 089791242X.