WSO2 ESB Inbound Endpoint

Inbound Endpoint is an endpoint which resides in server side of the ESB. Those are introduced to achieve  some of the main features like multi tenancy support for some protocols like JMS, by passing axis2 layer in  Inbound side,deploying and undeploying inbound endpoints without server restarting. 

 Basically there are two  behaviours introduced. Selection of the behaviour is done according to protocol.

• Polling behaviour
• Listening behaviour    
  

Polling behaviour

       This behaviour is in  JMS, File and Generic Inbound Endpoints. Basically it polls periodically for data with some Conditions and if Conditions is ok then injects that data to given sequence. for example in JMS inbound Endpoint it checks for JMS Queue periodically whether the data is available if so then take that message and inject it to given sequence.So this kind of inbound endpoints have one way operation. It does not require a result so in nature these are asynchronous.

Listening behaviour     

      This  behaviour is in HTTP and CXF-RS inbound endpoints. Basically listener is started in given port and it listens for requests coming to that port. When request is available it injects that request to the given sequence.Here those have two way operation and in nature those are synchronous.

Inbound Endpoint Configuration  

<inboundEndpoint xmlns="http://ws.apache.org/ns/synapse"

                name="feedep"

                sequence="TestIn"

                onError="fault"

                protocol="http"

                suspend="false">

  <parameters>

     <parameter name="inbound.http.port">8085</parameter>

  </parameters>

</inboundEndpoint>

According to the above configuration generic parameters for  inbound endpoints are added as attributes in inboundEndpoint element and protocol specific  parameters are given in the parameters element. 
 

Thread Pools in InboundEndpoint

    We need threadpool  to execute message injectors to the sequence. Message Injectors are handle by thread pool which avoids blocking in the message consumers from the source or listeners for the source.

There are three options that can be taken.

• Per inbound thread pool.
• Protocol specific thread pool.
• One thread pool for all inbound endpoints.

currently we are having thread pool per inbound and we need to make it configurable.

Multi Tenancy in InboundEndpoint                   

    Multi Tenancy means more tenants are operated in single physical location with logically separated manner. So each tenant can have more inbound endpoints. so when introducing this there are major problems that we need to solved. Basically one way protocols like JMS, File and Generic are run top of the task since tasks are handling multi tenancy  we don't need to separately handle it.

  But in Listening  endpoints like Http and CXF-RS need to handle multi tenancy. So basic problem that we faced is port sharing and  tenant unloading. we need to do port sharing between tenants because number of ports are limited.When tenant loading and unloading synapse environment also get loaded and unloaded. So we keep common handler and Listener always running and in runtime we get the synapse environment and get inbound endpoints through it and do the relevant operations.

Clustering    

  This is achieved by using hazelcast framework and distributed locks.  

Reference

• Isuru's Computer Lab
• ESB Documentation