Inbound transport options
We use the transport channel service to add, remove, or modify protocols (transport chains) used to establish connections with messaging engines hosted on servers over a network.
- TCP
- SSL over a TCP network.
- Tunneling through HTTP connections.
- Tunneling through HTTPS (secure HTTP) connections.
Messaging engine clients such as JMS applications running in a client container and other messaging engines can communicate with a messaging engine using these transport chains.
We can also configure one of two different types of transport chain to be used by IBM MQ links and IBM MQ client links. These transport chains support:
- TCP
- SSL over a TCP network.
IBM MQ queue manager sender channels and WebSphere Application Server applications that use the IBM MQ messaging provider can communicate with a messaging engine using either of these transport chain types.
When a server is created using the default template, the following transport chains are automatically created to facilitate communication with messaging engines that are hosted by the application server:
- InboundBasicMessaging
- Allows communication using the TCP protocol. The default port used by this chain for the first server on the node is 7276. Check the selected port is not already used, for example if we are creating a second server on a particular node. Messaging engines hosted in other application servers and JMS applications running in a client container can communicate with the messaging engines of the server using this transport chain.
- InboundSecureMessaging
- Provides secure communication using the SSL based encryption protocol over a TCP network. The default port used by this chain for the first server on the node is 7286. Check the selected port is not already used, for example if we are creating a second server on a particular node. The SSL configuration information for this chain is based on the default SSL repertoire for the application server. Messaging engines hosted in other application servers and JMS applications running in the client container can communicate using this transport chain.
- InboundBasicMQLink
- Supports IBM MQ queue manager sender channels and applications using the IBM MQ messaging provider connecting over a TCP network. The default port used by this chain is 5558, this can be automatically adjusted to avoid conflicts.
- InboundSecureMQLink
- Enable IBM MQ queue manager sender channels and applications using the IBM MQ messaging provider to establish SSL based encrypted connections over a TCP network. The default port used by this chain is 5578, this is automatically adjusted to avoid conflicts.
- soReuseAddr
- Allows the WAS administrator to control bind behavior. When the WAS is restarted, if the inbound TCP channels have problems trying to bind the listening socket, errors are printed into the SystemOut file until either the bind is successful or the number of allowed bind attempts has been passed. This custom property helps to avoid repeated error messages during the bind process.
By default all of these transport chains are configured to use the SIBFAPInboundThreadPool thread pool to handle the data they receive. No reason has been identified for it being necessary to change the minimum or maximum size of this thread pool.
We can manage these chains in the administrative console by selecting one of the following:
- Servers -> Server Types -> WebSphere application servers -> server -> [Server messaging] Messaging engine inbound transports
- Servers -> Server Types -> WebSphere application servers -> server -> [Server messaging] IBM MQ link inbound transports
We can also use these administrative console panels to define new transport chains from a set of templates.
Inbound channel chains used for communicating with messaging engines are usually started when the application server that hosts them is started. This can occur even if the application server does not host any active messaging engines. When an inbound chain starts, it binds to the TCP port that it has been assigned and accepts network connections. The following table describes the circumstances under which the inbound chains relating to messaging function are started:
Messaging chains IBM MQ interoperation chains SIB service disabled for server Not started Not started SIB service enabled for server and no IBM MQ links or IBM MQ client links resources defined Started Not started SIB service enabled and IBM MQ links or IBM MQ client links resources defined Started Started For more information about enabling or disabling the SIB service, see SIB Service Detail Form.
For more information about defining IBM MQ related resources, see, for example, IBM MQ link sender channel [Settings].
that there is no affinity between a particular inbound channel chain and a messaging engine. Any messaging engine active on a server can be contacted by any inbound channel chain running. This has important implications when attempting to secure network communications: communication with the messaging engines that are active in an application server is only as secure as the least secure messaging chain active on the server within the same category, that is, a messaging chain or MQ interop chain.
We can specify inbound transport chains by name in the following places:
- The Inter-engine transport chain field in the Buses [Settings]. This specifies the chain used when establishing connections between nodes in the same cell.
- The Target inbound transport chain field in the Default messaging provider unified connection factory [Settings]. Specifies the transport chain name to use when establishing a network connection for use by a JMS application when connecting to a remote messaging engine.
Related:
Messaging engine communication Configure transport chains SSL inbound channel Transport chains collection TCP transport channel custom properties Permitted transports [Collection] Add a transport to the list of permitted transports [Settings]