Friday, 26 April 2013

Understanding Oracle Service Bus Thread model - Ensures Scalablity

1. Basic Thread Model


An Http Servlet  or a JMS Message Driven Bean(front end artifact) gets the inbound message, which is routed to Outbound endpoint and the thread is released.


Basic OSB Thread Model











An Asynchronous Callback response is received later at the outbound endpoint, packaged and handed to the Oracle Service Bus pipeline. Later, the pipeline notifies the inbound endpoint that the response is ready to be sent to the client. This processing is scalable because a thread is only tied up as long as it is needed.


Oracle Service Bus Thread Model is a scalable model and comprises of:

Inbound Request Message Thread

  • An Inbound message received by a Servlet or Message Driven Bean

  • Transport endpoint packages the message in TransportMessageContext object and passes to the pipeline.

  • Request pipeline performs request pipeline actions configured for the proxy

  • In the same (request) thread, Oracle Service Bus runtime calls on the  outbound transport endpoint

    Request and Response Message Thread in OSB

     

 

 

 

 

 

 

 

 

 

Outbound Response Message Thread

  • In a new thread(response thread) the callback esponse message is packaged into a TransportMessageContext object and delivered back to Oracle Service Bus runtime.

  • Response pipeline performs response pipeline action (if any).

  • Oracle Service Bus runtime calls on the InboundTransportMessageContext object to notify it  to send the response back to the original caller

 Different Work Manager for Biz and Proxy Service

OSB allows you to assign different Work Managers and hence different thread pools to each Proxy Service and Business Service. This architecture ensures while waiting for a response from a business service there are no threads in use.

2. Do Nothing Route Thread Model ( Special Case)

      When there is no route node?  
  •  Oracle Service Bus just echoes the Request message as a Response message.
  •  It still uses a separate thread for the response, response thread in this case uses Default Work Manger.
 
 

3. Service Callout Threading Model 

  • Service Callout to a Business Service from within a pipeline.
  • Target Business Service is called using the pipeline thread but the response is also handled by the pipeline thread.
  • Calling thread is suspended after sending the request, but unlike the Route Node case the thread is not released, it waits for the response.
  • The socket muxer uses the Business Service Work Manager to allocate a thread to process the response, 
  • Getting the response and notifying the blocked pipeline thread that the response is available.  
  • The original pipeline thread can then continue to process the response.

 Note: Make sure that any Business Services used by a Callout in a pipeline use a different Work Manager than the pipeline itself.

4. Proxy Chaining Thread Model

  • Route node is calling a Proxy Service rather than a Business Service.
  • The original Work Manager is used for both request pipelines.  
  • Similarly the response pipeline uses the Work Manager associated with the ultimate Business Service invoked via a Route Node.  

No comments:

Post a Comment