Solicitud JMS y mensajería de respuesta con miembros de bus del clúster
Un patrón típico de mensajería JMS implica una aplicación solicitante que envía un mensaje a una cola JMS para que sea procesada por un servicio de mensajería, por ejemplo, un bean controlado por mensaje).
Cuando la aplicación solicitante envía el mensaje de solicitud, el mensaje identifica otra cola JMS a la que el servicio debe enviar un mensaje de respuesta. Después de enviar el mensaje de solicitud, la aplicación solicitante o bien espera a que llegue el mensaje de respuesta o bien vuelve a conectarse más tarde para recuperar el mensaje de respuesta.

- La aplicación solicitante puede identificar, en el mensaje solicitante, dónde debe enviar el servicio el mensaje de respuesta.
- La aplicación solicitante puede consumir el mensaje de respuesta desde la ubicación de respuesta.
- Si el miembro de bus es un servidor (que puede tener sólo un motor de mensajería) o un clúster con un único motor de mensajería, una cola JMS identifica un único punto de cola del bus de integración de servicios.
- Si el miembro de bus es un clúster con varios motores de mensajería (normalmente, para proporcionar compartimiento de carga de trabajo o escalabilidad), una cola JMS identifica varios puntos de cola; uno en cada motor de mensajería del miembro de bus.

- El punto de cola al que una aplicación envía mensajes, o del que recibe mensajes, está determinado por el sistema de mensajería.
- Durante su vida útil, un consumidor, en este caso un consumidor de mensajes JMS, consume sólo desde un punto de cola.
Este comportamiento de solicitud y respuesta permite que se envíe un mensaje de respuesta a un punto de cola diferente de aquél en el que el solicitante lo está esperando. Como resultado de ello, es posible que no se reciba el mensaje de respuesta.

- Utilizar una cola temporal como cola de respuestas.
- Utilizar un ámbito del destino de alias del bus de integración de servicios para limitar los mensajes a un único punto de cola.
- Restringir los mensajes de respuesta al punto de cola que sea local a la aplicación solicitante.
- Configure el solicitante para consumir mensajes de todos los puntos de cola simultáneamente.
Sopese las ventajas y los inconvenientes de cada opción y los requisitos de la aplicación antes de elegir un enfoque.
Resumen
- Si sólo se requieren mensajes de respuesta mientras la aplicación solicitante está conectada inicialmente, utilice mensajes no persistentes y colas temporales. Además, considere la posibilidad de establecer un timeToLive del mensaje de solicitud inicial, si la aplicación solicitante esperará una respuesta sólo durante un período de tiempo finito.
- Si un único punto de cola (y su motor de mensajería) puede manejar todo el tráfico de mensajes de respuesta para las aplicaciones solicitantes, pero se requiere un miembro de bus del clúster para el resto del tráfico de mensajería (por ejemplo, los mensajes de solicitud), utilice un destino de alias del bus de integración de servicios para establecer el ámbito de los mensajes en ese único punto de cola.
Si es necesario, puede combinar estas opciones para obtener la solución que mejor cumpla con los requisitos de la aplicación y que posea el mejor rendimiento y escalabilidad.
- Habilite la opción scopeToLocalQP de la cola JMS y permita que la aplicación solicitante se conecte a cualquiera de los motores de mensajería del miembro de bus del clúster (es decir, establezca el destino de la fábrica de conexiones JMS en el miembro de bus). De esta manera, se equilibra la carga de trabajo de las conexiones pero los mensajes de respuesta están limitados al punto de cola local. El resultado es que pueden encontrarse los mensajes de respuesta mientras se utiliza la misma conexión para recibir la respuesta que se ha utilizado para enviar la solicitud.
- Al volver a conectar después de una anomalía, habilite la opción Recopilación de mensajes en la cola JMS de modo que el mensaje de respuesta pueda recibirse desde dondequiera que esté contenido.
Este método permite equilibrar de forma dinámica la carga de trabajo de las aplicaciones solicitantes y al mismo tiempo minimiza las implicaciones de rendimiento relacionadas con la recopilación de mensajes, ya que reduce su uso a los escenarios de anomalías.