Sequência da Mensagem

A organização de mensagens é importante para alguns aplicativos do sistema de mensagens assíncronas, ou seja, é importante consumir mensagens na mesma ordem em que o produtor as envia. Se esse tipo de organização de mensagens for importante para o aplicativo, o projeto deverá levar isso em consideração.

Por exemplo, um aplicativo do sistema de mensagens que processa reservas de assentos pode ter componentes do produtor e um componente do consumidor. Um componente do produtor envia uma mensagem para o componente do consumidor quando um cliente reserva um assento. Se o cliente cancelar a reserva, então o produtor (ou possivelmente um produtor diferente) envia uma segunda mensagem. Normalmente, o componente do consumidor deve processar a primeira mensagem (que reserva o assento) antes de processar a segunda (que cancela a reserva).

Alguns aplicativos usam um padrão (pedido-resposta) síncrono, no qual o produtor aguarda por uma resposta para cada mensagem antes de enviar a mensagem seguinte. Nesse tipo de aplicativo, o consumidor controla a ordem na qual ele recebe as mensagens e pode garantir que essa seja a mesma ordem em que o produtor ou os produtores as enviaram. Outros aplicativos usam o padrão (do tipo fire and forget) assíncrono, no qual o produtor envia mensagens sem aguardar respostas. Mesmo para esse tipo de aplicativo, a ordem é geralmente preservada, ou seja, um consumidor pode esperar receber mensagens na mesma ordem em que o produtor ou os produtores as envia, especialmente quando há um tempo expressivo entre o envio de mensagens consecutivas. Entretanto, o projeto deve levar em consideração fatores que podem interromper essa ordem.

A ordem das mensagens será quebrada se seu aplicativo enviar mensagens com prioridades diferentes (mensagens de prioridade alta podem se sobrepor às mensagens de prioridade inferior) ou se seu aplicativo receber explicitamente uma mensagem diferente da primeira especificando os seletores de mensagem. O processamento paralelo e o processamento de erro ou de exceção também podem afetar a ordem da mensagem.

Processamento Paralelo

Destinos Múltiplos
Quando um produtor envia uma mensagem para um destino e, então, envia uma segunda para um destino diferente, é possível que a segunda mensagem chegue ao seu destino antes da primeira mensagem chegar ao seu. Isso pode acontecer até se o produtor enviar ambas as mensagens a partir da mesma transação (a transação garante que ambas falhem ou que ambas sejam concluídas; ela não garante a ordem da entrega). Se isso for um problema para o aplicativo, então evite usar mais de um destino para o aplicativo.
Múltiplos Produtores
Quando um produtor envia uma mensagem para um destino e, então, um segundo produtor envia uma segunda mensagem para o mesmo destino, é possível que a segunda mensagem chegue ao destino antes da primeira mensagem. Isso ocorre mesmo que o segundo produtor entre em sincronia com o primeiro, como por exemplo ao aguardar para um sinal do primeiro produtor, antes de enviar sua mensagem (a segunda mensagem). Isso também pode ocorrer mesmo se os produtores forem transacionais (o fato de uma transação estar concluída não significa que a mensagem ou as mensagens estão em seus destinos - a integração de serviço pode concluir uma transação primeiro e, então, entregar a mensagem ou as mensagens posteriormente). Se isso for um problema para o aplicativo, evite usar mais de um produtor para ele. Da mesma forma, evite usar um produtor único que execute múltiplos encadeamentos paralelos.
Múltiplos Consumidores
Quando duas mensagens chegam a um destino de tipo de fila, no qual há múltiplos consumidores, é possível que um consumidor receba a primeira mensagem e outro receba a segunda. Se os consumidores puderem ser executados em paralelo, então o consumidor que receber a segunda mensagem poderá processá-la antes do consumidor que receber a primeira mensagem. Além disso, se um consumidor receber uma mensagem de forma transacional e, então, retroceder a transação, a mensagem retornará ao destino no qual outro consumidor poderá recebê-la. Enquanto isso, esse outro consumidor poderá já ter recebido e processado outras mensagens (posteriores). Se qualquer uma dessas situações foi um problema para o aplicativo, então evite usar mais de um consumidor para ele. De forma semelhante, não permita múltiplas chamadas simultâneas do bean acionado por mensagens (MDB) por terminal (consulte Configurando o Controle de MDB para o Fornecedor de Sistema de Mensagens Padrão). De forma alternativa, considere usar uma organização estrita de mensagens; consulte Ordenação de Mensagens Rigorosa para Destinos de Barramento.
Armazenamento em Cluster e Destinos Particionados
Quando um destino de tipo de fila é designado a um membro do barramento de cluster com mais de um mecanismo do sistema de mensagens, então cada mecanismo do sistema de mensagens conterá uma partição do destino (ou seja, um dos pontos de fila do destino); a integração de serviço pode entregar mensagens diferentes para esse destino para partições diferentes. Essa configuração do destino de tipo de fila pode fornecer disponibilidade, escalabilidade e balanceamento de carga, mas ela não é normalmente apropriada para aplicativos nos quais a organização de mensagens é importante. A integração de serviços não garante a organização de mensagens enviadas a partições diferentes do mesmo destino. Além disso, um mecanismo do sistema de mensagens pode falhar enquanto essas mensagens estiverem na partição de destino que ele contém; essas mensagens não estarão disponíveis para consumidores até que o mecanismo do sistema de mensagens seja reiniciado. Entretanto, a integração de serviço pode continuar a entregar mensagens mais novas para outras partições (em outros mecanismos do sistema de mensagens) e consumidores podem receber e processar essas mensagens mais novas, antes das mensagens mais antigas contidas na partição do mecanismo do sistema de mensagens que falhou. Compartilhamento de Carga de Trabalho com Destinos de Fila oferece mais detalhes sobre esse tipo de configuração e também explica como você pode usar a opção Afinidade de mensagem, que pode ajudar a manter a organização de mensagens entre um produtor único e um consumidor único em um cluster (mas não se o cluster estiver em um barramento de integração de serviços diferente).
Publicação e Assinatura
Para o sistema de mensagens de publicação-assinatura, a integração de serviço não garante a organização de mensagens recebidas por instâncias diferentes de uma assinatura, incluindo instâncias separadas de uma assinatura durável, criada com a propriedade Compartilhar Assinaturas Duráveis configurada para permitir o compartilhamento.

