There are number of general considerations, such as network and
security settings, that apply when configuring messaging engines that receive
messages.
The configuration of network transport for service integration is managed
through the transport channel service. You can use this service to add, remove,
or modify protocols that can be used to establish connections to an application
server over a network.
You can configure an application server to allow a combination of several
different protocols, that is, a
transport chain, to be used when
communicating with messaging engines hosted by the server. The transport channel
service includes support for:
- TCP
- Secure Sockets Layer (SSL) over a TCP network
- Tunneling through Hyper Text Transfer Protocol (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.
In addition, you can choose to configure one of two different types of
transport chain to be used by WebSphere MQ links and WebSphere MQ client links.
These transport chains support:
- TCP
- Secure Sockets Layer (SSL) over a TCP network
WebSphere MQ queue manager sender channels and WebSphere applications
that use the WebSphere 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 you 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 secure sockets layer (SSL) based
encryption protocol over a TCP network. The default port used by this chain
for the first server on the node is 7286. You should verify that the selected
port is not already used, for example if you are configuring a second server
with the same name as the first server. 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 WebSphere MQ queue manager sender channels and applications using
the WebSphere MQ messaging provider connecting over a TCP network. The default
port used by this chain is 5558, although this can be automatically adjusted
to avoid conflicts.
- InboundSecureMQLink
- Enables WebSphere MQ queue manager sender channels and applications using
the WebSphere MQ messaging provider to establish SSL based encrypted connections
over a TCP network. The default port used by this chain is 5578, although
this is automatically adjusted to avoid conflicts.
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.
You can manage all of these chains through the administrative console by
selecting either or .
You can also use these administrative console panels to define new transport
chains from a set of templates.
Inbound channel chains that are 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 considerations that are taken into account when deciding whether to start
the inbound chains relating to messaging function:
|
Messaging chains |
WebSphere MQ interoperation chains |
SIB service disabled for server |
Not started |
Not started |
SIB service enabled for server and no WebSphere MQ links
or WebSphere MQ client links resources defined |
Started |
Not started |
SIB service enabled and WebSphere MQ links or WebSphere
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 WebSphere MQ related resources, see,
for example, WebSphere MQ link sender channel [Settings].
Note 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 that is 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.
You 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 JMS connection factory [Settings].
This 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.