How JMS applications connect to a messaging engine on a bus
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 we 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 running in an application server: Default configuration
Applications 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 running in the same bus but on a different server and host, because server1 does not have a suitable messaging engine.
Applications running outside an application server
Client applications running outside an application server (for example, running in a client container or outside the WAS 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 running the SIBService service, but is not necessarily running any messaging engines. The bootstrap server selects a messaging engine running in an application server that supports the required target transport chain.
Figure 2. Connection to a messaging engine - Applications running outside an application server
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 on the same host as the client, and that uses port 7276 and the predefined bootstrap transport chain called BootstrapBasicMessaging.
(iSeries) Note: For the IBM i platform, we must (at least) change the default endpoint address from localhost:7276:BootstrapBasicMessaging to your.server.name:7276:BootstrapBasicMessaging.
When creating 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. To use an application server as a bootstrap server, and the server has been assigned a non-secure port other than 7276, or we want to use the secure port, then we 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 used by applications outside of an application server. To avoid having to specify a long list of bootstrap servers, we can provide a few highly-available servers as dedicated bootstrap servers. Then we only have to specify a short list of bootstrap servers on each connection factory.
The messaging engine selection process
The selection process is used to choose a messaging engine an application should connect to so that it can use the resources of a service integration bus. The information that controls the selection process is configured in one of the following places:
- For JMS client applications, this information is configured on the connection factory.
- For message-driven bean (MDB) applications, this information is configured on the activation specification.
- For other types of application, this information is configured programmatically by the application.
Although a connection can be made to any available messaging engine, the connection process applies a few simple rules to find the most suitable messaging engine. For an application running in an application server, the process is as follows:
- If a messaging engine is running in the required bus within the same application server, then a connection is made from the application to the messaging engine. If there is no suitable messaging engine, the next rule is checked.
- If a messaging engine is running on the same host as the application, then the application makes a remote connection to the selected messaging engine. If there is no suitable messaging engine, the next rule is checked.
- If a messaging engine is running anywhere in the bus, then the application makes a remote connection to the selected messaging engine. If there is no suitable messaging engine, the connection attempt does not succeed.
For an application running outside an application server, connection requests are workload balanced across all the available messaging engines in the bus.
In both cases (that is, an application running in an application server and an application running outside an application server) we 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:
- Target
- The name of a target that identifies a group of messaging engines. Type of target using the Target type property.
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.
- Target type
- The type of target named in the Target property.
- Bus member name
- The name of a bus member. This option retrieves the active messaging engines that are hosted by the named bus member (an application server or server cluster).
- Custom messaging engine group name
- The name of a custom group of messaging engines (that form a self-declaring cluster). This option retrieves the active messaging engines that have registered with the named custom group.
- Messaging engine name
- The name of a messaging engine. This option retrieves the available endpoints used to reach the named messaging engine.
- Target significance
- This property defines whether the connection proximity search is restricted to only the messaging engines in the target group.
- Preferred
- It is preferred that a messaging engine is selected from the target group. A messaging engine in the target group is selected if one is available. If a messaging engine is not available in the target group, a messaging engine outside the target group is selected if available in the same service integration bus.
- Required
- It is required that a messaging engine is selected from the target group. A messaging engine in the target group is selected if one is available. If a messaging engine is not available in the target group, the connection process fails.
- Target inbound transport chain
-
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 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.
The following predefined messaging engine inbound transport chains are provided:
- InboundBasicMessaging
- JFAP over TCP/IP
- InboundSecureMessaging
- JFAP over SSL over TCP/IP
- Connection proximity
- For
an application running in an application server, this property defines
the proximity of messaging engines relative to the application server.
For an application running outside an application server, this property
defines the proximity of messaging engines relative to the bootstrap
server.
- Bus
- Connections can be made to messaging engines in the same bus.
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.
- Cluster
- Connections can be made to messaging engines in the same server cluster. If the application is not running in a clustered server, or the bootstrap
server is not in a cluster, then there are no suitable messaging engines.
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.
- Host
- Connections can be made to messaging engines in the same host. A suitable messaging engine in the same server is selected ahead of a suitable messaging engine in the same host.
- Server
- Connections can be made to messaging engines in the same application server.
For MDB applications connecting to a cluster bus member, we can also enable either of the following additional configurations:
- All servers in the cluster can receive messages from the MDB application, to make full use of the processing power in the cluster.
- Just one server at a time can receive messages from the MDB application, to ensure sequential processing of the messages.
See How a message-driven bean connects in a cluster.
To create or modify a JMS connection factory, see the following topics:
- Configure the messaging engine selection process for JMS applications.
- Configure a unified connection factory for the default messaging provider.
- createSIBJMSConnectionFactory command.
- modifySIBJMSConnectionFactory command.
To create or modify an activation specification, see the following topics:
- Configure an activation specification for the default messaging provider.
- createSIBJMSActivationSpec command.
- modifySIBJMSActivationSpec command.
Subtopics
- How a message-driven bean connects in a cluster
When an enterprise bean (EJB) application is deployed to an application server cluster, the application can run on any of the servers in the cluster to provide high availability and scalability of the application. When the EJB application is a message-driven bean (MDB), it can run on any of the servers in the cluster (for high availability) and can be invoked concurrently in multiple application servers in the cluster (for scalability). This behavior depends on the location of the MDB with respect to any service integration bus members, and on the configuration of the MDB itself. - Why and when to pass the JMS message payload by reference
When large object messages or bytes messages are sent, the cost in memory and processor use of serializing, deserializing, and copying the message payload can be significant. If we enable the pass message payload by reference properties on a connection factory or activation specification, you tell the default messaging provider to override the JMS 1.1 specification and potentially reduce or bypass this data copying.
Related: