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.

- 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.
- 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.

- 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.

- Usar uma fila temporária como a fila de resposta.
- Usar um destino de alias do barramento de integração de serviços com escopo para restringir mensagens a um único ponto de fila.
- Restringir mensagens de resposta ao ponto de fila local para o aplicativo solicitante.
- Configure o solicitante para consumir mensagens de todos os pontos da fila simultaneamente.
Considere as vantagens e desvantagens de cada opção e os requisitos de seu aplicativo, antes de escolher uma abordagem.
Sumarização
- 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.
- 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.