This topic describes options that you can configure to enable workload
management of connections to a service integration bus for JMS applications.
The options for connecting JMS applications to a bus are for administrator
interest; the JMS applications are unconcerned with connections to the bus,
beyond using a JMS connection factory or JMS activationSpec (for message-driven
beans).
The general aim of connecting to a bus is to connect to a suitable messaging
engine that provides the message point for
a JMS destination that the application wants to use. When an application connects
to the bus, the bus first makes a connection to a "bootstrap" messaging
engine. The bus then chooses a suitable messaging engine based on administrative
options provided by the properties of the JMS connection factory or activationSpec.
If you do not want to use workload management of connections, you can leave
the properties to default.
The bus uses the following general process to choose a suitable messaging
engine, based on the value you select for the Connection proximity property.
If you understand this process, you can better configure the properties that
control how the bus chooses messaging engines.
- The bus looks for a suitable messaging engine in the same application
server as the bootstrap messaging engine. If a suitable messaging engine is
found, it is used.
If a suitable messaging engine is not found, and Connection
proximity is set to Server (the default), the bus fails the connection request.
Otherwise, continue with the next step.
- The bus looks for a suitable messaging engine that uses the specified
remote protocol, on the same host as the bootstrap messaging engine. If a
suitable messaging engine is found, it is used.
If a suitable messaging
engine is not found, and Connection proximity is set to Host, the bus fails
the connection request. Otherwise, continue with the next step.
- The bus looks for a suitable messaging engine that uses the specified
remote protocol, in the same custom group as the bootstrap messaging engine.
If a suitable messaging engine is found, it is used.
If a suitable messaging
engine is not found, and Connection proximity is set to Group, fail the connection
request. Otherwise, continue with the next step.
- The bus looks for a suitable messaging engine that uses the specified
remote protocol, on the same bus as the bootstrap messaging engine. If a suitable
messaging engine is found, it is used.
If a suitable messaging engine is
not found, fail the connection request.
To configure how JMS applications connect to a
service integration bus, set the following properties on the JMS connection factory
or activationSpec:
- Specify the bus and provider end points to be used to connect to the bus:
- Bus name
- Type the name of the service integration bus that connections are made to.
- Provider end points
- Type a comma-separated list of end point triplets of the form host:port:protocol.
This identifies the endpoints that can be used to connect to a bootstrap messaging
engine. For example,
merlin:7276:BootstrapBasicMessaging,Gandalf:5557:BootstrapSecureMessaging
Where
- BootstrapBasicMessaging
- This corresponds to the remote protocol InboundBasicMessaging (JFAP-TCP/IP).
- BootstrapSecureMessaging
- This corresponds to the remote protocol InboundSecureMessaging (JFAP-SSL-TCP/IP).
- Specify the properties that control how a suitable messaging engine is
selected:
- Connection proximity
- Select the proximity of acceptable messaging engines, relative to the
bootstrap messaging engine that the bus first makes a connection to.
- Server
- The bus looks for a suitable messaging engine in the same application
server as the bootstrap messaging engine. If a suitable messaging engine is
found, it is used. If a suitable messaging engine is not found, the bus fails
the connection request.
- Host
- The bus performs the Server-based check. If a suitable messaging engine
is not found, the bus looks for a suitable messaging engine on the same host
as the bootstrap messaging engine. If a suitable messaging engine is found,
it is used. If a suitable messaging engine is not found, the bus fails the
connection request.
- Group
- The bus performs the Host-based check. If a suitable messaging engine
is not found, the bus looks for a suitable messaging engine in the same custom
group as the bootstrap messaging engine. If a suitable messaging engine is
found, it is used. If a suitable messaging engine is not found, the bus fails
the connection request.
- Group
- The bus performs the Group-based check. If a suitable messaging engine
is not found, the bus looks for a suitable messaging engine anywhere on the
bus. If a suitable messaging engine is found, it is used. If a suitable messaging
engine is not found, the bus fails the connection request.
- Remote target type
- Select the type of target from which a suitable messaging engine can be
selected. This identifies the type of group named in the Remote target group
parameter. For example, if you select Bus member, the bus retrieves the active
messaging engines that are in the same bus member as the bootstrap messaging
engine.
- Bus member name
- The bus selects a messaging engine that is assigned to the bus member
named.
- Bus destination name
- The bus selects a messaging engine that provides a message point for the destination named.
- Custom group name
- The bus selects a messaging engine from the custom group named. (Messaging
engines can be configured to join a custom group when they start.)
- Messaging engine name
- The bus makes connections to the messaging engine named.
- Remote target group
- Type the name of a target that resolves to a group of messaging engines.
The bus can choose a messaging engine only from the group resolved by this
property. If you do not specify this property, the bus chooses a suitable
messaging engine on the bus specified by the Bus name property.
- Remote protocol
- Type the name of the protocol that should be used to connect to the target
messaging engine. The bus can make connections only to a messaging engine
that supports the specified protocol.
- InboundBasicMessaging
- This is a connection-oriented protocol, using a standard TCP/IP connection
(JFAP-TCP/IP). It includes support for two-phase transactional (remote XA)
flows, so that a message producer or consumer, running on a client or server
system, can participate in a global transaction managed on that client or
server system. The specific use for the XA flows is to support access from
an application running in one server to a messaging engine on second server, perhaps because the first server does not have
a suitable messaging engine.
If the remote XA flows are used, a transaction coordinator must be available
local to the application.
- InboundSecureMessaging
- This is the InboundBasicMessaging protocol wrapped in SSL.
If there are no active messaging engines that match the options specified,
applications cannot use the connection factory or activationSpec to connect
to the bus.