Puede realizar solicitudes HTTP y recibir
una respuesta asíncronamente utilizando los nodos
HTTPAsyncRequest y
HTTPAsyncResponse o los nodos
SOAPAsyncRequest y
SOAPAsyncResponse,
en el flujo de mensajes.
El nodo
SOAPAsyncRequest soporta dos
métodos de solicitudes asíncronas cuando se utiliza el transporte HTTP:
- Utilización de WS-Addressing para dirigir la respuesta al nodo
SOAPAsyncResponse emparejado. El nodo
SOAPAsyncRequest espera el acuse de recibo
de HTTP 202 antes de continuar con el flujo de mensajes y el nodo
SOAPAsyncRequest se bloquea si no se recibe
el acuse de recibo. El servidor de fondo realiza una nueva conexión HTTP
para responder al nodo SOAPAsyncResponse. Éste es el comportamiento predeterminado.
- Utilización de solicitud-respuesta asíncrona HTTP. Cuando se selecciona la
propiedad de SOAPAsyncRequest
Utilizar solicitud-respuesta asíncrona HTTP,
el nodo SOAPAsyncRequest pasa el socket HTTP
al nodo SOAPAsyncResponse emparejado
para permitir que el servidor de fondo responda utilizando el mismo socket. Cuando se
selecciona esta opción, las cabeceras de WS-Addressing se envían, pero es necesario
que el servidor de fondo las comprenda. Las cabeceras WS-Addressing no se marcan
como mustUnderstand y la cabecera replyTo se establece en anónima. Por consiguiente, el
nodo utiliza el manejo de socket HTTP asíncrono en lugar de WS-Addressing para realizar
solicitudes HTTP y recibir una respuesta asíncrona.
El nodo
HTTPAsyncRequest utiliza siempre
el manejo de socket HTTP asíncrono para realizar solicitudes y respuestas asíncronas.
Los nodos de solicitud asíncrona devuelven el control al flujo sin esperar una
respuesta. Esta acción libera la hebra de solicitud para manejar solicitudes
adicionales, mientras que la respuesta es manejada por el nodo de respuesta
emparejado en una hebra diferente y en una nueva transacción. El nodo de respuesta
puede estar en un flujo de mensajes separado, pero debe estar en el mismo servidor
de integración que el nodo de solicitud emparejado.
El comportamiento de solicitud-respuesta asíncrona HTTP es asíncrono
sólo porque WebSphere Message Broker trata la
solicitud y la respuesta como tales, permitiendo que el flujo de mensajes recupere
el mensaje siguiente sin esperar la respuesta de la solicitud asíncrona. El
servidor de fondo ve la solicitud-respuesta como una solicitud HTTP síncrona típica.
Escenarios
Es aconsejable que utilice la solicitud-respuesta
asíncrona HTTP en las situaciones siguientes:
- Cuando interaccione con un servidor de fondo que tiene una alta latencia, el uso de
solicitudes HTTP síncronas puede producir muchas solicitudes pendientes que
requieren un gran número de hebras para realizar suficientes conexiones simultáneas
al servidor de fondo. Si en lugar de ello se utiliza el manejo del socket HTTP asíncrono,
la respuesta se puede desacoplar de la solicitud.
- La utilización de la solicitud-respuesta asíncrona HTTP en el
SOAPAsyncRequest es una alternativa
a la utilización de WS-Addressing con una cabecera replyTo no anónimas.
Para
obtener información sobre la utilización de solicitud-respuesta HTTP asíncrona con
el nodo
SOAPAsyncRequest,
consulte
Elección del comportamiento asíncrono para el nodo SOAPAsyncRequest.
Limitaciones
Cuando se utiliza el nodo
HTTPAsyncRequest o el nodo
SOAPAsyncRequest con la solicitud-respuesta
HTTP asíncrona, se aplican las limitaciones siguientes:
- No se soporta la redirección. Los mensajes con un código de estado de redirección (3xx)
se tratan como un error y la respuesta se direcciona al terminal Error
del nodo de respuesta mientras sigue las propiedades especificadas en el separador Error.
- WS-RM no es compatible con la utilización de solicitud-respuesta HTTP asíncrona.