Por omisión, un intermediario descarta una publicación
después de haberla enviado a todos los suscriptores interesados en ella. Sin embargo, un publicador puede especificar que desea que el intermediario conserve una copia de una publicación que, a partir de
ese momento, se llamará publicación retenida.
El intermediario envía una copia de la publicación a todos los suscriptores que registran
su interés sobre el tema de la publicación. significa que el nuevo suscriptor no tiene que esperar a que la información vuelva a publicarse para recibirla.
Por ejemplo, un suscriptor que registre una suscripción al precio de unas acciones recibe el último precio
publicado directamente, sin tener que esperar a que el precio de dichas acciones cambie y vuelva a publicarse.
Si se ha especificado RetainPub como opción de publicación en el mensaje de publicación, el intermediario
retiene la publicación que sustituye a las publicaciones retenidas anteriores de dicho tema.
Como
el intermediario retiene únicamente una publicación para cada tema y punto
de suscripción, la publicación antigua se suprime cuando llega una nueva
publicación.
Al decidir si va a utilizar o no publicaciones
retenidas, considere las siguientes preguntas.
- ¿Contienen las publicaciones información de estado o información de sucesos?
Normalmente, la información de sucesos no se
retiene, pero la información de estado sí. Sin embargo, si todas las
suscripciones a un tema están en su sitio antes de haber efectuado ninguna
publicación sobre ese tema, y si no se esperan nuevas suscripciones,
no es necesario retener publicaciones, incluso para la información de
estado, puesto que las publicaciones se entregarán a todos los
suscriptores en cuanto se publiquen.
Puede que tampoco sea
necesario retener publicaciones que contienen información de estado si
éstas se publican con mucha frecuencia (por ejemplo, cada segundo). Con
esta frecuencia de publicación, cualquier nuevo suscriptor (o un
suscriptor que se recupere de una anomalía) recibe el estado actual casi
inmediatamente después de suscribirse.
- ¿Desea recibir publicaciones sólo cuando las solicite?
Si utiliza publicaciones retenidas, los
suscriptores pueden registrarse utilizando la opción
PubOnReqOnly del mensaje de registro de suscriptor. Esto
significa que el intermediario envía publicaciones a un suscriptor sólo
cuando dicho suscriptor solicita una actualización. El intermediario envía
entonces al suscriptor la publicación que esté retenida en ese momento y
que coincida con la suscripción.
- ¿Pueden mezclarse las publicaciones retenidas con publicaciones no retenidas sobre el mismo tema?
No es aconsejable. Si tiene una publicación retenida y publica después una publicación no retenida
sobre el mismo tema, la publicación retenida ya existente seguirá quedando retenida. No se actualizará con la publicación no retenida. Si un suscriptor se registra utilizando la opción PubOnReqOnly del mensaje de registro de suscriptor,
no podrá acceder a ninguna publicación no retenida.
El intermediario envía únicamente la publicación retenida en ese momento en respuesta a una petición de actualización.
- ¿Puede haber más de una aplicación publicando publicaciones retenidas sobre el mismo tema?
Es
aconsejable no tener más de una aplicación publicando publicaciones retenidas sobre el mismo tema. Si lo hace, y el tiempo entre publicaciones es casi simultáneo, no se determina
qué publicación está retenida. Si los publicadores utilizan distintos intermediarios, cada intermediario podría contener distintas publicaciones
sobre el mismo tema.
- ¿Cómo se recupera la aplicación de suscriptor de una anomalía?
Si el publicador no usa publicaciones retenidas, la aplicación de suscriptor podría necesitar
almacenar localmente su estado actual. Si el publicador utiliza publicaciones retenidas, el suscriptor puede
pedir una actualización para renovar su información de estado después de un reinicio.
El continúa enviando publicaciones a un suscriptor registrado incluso
si dicho suscriptor no está ejecutándose. Esto puede producir una
acumulación de mensajes en la cola de suscriptores.
Esa acumulación puede evitarse si el suscriptor se registra utilizando la opción PubOnReqOnly del
mensaje de registro de suscriptor. A continuación, el suscriptor deberá renovar el estado periódicamente solicitando una actualización o utilizando una cola dinámica
temporal.
- ¿Cuáles son las implicaciones sobre el rendimientos provocadas por las publicaciones retenidas?
El intermediario necesita almacenar las publicaciones retenidas en una base de datos. Esto reduce la productividad. Si las publicaciones son muy grandes, se necesita una cantidad de espacio en disco considerable para almacenar la publicación retenida sobre cada tema. En un entorno de múltiples intermediarios, las publicaciones retenidas las almacenan todos los demás intermediarios
conectados que tengan suscripciones coincidentes.
Use el campo Expiry del descriptor de mensaje
(MQMD) par establecer un intervalo de caducidad para una publicación retenida.
Las aplicaciones de verificación
de ejemplo que se envían con WebSphere Message Broker incluyen el Servicio de resultados
de fútbol (soccer). Ese ejemplo utiliza publicaciones retenidas para registrar la puntuación más reciente
de cada partido de fútbol que se esté supervisando. El código del ejemplo ilustra la programación que se requiere
para soportar esta opción.
No todas las aplicaciones pueden
publicar publicaciones retenidas, y no a todas las publicaciones retenidas
se les pueden aplicar fechas de caducidad. La siguiente tabla muestra qué
aplicaciones pueden publicar publicaciones retenidas y si las
publicaciones retenidas pueden tener una fecha de caducidad:
|
MQ |
SCADA |
JMS/IP |
Retenidas |
SÍ |
SÍ |
NO |
Fecha caducidad |
SÍ |
NO |
NO |
Las columnas de la tabla indican tres tipos de
aplicación. 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 caducidad a la publicación.