Este artículo necesita citas adicionales para su verificación . ( marzo de 2010 ) |
En la arquitectura de software , publicar-suscribirse es un patrón de mensajería en el que los remitentes de mensajes , denominados editores, no programan los mensajes para que se envíen directamente a receptores específicos, denominados suscriptores, sino que clasifican los mensajes publicados en clases sin saber qué suscriptores, si los hay. , puede haber. 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, los hay.
Publish-subscribe es un hermano del paradigma de la cola de mensajes y, por lo general, es una parte de un sistema de middleware orientado a mensajes más grande . La mayoría de los sistemas de mensajería son compatibles con los modelos pub / sub y 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 disminución de la flexibilidad para modificar el editor y la estructura de los datos publicados.
En el modelo de publicación-suscripción, los suscriptores generalmente reciben solo 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 en canales lógicos con nombre. Los suscriptores en un sistema basado en temas recibirán todos los mensajes publicados sobre los temas a los que se suscriben. 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 envían mensajes a 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 editores envían mensajes a un intermediario de mensajes o bus de eventos , y los suscriptores registran suscripciones con ese intermediario, lo que permite que el intermediario realice el filtrado. El corredor 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 de 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 su lugar, cada editor y suscriptor del sistema de publicación / subsistema comparte metadatos entre sí a través de la 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. 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 desde los editores hasta los suscriptores. Jon Kleinberg demostró que el enrutamiento descentralizado eficiente requiere topologías navegables de mundo pequeño . Estas topologías de Small-World generalmente se implementan mediante sistemas de publicación / suscripción descentralizados o federados.[1] Los sistemas de publicación / suscripción conscientes de la localidad [2] construyen topologías Small-World que enrutan las suscripciones a través de enlaces de corta distancia y de bajo costo, lo que reduce los tiempos de entrega de las suscripciones.
Uno de los primeros sistemas pub / subs descritos públicamente fue el subsistema de "noticias" del Isis Toolkit, descrito en el Simposio de 1987 de la Asociación de Maquinaria de Computación (ACM) sobre principios de sistemas operativos (SOSP '87), en un documento "Explotación virtual Sincronía en sistemas distribuidos . 123-138 ". [3]
Los editores están poco vinculados a los suscriptores y ni siquiera necesitan saber de su existencia. Con el tema como foco, los editores y suscriptores pueden ignorar la topología del sistema. Cada uno puede seguir funcionando normalmente de forma independiente del otro. En el paradigma tradicional 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 esté ejecutándose. Muchos sistemas de pub / subs 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 tales sistemas de publicación / subs es eliminar un editor para permitir que el suscriptor trabaje a través de la acumulación (una forma deestrangulamiento del ancho de banda ).
Pub / sub brinda la oportunidad de una mejor escalabilidad que el tradicional cliente-servidor, a través del funcionamiento en paralelo, el almacenamiento en caché de mensajes, el enrutamiento basado en árboles o en red, etc. Sin embargo, en ciertos tipos de entornos empresariales de gran volumen y estrechamente acoplados, como sistemas escalar 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 pub / sub con una gran 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 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 distribuir mensajes a (potencialmente) millones de nodos de suscriptores separados.
Los problemas más serios con los sistemas pub / subs son un efecto secundario de su principal ventaja: la disociación del editor del suscriptor.
Un pub / sub sistema debe diseñarse cuidadosamente para poder proporcionar propiedades de sistema más sólidas que una aplicación en particular podría requerir, como la entrega asegurada.
El patrón pub / sub se adapta bien a redes pequeñas con un número reducido de nodos de publicadores y suscriptores 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 / subred. 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 es dentro de banda y puede estar sujeto a problemas de seguridad. Se puede engañar a los corredores para que envíen notificaciones al cliente equivocado, lo que amplifica las solicitudes de denegación de servicio contra el cliente. Los propios corredores podrían estar sobrecargados al asignar recursos para realizar un seguimiento de las suscripciones creadas.
Incluso con sistemas que no dependen de intermediarios, un suscriptor puede 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 / subsistema. Esto es especialmente cierto con los sistemas que broadcast o multicast sus mensajes. El cifrado (por ejemplo, Transport Layer Security (SSL / TLS)) puede evitar el acceso no autorizado, pero no puede evitar que los editores autorizados introduzcan mensajes dañinos. Las arquitecturas distintas de pub / sub, como los sistemas cliente / servidor, también son vulnerables a los remitentes de mensajes autorizados que se comportan de forma maliciosa.
Es posible que el uso de enlaces externos en este artículo no siga las políticas o pautas de Wikipedia . ( Junio de 2016 ) |