Pedido de JMS e Sistema de Mensagens de Resposta com Membros de Barramento de Cluster

Um padrão de sistema de mensagens JMS típico envolve um aplicativo solicitante que envia uma mensagem para uma fila JMS para processamento por um serviço de sistema de mensagens, por exemplo, um bean acionado por mensagens.

Quando o aplicativo de pedido envia uma mensagem de pedido, a mensagem identifica outra fila JMS à qual o serviço deve enviar uma mensagem de resposta. Depois de enviar a mensagem de pedido, o aplicativo solicitante espera a chegada da mensagem de resposta, ou reconecta-se posteriormente para recuperar a mensagem de resposta.

Figura 1. Padrão Típico do Sistema de Mensagem JMS
Um padrão típico do sistema de mensagens JMS
O padrão de pedido e resposta requer as seguintes condições:
  • O aplicativo solicitante pode identificar, na mensagem de pedido, onde o serviço deve enviar a mensagem de resposta.
  • O aplicativo solicitante pode consumir a mensagem de resposta do local de resposta.
Uma fila JMS pode consultar um destino do barramento de integração de serviços que está definido em um membro do barramento do servidor ou um membro do barramento do cluster.
  • Se o membro do barramento for um servidor (que pode ter apenas um mecanismo do sistema de mensagens), ou um cluster com um único mecanismo do sistema de mensagens, uma fila JMS identificará um único ponto de fila do barramento de integração de serviços.
  • Se o membro do barramento for um cluster com múltiplos mecanismos do sistema de mensagens (geralmente, para fornecer compartilhamento ou escalabilidade de carga de trabalho), uma fila JMS identificará múltiplos pontos de fila; um em cada mecanismo do sistema de mensagens no membro do barramento.
Figura 2. Um Destino de Fila do Barramento de Integração de Serviços Definido para um Membro de Barramento do Servidor de Aplicativos
Um destino de fila do barramento de integração de serviços definido para um membro do barramento do servidor de aplicativos.
O seguinte comportamento ocorre por padrão:
  • O ponto de fila ao qual um aplicativo envia mensagens ou do qual recebe mensagens é determinado pelo sistema de mensagens.
  • Durante seu tempo de vida, um consumidor, nesse caso, um consumidor de mensagens JMS, consome apenas de um ponto de fila.

Esse comportamento de solicitação e resposta permite que uma mensagem de resposta seja enviada para um ponto diferente da fila daquele no qual o solicitante está aguardando por ela. Isso pode resultar no não recebimento da mensagem de resposta.

Figura 3. Um destino de fila do barramento de integração de serviços que está definido para um membro do barramento do cluster com dois mecanismos de sistema de mensagens
Um destino de fila do barramento de integração de serviços que está definido para um membro do barramento do cluster com dois mecanismos de sistema de mensagens.

Considere as vantagens e desvantagens de cada opção e os requisitos de seu aplicativo, antes de escolher uma abordagem.

Sumarização

Use a solução mais simples que satisfaça os requisitos do cenário de pedido/resposta. Por exemplo:
  • Se mensagens de resposta forem requeridas somente enquanto o aplicativo de pedido é inicialmente conectado, use mensagens não persistentes e filas temporárias. Além disso, considere configurar um timeToLive da mensagem de pedido inicial, se o aplicativo de pedido for aguardar por uma resposta apenas por um tempo definido.
  • Se um único ponto de fila (e seu mecanismo do sistema de mensagens) puder tratar de todo o tráfego de mensagem de resposta dos aplicativos solicitantes, mas um membro do barramento de cluster com múltiplos mecanismos de sistema de mensagens for necessário para outro tráfego do sistema de mensagens (por exemplo, as mensagens de pedido), use um destino de alias do barramento de integração de serviço para definir o escopo das mensagens desse único ponto de fila.

Se necessário, você poderá combinar essas opções para alcançar a solução que melhor satisfaz os requisitos do aplicativo e que tenha o melhor desempenho e escalabilidade.

Por exemplo, se os aplicativos de solicitação normalmente receberem suas mensagens de resposta durante e conexão inicial, mas sob determinadas condições raras (por exemplo, uma falha) precisarem se reconectar para receber as resposta, a seguinte abordagem poderá ser apropriada:
  • Ative a opção scopeToLocalQP da fila JMS e permita que o aplicativo de pedido se conecte a qualquer um dos mecanismos do sistema de mensagem no membro de barramento do cluster (ou seja, destine o connection factory JMS no membro de barramento). Isso permite que as conexões tenham sua carga de trabalho balanceadas mas restringe as mensagens de resposta para o ponto de fila local. O resultado é que as mensagens de resposta podem ser encontradas ao usar a mesma conexão para receber a resposta que foi usada para enviar o pedido.
  • Ao reconectar-se após uma falha, ative a opção Reunião de menagens na fila JMS para que a mensagem de resposta possa ser recebida do lugar que ela estiver retida.

Essa abordagem permite o balanceamento dinâmico de carga de trabalho dos aplicativos de pedidos e minimiza as implicações de desempenho da coleta de mensagens ao reduzir seu uso em cenários de falha.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjt0020_
Nome do arquivo: cjt0020_.html