É possível fazer solicitações de HTTP e receber uma resposta de forma assíncrona usando os nós HTTPAsyncRequest e HTTPAsyncResponse, ou os nós SOAPAsyncRequest e SOAPAsyncResponse, em seu fluxo de mensagens.
O nó
SOAPAsyncRequest suporta dois métodos de solicitações assíncronas ao usar o transporte HTTP:
- Usando WS-Addressing para direcionar a resposta para o nó SOAPAsyncResponse com par. O nó SOAPAsyncRequest aguarda pelo
reconhecimento de HTTP 202 antes de continuar com o fluxo de mensagens e o nó
SOAPAsyncRequest será bloqueado se o
reconhecimento não for recebido. Uma nova conexão HTTP é feita pelo servidor de backend para responder ao nó SOAPAsyncResponse. Esse não é o comportamento padrão.
- Usando Solicitação-resposta Assíncrona de HTTP. Quando a propriedade SOAPAsyncRequest Usar Solicitação-resposta Assíncrona de HTTP for selecionada, o nó SOAPAsyncRequest passa o soquete de HTTP para o nó SOAPAsyncResponse com par para permitir que o servidor
de backend responda usando o mesmo soquete. Quando essa opção estiver
selecionada, os cabeçalhos WS-Addressing serão enviados, mas não precisarão ser entendidos pelo
servidor de backend. Os cabeçalhos WS-Addressing não são marcados como mustUnderstand e o cabeçalho replyTo é configurado como anônimo. O nó usa portanto manipulação de soquete de HTTP assíncrono em vez de
WS-Addressing para fazer solicitações de HTTP e receber uma resposta assíncrona.
O nó
HTTPAsyncRequest sempre usa manipulação de soquete de HTTP assíncrona para fazer solicitações e receber respostas assíncronas.
Os nós de solicitação assíncrona retornará o controle ao fluxo sem esperar por uma resposta.
Essa ação libera o encadeamento de solicitação para manipular pedidos adicionais, enquanto a resposta é manipulada pelo nó de resposta com par em um encadeamento diferente e em uma nova transação. O nó de resposta pode estar em um fluxo de mensagens separado, mas deve estar no mesmo servidor de integração que seu nó de solicitação com par.
O comportamento de solicitação-resposta assíncrona de HTTP é assíncrono apenas porque o WebSphere Message Broker trata a solicitação e a resposta como tal, permitindo
que o fluxo de mensagens recupere a próxima mensagem sem aguardar pela resposta da solicitação assíncrona. O servidor de backend vê a solicitação-resposta como uma solicitação de HTTP síncrona típica.
Cenários
Talvez você queira usar solicitação-resposta assíncrona de HTTP nas seguintes situações:
- Ao interagir com um servidor de backend que tenha uma latência alta, o uso de solicitações de HTTP síncronas pode resultar em várias solicitações pendentes o que exigirá uma grande quantidade de encadeamentos para fazer conexões simultâneas suficientes para o servidor de backend. Usar manipulação de soquete de HTTP assíncrona permite que a resposta seja separada da solicitação.
- Usar solicitação-resposta assíncrona de HTTP no SOAPAsyncRequest é uma alternativa ao uso de WS-Addressing com um cabeçalho replyTo não anônimo.
Para obter informações sobre como usar solicitação-resposta assíncrona de HTTP com o nó
SOAPAsyncRequest,
consulte
Escolhendo Comportamento Assíncrono para o Nó SOAPAsyncRequest.
Limitações
Ao usar o nó
HTTPAsyncRequest, ou o nó
SOAPAsyncRequest com solicitação-resposta assíncrona de
HTTP, as seguintes limitações se aplicam:
- Redirecionamento não é suportado. As mensagens com um código de status de redirecionamento
(3xx) são tratadas como um erro e a resposta é roteada para o terminal de Erro do nó de resposta enquanto segue as propriedades especificadas na guia Erro.
- WS-RM não é compatível com o uso de solicitação-resposta assíncrona de HTTP.