There are several factors that affect how JMS applications connect to a service integration bus, so that they can use resources provided by the bus.
To connect to a service integration bus, an application actually connects to a messaging engine on the bus.
By default, the environment automatically connects applications to an available messaging engine on the bus. However you can specify extra configuration details to influence the connection process; for example to identify special bootstrap servers, or to limit connection to a subgroup of available messaging engines, or to improve availability or performance, or to ensure sequential processing of messages received.
Applications that are running in an application server are directed by the WebSphere® Application Server environment to an available messaging engine.
If the messaging engine is found in the same server, a connection is created that provides the application with the fastest available connection to a messaging engine. Otherwise, if a messaging engine is found in another process - on the same or a different host - a remote connection is made. If no suitable messaging engine is found the application fails to connect to the bus.
The figure shows two applications running in application servers. Application X on server3 has connected to the messaging engine running in the same server. Application Y on server1 has connected to a messaging engine that is running in the same bus but on a different server and host, because server1 does not have a suitable messaging engine.
Client applications running outside an application server (for example, running in a client container or outside the WebSphere Application Server environment) cannot locate a suitable messaging engine themselves and must complete a bootstrap process through a bootstrap server. A bootstrap server is an application server that is running the SIBService service, but is not necessarily running any messaging engines. The bootstrap server selects a messaging engine that is running in an application server that supports the required target transport chain.
This figure shows a client application running outside an application server. To connect to a messaging engine, the application connects first to a bootstrap server. The bootstrap server selects a messaging engine then tells the client application to connect to that messaging engine.
A bootstrap server uses a specific port and bootstrap transport chain, which with the host name form the endpoint address of the bootstrap server.
The properties of a JMS connection factory used by a client application control the selection of a suitable messaging engine and how the client connects to the selected messaging engine. By default, a connection factory expects to use a bootstrap server that has an endpoint address of localhost:7276:BootstrapBasicMessaging. That is: the client application expects to use a bootstrap server that is on the same host as the client, and that uses port 7276 and the predefined bootstrap transport chain called BootstrapBasicMessaging.
When you create an application server, it is automatically assigned a unique non-secure bootstrap port, SIB_ENDPOINT_ADDRESS, and a secure bootstrap port, SIB_ENDPOINT_SECURE_ADDRESS. If you want to use an application server as a bootstrap server, and the server has been assigned a non-secure port other than 7276, or you want to use the secure port, then you must specify the endpoint address of the server on the Provider endpoints property of the connection factory.
The endpoint addresses for bootstrap servers must be specified in every connection factory that is used by applications outside of an application server. To avoid having to specify a long list of bootstrap servers, you can provide a few highly-available servers as dedicated bootstrap servers. Then you only have to specify a short list of bootstrap servers on each connection factory.
In both cases (that is, an application running in an application server and an application running outside an application server) you can restrict the range of messaging engines available for connection, to a subgroup of those available in the service integration bus. You do this by configuring the following connection properties of the connection factory or activation specification:
Before the connection proximity search is performed to select a suitable messaging engine, the set of messaging engines that are members of the specified target group are selected. The connection proximity search is then restricted to these messaging engines. If a target group is not specified (the default), then all messaging engines in the bus are considered during the connection proximity search.
For example, if the Target type property is set to Bus member name, the Target property specifies the name of the bus member from which suitable messaging engines can be chosen.
The name of the messaging engine inbound transport chain that the application should target when connecting to a messaging engine in a separate process to the application.
These transport chains specify the communication protocols that can be used to communicate with the application server to which the client application is connected. If a messaging engine in another process is chosen, a connection can be made only if the messaging engine is in a server that runs the specified inbound transport chain.
A suitable messaging engine in the same server is selected ahead of a suitable messaging engine in the same host, and in turn ahead of a suitable messaging engine in another host.
A suitable messaging engine in the same server is selected ahead of a suitable messaging engine in the same host, and in turn ahead of a suitable messaging engine in another host.
This option should be used only in WebSphere Application Server environments that support server clusters.