Oracle Service Bus: Async Publish, Error Handling and Quality Of Service.

Async Invocation Using "Publish"

In proxy service message flow "publish" communication action control is used to invoke service in fire and forget fashion.

It uses asynchronous transport underneath to call target business service. In this case proxy service request continue to execute and does not wait for response or discards the response if it is available.



Error Handling With Publish


Error handling can become an issue especially in case of “publish” action with default quality of service (best effort). With default QOS configuration proxy service execution remains unaware even in a case where target business service is not available.

There is an option to upgrade quality of service from default “best effort” to with “exactly once”.

“Publish” action with “exaclty once” QOS allows to handle error when invocation of the target servers returns error.


Overhead of the “exactly once”


“Publish” with “exactly once” significantly changes execution of the proxy service request. In “Publish with "exactly once" scenario proxy request execution blocks until message is processed completely in target business service. Publish with "exactly once" is architecturally equivalent to synchronous service invocation (using service call out ) and it is no longer a "fire and forget" invocation.

Blocked Proxy Service Execution Thread

-----------------------------
java.net.SocketInputStream.socketRead0(Native Method)
……….
weblogic.net.http.HttpURLConnection.getInputStream(HttpURLConnection.java:359)
…………
com.bea.wli.sb.transports.http.HttpOutboundMessageContext.getResponse(HttpOutboundMessageContext.java:574) com.bea.wli.sb.transports.http.HttpOutboundMessageContext.send(HttpOutboundMessageContext.java:327) com.bea.wli.sb.transports.http.HttpTransportProvider.sendMessageAsync(HttpTransportProvider.j
$Proxy49.sendMessageAsync(Unknown Source)
…….
com.bea.wli.sb.transports.LoadBalanceFailoverListener.sendMessageToServiceAsync(LoadBalanceFailoverListener.java:543)
………
com.bea.wli.sb.pipeline.PipelineContextImpl.doDispatch(PipelineContextImpl.java:583)
com.bea.wli.sb.pipeline.PipelineContextImpl.dispatchSync(PipelineContextImpl.java:466)
stages.publish.runtime.PublishRuntimeStep.processMessage(PublishRuntimeStep.java:137)
...........
----------------------------------------------------------

Architectural Trade-Off

Key advantage of the asynchronous invocation is optimized thread resources utilization. Generally async “publish” invocation approach is used for invocation of the auxiliary business services where unavailability of the auxiliary business service does not warrant interruption in proxy service execution. Many times during implementation of the proxy service, QOS is upgraded to “exactly once” to achieve better error handling while forgetting original async architectural intent. In this scenarios it is recommended to rely on other monitoring infrastructure to detect unavailability of the downstream auxiliary service rather than introducing design time error handling through “exactly-once” which has significant performance overhead.