Agregação de Fluxo de Mensagens

Agregação é a geração e o fan-out de pedidos relacionados que se originam de uma única mensagem de entrada, bem como o fan-in das respostas correspondentes para produzir uma única mensagem de resposta agregada.

O pedido inicial recebido pelo fluxo de mensagens, representando uma coleção de itens de pedido relacionados, é dividido no número apropriado de pedidos individuais para atender às subtarefas do pedido inicial. Esse processo é conhecido como fan-out, e é fornecido por um fluxo de mensagens que inclui nós de agregação.

As respostas das subtarefas são combinadas e mescladas em uma única resposta que é retornada ao solicitante original (ou outro aplicativo de destino) para indicar a conclusão do processamento. Esse processo é conhecido como fan-in, e também é fornecido por um fluxo de mensagens que inclui nós de agregação.

Uma agregação de mensagem é iniciada por um fluxo de mensagens que contém o nó AggregateControl seguido por um nó AggregateRequest. As respostas são agregadas novamente utilizando um fluxo que contém o nó AggregateReply. Os nós de agregação funcionam corretamente apenas para transportes que utilizam um modelo de pedido/resposta; por exemplo, WebSphere MQ Enterprise Transport.

O WebSphere Message Broker fornece três nós do fluxo de mensagens que suportam agregação:

Quando você inclui esses nós em seus fluxos de mensagens, os diversos pedidos de difusão são emitidos em paralelo a partir de um fluxo de mensagens. A operação padrão do fluxo de mensagens destina-se a cada nó que executa seu processamento em seqüência.

Se você utilizar o WebSphere MQ Enterprise Transport, as respostas recebidas pelo fluxo fan-in deverão ser mensagens de resposta válidas que contenham o identificador de resposta. É necessário configurar o identificador de resposta como o valor da mensagem no descritor de mensagens da mensagem de pedido (MQMD), em seguida, armazenar o identificador de resposta no campo do identificador de correlação (CorrelId) do MQMD. Se o CorrelId estiver configurado como MQCI_NONE, o nó AggregateReply emitirá um erro, porque a mensagem de resposta não é válida e não pode corresponder a uma mensagem de pedido.

Você também pode utilizar esses nós de agregação para emitir pedidos aos aplicativos fora do ambiente do intermediário. As mensagens podem ser enviadas de modo assíncrono a serviços ou aplicativos externos; as respostas são recuperadas desses aplicativos e combinadas para fornecer uma única resposta à mensagem de pedido original.

Estes nós podem ajudar a aprimorar o tempo de resposta, porque os pedidos lentos podem ser desempenhados em paralelo e não precisam seguir uns aos outros seqüencialmente. Se as subtarefas puderem ser processadas de forma independente, e não precisarem ser manipuladas como parte de uma única unidade de trabalho, elas poderão ser processadas por fluxos de mensagens separados.

Você pode projetar e configurar um fluxo de mensagens que fornece uma função semelhante sem utilizar os nós de agregação, emitindo pedidos de subtarefa para outro aplicativo (por exemplo, utilizando o nó HTTPRequest), e registrando os resultados de cada pedido no ambiente local. Após a conclusão de cada subtarefa, mescle os resultados de LocalEnvironment em um nó Compute e crie a mensagem de resposta combinada para propagação para o aplicativo de destino. No entanto, todas as subtarefas são desempenhadas seqüencialmente, e não fornecem os benefícios de desempenho de operação paralela que podem ser obtidos se você utilizar os nós de agregação.

Exemplos de fluxos de agregação que utilizam os nós de agregação são fornecidos nas amostras a seguir: A amostra Aggregation demonstra uma agregação simples de quatro vias e a amostra Airline Reservations simula pedidos que estão relacionados a um serviço de reserva de passagens aéreas e ilustra as técnicas associadas a fluxos de agregação. Você pode visualizar amostras apenas quando utilizar o centro de informações integrado ao Message Brokers Toolkit.

Os nós de agregação armazenam o estado das agregações nas filas do WebSphere MQ. Se não for especificado um tempo limite no nó AggregateControl, ou se você deixá-lo configurado como zero, os pedidos de agregação armazenados internamente pelo WebSphere MQ nunca serão limpos, a menos que todas as mensagens de resposta sejam retornadas. Esta situação pode conduzir a um acúmulo gradual de mensagens nas filas internas. Defina o tempo limite como um valor maior que zero para assegurar-se de que os pedidos sejam limpos e as filas não acumulem pedidos redundantes. É uma boa prática configurar o valor de tempo limite como um valor alto, por exemplo, 86400 segundos (24 horas), para que as filas limpem as mensagens de agregação antigas, mesmo que os tempos limite não sejam necessários ou esperados.

Os nós de agregação utilizam a expiração de mensagem do WebSphere MQ para gerenciar o tempo limite de mensagens. Para que a expiração de mensagem funcione, os nós de agregação devem procurar as filas de mensagens. Os nós de agregação procuram as filas automaticamente para garantir que as mensagens expiradas sejam processadas.

z/OS platform No z/OS, você pode configurar o WebSphere MQ para executar um processo de varredura que procura as filas em vez dos nós de agregação. Para ativar a varredura, configure a propriedade do gerenciador de filas do intermediário EXPRYINT como um valor de 5 segundos. Se você não definir EXPRYINT, ou defini-lo com um valor superior a 10 segundos, os nós de agregação serão invertidos, passando a procurar as filas de agregação automaticamente.

Conceitos relacionados
Nós do Fluxo de Mensagens
Tarefas relacionadas
Projetando um Fluxo de Mensagens
Definindo o Conteúdo do Fluxo de Mensagens
Configurando Fluxos de Agregação
Referências relacionadas
Nós Internos
Nó AggregateControl
Nó AggregateReply
Nó AggregateRequest
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última atualização : 2009-02-13 16:11:37

ac00660_