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:
Table 1. The affects of starting the inbound chain on a message
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.