Condições de Erro e de Exceções

Qualidade de serviço
A qualidade do serviço de uma mensagem determina como as condições de erro e de exceção podem afetar a entrega da mensagem (consulte Níveis de Confiabilidade da Mensagem - Modo de Entrega de JMS e Qualidade da Integração de Serviço do Serviço. Dependendo da qualidade do serviço, uma condição de erro ou de exceção pode fazer com que a integração de serviço entregue a mensagem com confiança (exatamente uma vez) ou com menos segurança (mais de uma vez ou nenhuma vez). Por exemplo, com a qualidade de serviço expresso e não persistente, é possível que sequências de mensagens sejam entregues novamente após uma falha, entretanto a ordem subjacente será sempre mantida, de modo que as mensagens possam chegar na sequência: 1, 2, 3, 2, 3, 4. De forma mais geral, a integração de serviço não garante a organização de mensagens diferentes enviadas com qualidades diferentes de serviço. Se isso for um problema para o aplicativo, então certifique-se de selecionar uma qualidade apropriada de serviço e evite misturar qualidades diferentes de serviços para mensagens para o mesmo destino.
Destinos de Exceção
Sob alguns cenários de falha, a integração de serviço pode entregar uma mensagem para um destino de exceção ou entregar uma mensagem para um destino e subsequentemente transferi-la para um destino de exceção. A integração de serviço não garante a organização de mensagens que envia ou transfere para um destino de exceção. Se isso for um problema para o aplicativo, então será possível configurar o destino para que ele não use o destino de exceção (consulte Destinos de Exceção). Se o produtor e o destino estiverem em barramentos diferentes, você poderá configurar o link ou links entre esses barramentos para que não haja destinos de exceção (consulte Barramentos Externos e Configurando Processamento de Destino de Exceção de um Link para um Barramento Externo.
Retrocesso da Transação
A especificação de ativação para um bean acionado por mensagens (MDB) pode especificar um atraso entre novas tentativas de mensagens falhas. Esse atraso dá tempo para que a condição que provoca o retrocesso se recupere, antes de a mesma mensagem acionar o MDB novamente. Entretanto, enquanto uma mensagem é atrasada dessa forma, outra (posterior) mensagem pode acionar o MDB (consulte Protegendo um aplicativo MDB de problemas de recursos do sistema). Se isso for um problema para o aplicativo, então considere limitar o máximo de falhas sequenciais a um (consulte Especificação de Ativação JMS [Configurações] ou considere usar uma organização estrita de mensagens, consulte Ordenação de Mensagens Rigorosa para Destinos de Barramento.
Resolvendo Transações Indeterminadas
Durante o processamento two-phase commit, um aplicativo pode falhar enquanto uma operação JMS de envio ou recebimento está em um estado indeterminado. Quando isso acontece, é possível que o aplicativo seja reiniciado antes que o estado indeterminado seja resolvido, para que uma ou mais mensagens fiquem "invisíveis" quando o aplicativo for reiniciado, mas tornem-se "visíveis" posteriormente. Outras mensagens no destino não são afetadas. Um aplicativo de consumo pode receber uma mensagem (digamos, a mensagem 2) que fica logicamente depois de uma mensagem "invisível" (digamos, a mensagem 1); posteriormente, depois que a transação indeterminada é resolvida, o aplicativo recebe a mensagem "invisível" anteriormente (mensagem 1). Dessa forma, o aplicativo poderá receber e processar mensagens na ordem errada. Se isso for um problema para o aplicativo, então considere usar a organização estrita de mensagens; consulte Ordenação de Mensagens Rigorosa para Destinos de Barramento.

Í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=cjj8000_
Nome do arquivo: cjj8000_.html