An inbound endpoint is a message entry point that can inject messages directly from the transport layer to the mediation layer, without going through the Axis engine. The following diagram illustrates the inbound endpoint architecture.
Out of the existing transports only the HTTP transport supports multi-tenancy, this is one limitation that is overcome with the introduction of the inbound architecture. Another limitation when it comes to conventional Axis2 based transports is that the transports do not support dynamic configurations. With inbound endpoints, it is possible to create inbound messaging channels dynamically, and there is also built-in cluster coordination as well as multi-tenancy support for all transports.
Based on the protocol, the behaviour of an inbound endpoint can either be listening, polling or event-based.
For detailed information on listening, polling and event-based inbound endpoints see the following topics:
For information on how to create a custom inbound endpoint based on your requirement, see Custom Inbound Endpoint.
Following is a sample inbound endpoint configuration:
In an inbound endpoint configuration, the common inbound endpoint parameters are specified as attributes of the
<inboundEndpoint> element whereas the protocol specific parameters are specified as
Common inbound endpoint parameters
The following parameters are common to all inbound endpoints:
|sequential||The behavior when executing the given sequence. |
When set as
|Yes||true or false||true|
|suspend||When set to ||Yes||true or false||false|
Specifying inbound endpoint parameters as registry values
Other than specifying parameter values inline, you can also specify parameter values as registry entries. The advantage of specifying a parameter value as a registry entry is that the same inbound endpoint configuration can be used in different environments simply by changing the registry entry value.
If you need to provide the registry entry value via the Management Console, specify it as