Es importante proteger los mensajes que circulan por el dominio de intermediarios. Esto es válido tanto para los mensajes generados por una aplicación como para los que se utilizan internamente para la comunicación entre componentes. Los mensajes que se utilizan internamente entre componentes siempre utilizan el protocolo de WebSphere MQ. Los mensajes de aplicaciones pueden utilizar todos los protocolos de transporte soportados.
Para los mensajes de aplicaciones y los mensajes internos que se mueven por WebSphere MQ, hay dos técnicas que les protege contra la pérdida de mensajes:
Si un mensaje es persistente, WebSphere MQ asegura que no se pierda cuando se produce un error, copiándolo en el disco.
Una aplicación puede solicitar que un mensaje se procese en una unidad de trabajo (UOW) sincronizada
Para obtener más información sobre cómo utilizar estas opciones, consulte la WebSphere MQguía de administración del sistema.
Los componentes de WebSphere Message Broker utilizan los mensajes de WebSphere MQ para comunicar sucesos y datos entre los procesos de intermediario y los subsistemas, y el Gestor de configuración y el Servidor de nombres de usuario. Los componentes aseguran que se aprovechen las características de WebSphere MQ para proteger contra la pérdida de mensajes. No es necesario efectuar ningún paso adicional para configurar WebSphere MQ o WebSphere Message Broker para que proteja contra la pérdida de mensajes internos.
Si la entrega de mensajes de aplicaciones es muy importante, debe diseñar los programas de aplicación y los flujos de mensajes que utilizan para asegurarse de que no se pierden mensajes. Las técnicas que se utilizan dependen del protocolo utilizado por las aplicaciones.
Los productos de mensajería de WebSphere MQ proporcionan persistencia de mensajes, que define la longevidad del mensaje en el sistema y garantiza la integridad del mensaje. Los mensajes no persistentes se pierden en el caso de que se produzca una anomalía en el sistema o el gestor de colas. Los mensajes persistentes siempre se recuperan, aún en el caso de anomalías.
Cuando un nodo de entrada lee un mensaje de la cola de entrada, la acción por omisión es utilizar la persistencia definida en el cabecera del mensaje (MQMD) de WebSphere MQ, que ha sido establecida por la aplicación que crea el mensaje o por la persistencia por omisión de la cola de entrada. El mensaje conserva esta persistencia a través del flujo de mensajes, a menos que se cambie en un nodo de proceso de mensajes posterior.
Puede alterar temporalmente el valor de persistencia de cada mensaje cuando el flujo de mensajes termina en un nodo de salida. Este nodo tiene una propiedad que le permite especificar la persistencia de cada mensaje cuando se coloca en la cola de salida, bien como valor necesario o como un valor por omisión. Si especifica el valor por omisión, el mensaje toma el valor de persistencia definido para las colas en las que se escriben los mensajes.
Si un mensaje pasa a través de un nodo Publication, la persistencia de los mensajes enviados a los suscriptores la determinan las opciones de registro de los suscriptores. Si un suscriptor ha solicitado la entrega de un mensaje persistente y está autorizado a ello por un ACL explícito o implícito (heredado), el mensaje se entrega de forma persistente, independientemente de la propiedad de persistencia existente. Además, si el usuario ha solicitado la entrega de un mensaje no persistente, el mensaje se entrega de forma no persistente, independientemente de la propiedad de persistencia existente.
Si un flujo de mensajes crea un nuevo mensaje (por ejemplo, en un nodo Compute), la persistencia en el MQMD del nuevo mensaje se copia de la persistencia del MQMD del mensaje de entrada.
La acción por omisión de un flujo de mensajes es procesar mensajes de entrada bajo un punto de sincronización en una transacción controlada por intermediario. Esto significa el intermediario restituye el mensaje que, por algún motivo, no se puede procesar. Puesto que se ha recibido bajo un punto de sincronización, el mensaje anómalo se vuelve a colocar en la cola de entrada y puede procesarse de nuevo. Si el proceso falla, se ejecutan los procedimientos de manejo de errores que hay para este flujo de mensajes (definidos según cómo se haya configurado el flujo de mensajes o por el intermediario).
Para obtener más información sobre el proceso del nodo de entrada, consulte Gestionar errores en el nodo de entrada.
Si se publica un mensaje SCADA persistente, puede rebajarse al nivel más alto que el cliente pueda aceptar. En algunas circunstancias, esto puede significar que el mensaje pasa a ser no persistente.