Carrying Messages

A transport is responsible for carrying messages that are in a specific format. The ESB Profile of WSO2 Enterprise Integrator supports all the widely-used transports including HTTP/s, JMS, and VFS, and domain-specific transports like FIX. All ESB transports are directly or indirectly based on the Apache Axis2 transports framework. This framework provides two main interfaces that each transport implementation must implement.

org.apache.axis2.transport.TransportListener - Implementations of this interface specify how incoming messages are received and processed before handing them over to the Axis2 engine for further processing.
org.apache.axis2.transport.TransportSender - Implementations of this interface specify how a message can be sent out from the Axis2 engine.

Each transport implementation has to implement the above two interfaces, and thereby, each transport generally contains a transport receiver/listener implementation and a transport sender implementation. You configure, enable, and manage transport listeners and senders independently of each other. For example, you could enable just the JMS transport sender without having to enable the JMS transport listener.

Configuring transports

The following sections describe how to globally configure ESB Transports.

Configuring transports globally

Configuring using the axis2.xml file

The <transportReceiver> and <transportSender> elements in the <EI_HOME>/conf/axis2 /axis2.xml file are used to configure transport receivers and senders respectively. Some transports are already configured and enabled by default, including the HTTP and HTTPS transports.

You can send and receive RESTful messages through the ESB profile using the HTTP and HTTPS transports. However, other transports such as the Local transport does not support RESTful messages.
The HTTP and HTTPS transports are required to start the Management Console of the ESB Profile of WSO2 EI, and for other administrative functions. Therefore, do not disable these transports.
WSO2 products do not use the HTTP/S servlet transport configurations that are in the axis2.xml file. Instead, they use Tomcat-level servlet transport configurations in the <EI_HOME>/conf/tomcat/catalina-server.xml file. However, the ESB Profile uses the HTTP Pass Through transport configurations in the axis2.xml file.

Following is an example of the JMS transport receiver configuration in the axis2.xml file.

<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
        <parameter name="myTopicConnectionFactory">
            <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
            <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
            <parameter name="transport.jms.ConnectionFactoryJNDIName">TopicConnectionFactory</parameter>
        </parameter>

        <parameter name="myQueueConnectionFactory">
            <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
            <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
            <parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>
        </parameter>

        <parameter name="default">
            <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>
            <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>
            <parameter name="transport.jms.ConnectionFactoryJNDIName">QueueConnectionFactory</parameter>
        </parameter>
</transportReceiver>

<transportReceiver> has the following attributes and elements:

name - A mandatory attribute which indicates a unique name for the transport receiver.
class - A mandatory attribute which indicates the transport receiver implementation class.
parameters - Configuration parameters for the transport receiver, such as the port in the example above. Parameters should be included as child elements of the <transportReceiver> element.

Similarly <transportSender> elements can be used to configure and enable transport senders. Following is the Pass-through transport sender configuration that comes by default:

<transportSender name="http" class="org.apache.synapse.transport.passthru.PassThroughHttpSender">
      <parameter name="non-blocking" locked="false">true</parameter>
</transportSender>

Having <transportReceiver> and <transportSender> elements enabled in the axis2.xml file causes those transports to be loaded and activated during server startup. Therefore, any dependency JARs required by those transport implementations must be included in the server classpath (such as the <EI_HOME>/dropins directory) to prevent the server from running into exceptions at startup. Additionally, an inaccurate transport configuration (such as a wrong parameter value) might cause the transport not to be enabled properly.

The axis2.xml file will be loaded into memory at server startup only. Therefore, any changes made to the file while the server is running have no effect until you restart the server.

Configuring using the catalina-server.xml file in the standalone mode

In addition to configuring transports in the axis2.xml file, you can globally configure transport receivers using the <EI_HOME>/conf/tomcat/catalina-server.xml file when the server is running in the standalone mode (that is, the server is not running in a servlet container). By default, you will find the HTTP and HTTPS servlet transports configured in this file. The XML syntax to configure transports in the catalina-server.xml file is similar to the syntax used in the axis2.xml file, except the <transport> element takes the place of the <transportReceiver> element. The default HTTP receiver configuration specified in the catalina-server.xml file is as follows:

<transport name="http" class="org.wso2.carbon.server.transports.http.HttpTransport">
      <parameter name="port">9763</parameter>
      <parameter name="maxHttpHeaderSize">8192</parameter>
      <parameter name="maxThreads">150</parameter>
      <parameter name="minSpareThreads">25</parameter>
      <parameter name="maxSpareThreads">75</parameter>
      <parameter name="enableLookups">false</parameter>
      <parameter name="disableUploadTimeout">false</parameter>
      <parameter name="clientAuth">false</parameter>
      <parameter name="maxKeepAliveRequests">100</parameter>
      <parameter name="acceptCount">100</parameter>
      <parameter name="compression">force</parameter>
      <parameter name="compressionMinSize">2048</parameter>
      <parameter name="noCompressionUserAgents">gozilla, traviata</parameter>
      <parameter name="compressableMimeType">
          text/html,text/javascript,application/x-javascript,application/javascript,application/xml,text/css,application/xslt+xml,text/xsl,image/gif,image/jpg,image/jpeg
      </parameter>
  </transport>

Transport receivers configured in catalina-server.xml will be loaded through a special Transport Manager implementation. Therefore, the classes specified in the <transport> element must implement the interface org.wso2.carbon.server.transports.Transport. Currently, only the default servlet transports can be configured from the catalina-server.xml file.

Configuring transports at the service level

Also, you can configure transports at the service level. Transports configured at the service level affect individual services and not all the services deployed. Some transport implementations such as JMS and FIX mandate configuring certain transport parameters at the service level.

To configure a transport at the service level, edit the service's XML file or specify the service-level transport parameters in the proxy service configuration in the Management Console. For more information, see Working with Services.

For information on configuring transport-level security, see Configuring Transport Level Security in the WSO2 Administration Guide.