LibraryLink ToToggle FramesPrintFeedback

Using the HTTP Transport in Decoupled Mode

In normal HTTP request/response scenarios, the request and the response are sent using the same HTTP connection. The service provider processes the request and responds with a response containing the appropriate HTTP status code and the contents of the response. In the case of a successful request, the HTTP status code is set to 200.

In some instances, such as when using WS-RM or when requests take an extended period of time to execute, it makes sense to decouple the request and response message. In this case the service providers sends the consumer a 202 Accepted response to the consumer over the back-channel of the HTTP connection on which the request was received. It then processes the request and sends the response back to the consumer using a new decoupled server->client HTTP connection. The consumer runtime receives the incoming response and correlates it with the appropriate request before returning to the application code.

Using the HTTP transport in decoupled mode requires that you do the following:

  1. Configure the consumer to use WS-Addressing.

    See Configuring an endpoint to use WS-Addressing.

  2. Configure the consumer to use a decoupled endpoint.

    See Configuring the consumer.

  3. Configure any service providers that the consumer interacts with to use WS-Addressing.

    See Configuring an endpoint to use WS-Addressing.

Specify that the consumer and any service provider with which the consumer interacts use WS-Addressing.

You can specify that an endpoint uses WS-Addressing in one of two ways:


The WS-Addressing policy supersedes the wswa:UsingAddressing WSDL element.

Configure the consumer endpoint to use a decoupled endpoint using the DecoupledEndpoint attribute of the http-conf:conduit element.

Example 2.13 shows the configuration for setting up the endpoint defined in Example 2.11 to use use a decoupled endpoint. The consumer now receives all responses at

Using the HTTP transport in decoupled mode adds extra layers of complexity to the processing of HTTP messages. While the added complexity is transparent to the implementation level code in an application, it might be important to understand what happens for debugging reasons.

Figure 2.1 shows the flow of messages when using HTTP in decoupled mode.

A request starts the following process:

  1. The consumer implementation invokes an operation and a request message is generated.

  2. The WS-Addressing layer adds the WS-A headers to the message.

    When a decoupled endpoint is specified in the consumer's configuration, the address of the decoupled endpoint is placed in the WS-A ReplyTo header.

  3. The message is sent to the service provider.

  4. The service provider receives the message.

  5. The request message from the consumer is dispatched to the provider's WS-A layer.

  6. Because the WS-A ReplyTo header is not set to anonymous, the provider sends back a message with the HTTP status code set to 202, acknowledging that the request has been received.

  7. The HTTP layer sends a 202 Accepted message back to the consumer using the original connection's back-channel.

  8. The consumer receives the 202 Accepted reply on the back-channel of the HTTP connection used to send the original message.

    When the consumer receives the 202 Accepted reply, the HTTP connection closes.

  9. The request is passed to the service provider's implementation where the request is processed.

  10. When the response is ready, it is dispatched to the WS-A layer.

  11. The WS-A layer adds the WS-Addressing headers to the response message.

  12. The HTTP transport sends the response to the consumer's decoupled endpoint.

  13. The consumer's decoupled endpoint receives the response from the service provider.

  14. The response is dispatched to the consumer's WS-A layer where it is correlated to the proper request using the WS-A RelatesTo header.

  15. The correlated response is returned to the client implementation and the invoking call is unblocked.