Using HTTP asynchronous request-response
You can make HTTP requests and
receive a response asynchronously using the HTTPAsyncRequest and HTTPAsyncResponse nodes, or
the SOAPAsyncRequest and SOAPAsyncResponse nodes, in
your message flow.
The
SOAPAsyncRequest node
supports two methods of asynchronous requests when using HTTP transport:
- Using WS-Addressing to direct the response to the paired SOAPAsyncResponse node. The SOAPAsyncRequest node waits
for the HTTP 202 acknowledgment before continuing with the message
flow, and the SOAPAsyncRequest node
blocks if the acknowledgment is not received. A new HTTP connection
is made by the backend server to reply to the SOAPAsyncResponse node. This
is the default behavior.
- Using HTTP asynchronous request-response. When the SOAPAsyncRequest property Use
HTTP asynchronous request-response is selected, the SOAPAsyncRequest node passes
the HTTP socket to the paired SOAPAsyncResponse node to allow
the backend server to reply using the same socket. When this option
is selected, WS-Addressing headers are sent, but are not required
to be understood by the backend server. The WS-Addressing headers
are not marked as mustUnderstand, and the replyTo header is set to
anonymous. The node therefore uses asynchronous HTTP socket handling
instead of WS-Addressing to make HTTP requests and receive an asynchronous
response.
The
HTTPAsyncRequest node
always uses asynchronous HTTP socket handling to make asynchronous
requests and responses.
The asynchronous request nodes return control to the flow without waiting for a response. This
action frees the request thread to handle further requests, while the response is
handled by the paired response node on a different thread and in a new transaction. The
response node can be in a separate message flow, but it must be in the same integration
server as its paired request node.
The HTTP asynchronous request-response behavior is asynchronous
only because IBM® Integration Bus treats the
request and the response as such, enabling the message flow to retrieve
the next message without waiting for the response from the asynchronous
request. The backend server sees the request-response as a typical
synchronous HTTP request.
Scenarios
You might want to use HTTP asynchronous
request-response in the following situations:
- When interacting with a backend server that has a high latency,
using synchronous HTTP requests might result in many outstanding requests
which require large numbers of threads to make enough simultaneous
connections to the backend server. Using asynchronous HTTP socket
handling instead allows the response to be decoupled from the request.
- Using HTTP asynchronous request-response in the SOAPAsyncRequest is an alternative
to using WS-Addressing with a non-anonymous replyTo header.
For information about using HTTP asynchronous request-response
with the
SOAPAsyncRequest node,
see
Choosing asynchronous behavior for the SOAPAsyncRequest node.
Limitations
When using the
HTTPAsyncRequest node, or the
SOAPAsyncRequest node with
HTTP asynchronous request-response, the following limitations apply:
- Redirection is not supported. Messages with a redirection status
code (3xx) are treated as an error, and the response is routed to
the Error terminal of the response node while following the properties
specified on the Error tab.
- WS-RM is not compatible with using HTTP asynchronous request-response.