Un intermediario descarta por omisión una publicación tras haberla enviado a todos los suscriptores interesados. No obstante, un publicador puede especificar que desea que el intermediario guarde una copia de una publicación, la cual pasa a denominarse publicación retenida.
El intermediario envía una copia de una publicación retenida a todos los suscriptores que registran su interés por el tema de la publicación. Esto significa que un nuevo suscriptor no tiene que esperar a que vuelva a publicarse información para poder recibirla.
Por ejemplo, un suscriptor que registra una suscripción a un precio de stock recibe inmediatamente el precio publicado más reciente sin necesidad de esperar a que el precio de stock cambie y vuelva a publicarse.
Si en el mensaje de Publish se especifica RetainPub como una opción de publicación, el intermediario retiene la publicación y sustituye las publicaciones retenidas anteriormente de ese tema.
Dado que el intermediario retiene sólo una publicación por cada tema y punto de suscripción, la publicación antigua se suprime cuando llega una publicación nueva.
En el momento de decidir si desea utilizar publicaciones retenidas, debe considerar los factores siguientes:
Normalmente, la información de sucesos no se retiene, pero sí se retiene la información de estado. No obstante, si todas las suscripciones a un tema se han hecho efectivas antes de que se realicen publicaciones sobre dicho tema, y si no se esperan nuevas suscripciones, no será necesario retener publicaciones, ni siquiera para la información de estado, ya que las publicaciones se entregan a todos los suscriptores inmediatamente después de publicarse.
Es posible que tampoco sea necesario retener publicaciones de información de estado, si éstas se publican muy frecuentemente (por ejemplo, cada segundo). Gracias a esta frecuencia de publicación, un nuevo suscriptor (o un suscriptor que se recupere de una anomalía) recibe el estado actual casi inmediatamente después de suscribirse.
Si utiliza publicaciones retenidas, los suscriptores pueden registrarse utilizando la opción PubOnReqOnly del mensaje de Register Subscriber. Esto significa que el intermediario envía publicaciones a un suscriptor sólo cuando éste solicita una actualización. Seguidamente, el intermediario envía al suscriptor la publicación retenida actual que coincide con la suscripción.
Esto no es recomendable. Si tiene una publicación retenida y publica una publicación no retenida basada en el mismo tema, la publicación retenida existente seguirá retenida. Dicha publicación no se actualizará mediante la publicación no retenida. Si un suscriptor se registra utilizando la opción PubOnReqOnly del mensaje de Register Subscriber, no podrá acceder a ninguna de las publicaciones no retenidas. El intermediario sólo envía la publicación retenida actual en respuesta a una petición de actualización.
Se recomienda no tener más de una publicación retenida de publicación de aplicaciones basada en el mismo tema. Si tiene más de una, y si las tiene casi de forma simultánea, no podrá determinarse qué publicación quedará retenida. Si los publicadores utilizan intermediarios distintos, cada intermediario servirá para retener las distintas publicaciones retenidas para un mismo tema.
Si el publicador no utiliza publicaciones retenidas, es posible que la aplicación de suscriptor deba almacenar localmente su estado actual. Si el publicador utiliza publicaciones retenidas, el suscriptor puede solicitar una actualización de la información de estado tras efectuarse un reinicio.
El intermediario continúa enviando publicaciones a un suscriptor registrado, aunque dicho suscriptor no se esté ejecutando. Esto puede llevar a la acumulación de mensajes en la cola de suscriptores. Esta acumulación puede evitarse si el suscriptor se registra con la opción PubOnReqOnly del mensaje de Register Subscriber. El suscriptor deberá entonces actualizar su estado periódicamente solicitando una actualización o utilizando una cola dinámica temporal.
El intermediario necesita almacenar las publicaciones retenidas en una base de datos. Esto reduce el rendimiento. Si las publicaciones son muy grandes, es necesario tener una cantidad considerable de espacio en disco para almacenar la publicación retenida de cada tema. En un entorno de varios intermediarios, las publicaciones retenidas las almacenan los otros intermediarios conectados que tienen una suscripción coincidente.
Utilice el campo Expiry del descriptor de mensaje (MQMD) para establecer un intervalo de vencimiento para una publicación retenida.
Las aplicaciones de verificación de ejemplo que se envían con WebSphere Business Integration Event Broker incluyen el servicio Soccer Results. Este ejemplo utiliza publicaciones retenidas para registrar la última puntuación de cada partido de soccer que supervisa. El código de ejemplo ilustra la programación necesaria para dar soporte a esta opción.
MQ | MQe | SCADA | JMS/IP | |
---|---|---|---|---|
Retenidas | YES | YES | YES | NO |
Fecha de vencimiento | YES | YES | NO | NO |
Las columnas de la tabla indican el tipo de aplicación al que hacen referencia las filas. La primera fila indica si una publicación puede ser una publicación retenida, y la segunda fila indica si puede aplicarse una fecha de vencimiento a la publicación.
Conceptos relacionados
Publicaciones
Suscripciones
Tareas relacionadas
Publicación
Suscripciones
Anulación del registro de una suscripción
Referencia relacionada
Mensaje de Publish
Mensaje de Register Subscriber
Avisos |
Marcas registradas |
Descargas |
Biblioteca |
Soporte |
Información de retorno (feedback)
![]() ![]() |
aq13030_ |