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.

Figura 1. Patrón típico de mensajería JMS
Un patrón típico de mensajería JMS
El patrón de solicitud y respuesta requiere las condiciones siguientes:
  • 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.
Una cola JMS puede hacer referencia a un destino del bus de integración de servicios que esté definido en un miembro de bus del servidor o en un miembro de bus del clúster.
  • 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.
Figura 2. Un destino de cola de bus de integración de servicios definido en un miembro de bus del servidor de aplicaciones
Un destino de cola de bus de integración de servicios definido en un miembro del bus del servidor de aplicaciones.
El comportamiento siguiente se produce de manera predeterminada:
  • 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.

Figura 3. Un destino de cola de bus de integración de servicios que está definido en un miembro de bus con dos motores de mensajería
Un destino de cola de bus de integración de servicios definido en un miembro de bus de clúster con dos motores de mensajería.

Sopese las ventajas y los inconvenientes de cada opción y los requisitos de la aplicación antes de elegir un enfoque.

Resumen

Utilice la solución más sencilla que satisfaga los requisitos del escenario de solicitud/respuesta. Por ejemplo:
  • 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.

Por ejemplo, si las aplicaciones solicitantes normalmente reciben sus mensajes de respuesta durante la conexión inicial,pero en determinadas condiciones muy poco frecuentes (por ejemplo, debido a una anomalía) se tienen que volver a conectar para recibir la respuesta, el método siguiente puede resultar más adecuado:
  • 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.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjt0020_
File name: cjt0020_.html