Configuring a connection to a non-default bootstrap server
A bootstrap server is an application server running in the same cell, specifically the same core group, as the service integration bus.
About this task
To use JMS destinations of the default messaging provider, an application or message-driven bean connects to a messaging engine on the target service integration bus on which the destinations are assigned. For example, a JMS queue is assigned to a queue destination on a service integration bus.
Applications that are running in a server that is part of the same cell as the service integration bus can usually connect to a messaging engine on that bus without requiring provider endpoints to be configured. If the cell has been divided into two core groups, each defined with its own policies, client applications that are running in a client container and client applications that are running outside the WebSphere® Application Server environment, cannot automatically locate the required service integration bus so that, unless a core group bridge has been configured between the core groups in the same cell, you must configure one or more provider endpoints. Similarly, unless a core group bridge has been established between the two cells, an application that is running on a server in one cell cannot connect to a bus in another cell without the configuration of provider endpoints.
In the scenarios where provider endpoints are required, the clients or the servers in another bus must complete a bootstrap process through a bootstrap server. The bootstrap server does not have to be a member of the service integration bus, and it does not have to contain any messaging engines. For the application to locate the required bootstrap server, you must configure the provider endpoint property of the JMS connection factory or JMS activation specification used by the client application. When the bootstrap server receives the client request, it selects a messaging engine that matches the criteria specified by the connection factory or activation specification, for example the target transport chain, target group, or connection proximity. It returns the location information for this messaging engine to the client, and the client creates a new connection to the target messaging engine, if necessary.
The following 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.
The following figure shows a message-driven bean running in an application server that is in a different cell to the bus that the message-driven bean needs to be connected to in order to receive messages.
To connect to a messaging engine, the message-driven bean connects first to a bootstrap server. The bootstrap server selects a messaging engine then tells the message-driven bean to connect to that messaging engine.
- The host name of the host on which the bootstrap server is running
- A specific port that is either SIB_END_POINT or, if security is enabled, SIB_ENDPOINT_SECURE_ADDRESS
- A bootstrap transport chain
JMS connection factory properties control how an application connects to a messaging engine, and which messaging engine is selected. If you deploy the application to an application server on which the service integration bus (SIB) service is enabled, the system uses the SIB service to locate a messaging engine that matches the connection factory criteria. The SIB service is aware of all the messaging engines running on servers in the core group of which the application server to which the application is deployed is a member.
- The application is running as a client application outside of an application server.
- No SIB service is running in the application server to which the application is deployed.
- The SIB service cannot find a suitable messaging engine for the application to connect to.
- If the application does not supply a password, a default endpoint address of localhost:7276:BootstrapBasicMessaging is used. That is, by default, applications try to use a bootstrap server on the same host as the client, using port 7276 and the predefined bootstrap transport chain called BootstrapBasicMessaging.
- If the application does supply a password, the default secure port of 7286 and the transport chain BootstrapSecureMessaging is used to prevent the transmission of an unencrypted password to the server.
If you want an application to use a bootstrap server with a different endpoint address, you must specify the required endpoint address on the Provider endpoints property of the JMS connection factories or JMS activation specifications that the client application or message-driven bean uses. You can specify one or more endpoint addresses of bootstrap servers by using a comma-separated list.
The endpoint addresses for bootstrap servers must be specified in every JMS 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 can specify a short list of bootstrap servers on each connection factory.
This task is based on an application that uses a unified JMS connection factory. You can use the same task to configure a JMS queue connection factory or JMS topic connection factory, but during the task you must select the appropriate type of connection factory instead of a JMS queue connection factory. You can also use this task to configure a JMS activation specification instead of a JMS connection factory.
[ [host_name] [ ":" [ port_number] [ ":" chain_name] ] ]
Specifying
host_name : chain_name instead of host_name : : chain_name (with two colons) is incorrect. The
default value applies if you do not specify a value, but you must separate the fields with
":"s.For an application to use a bootstrap server with a non-default endpoint address, complete the following steps.