JMS connection factories

A connection factory is an object that a JMS client (a JMS program that uses the JMS API) uses to create a connection with a JNDI provider (a messaging provider such as IBM MQ ).

We can use IBM MQ Explorer to create connection factories and to define the connection parameters that the connection factory will use to create connections.

Connection factories, like destinations, are administered objects and are stored in a JNDI namespace, which is a defined location within the naming and directory service. The initial context defines the root of the JNDI namespace. In IBM MQ Explorer, all connection factories are stored in Connection Factories folders in the appropriate context and subcontexts, as shown in the following figure.

In the figure, the connection factory that is called Connection Factory 1 is stored in the Connection Factories folder of the initial context called File System Initial Context.

When you define a connection factory, you select the messaging provider that is used as the JMS provider (for example, IBM MQ or Real-time); a connection factory can create connections only to that messaging provider. For the JMS client to create connections to a different messaging provider, you must create a new connection factory and specify the messaging provider. Real-time transport is not available in IBM MQ Version 8.0. If you are using IBM MQ Version 8.0 we can define Real-time transport, but it fails when an attempt is made to create a connection.

Domain-independent connection factories

There are two messaging domains: the point-to-point messaging domain and the publish/subscribe messaging domain. We can create a connection factory to create connections specifically for point-to-point messaging (using the QueueConnectionFactory interface) or specifically for publish/subscribe messaging (using the TopicConnectionFactory interface). From JNDI, we can also create connection factories that are domain independent and so can be used for both point-to-point and publish/subscribe messaging (using the ConnectionFactory interface). For more information, see Creating a connection factory.

If the JMS application is intended to use only point-to-point messaging or only publish/subscribe messaging, we can select the specific messaging domain when you create the connection factory and a domain-specific connection factory is created.

If, however, you want to perform both point-to-point and publish/subscribe work under the same transaction, we can create a domain-independent connection factory. For example, you might want a JMS application to subscribe to a topic (publish/subscribe messaging) then when the JMS application receives a particular message, it sends another message to a queue (point-to-point messaging). It is difficult to reliably perform both point-to-point and publish/subscribe work under the same transaction if we use domain-specific connection factories: you must create a separate connection factory for each messaging domain, which means that the point-to-point work is done under a transaction that is controlled by the QueueSession session and the publish/subscribe work is done under a transaction that is controlled by the TopicSession session. It is difficult to ensure that the send and receive actions either both happened or both were backed out.

Instead of creating one domain-specific connection factory for the point-to-point work and one domain-specific connection factory for the publish/subscribe work, we can create a single domain-independent connection factory for both. This means that the connection factory creates one connection, which creates one session. The session creates a MessageConsumer from a topic and a MessageProducer to a queue. When the JMS application receives the published message, the next message can be sent to the queue under the same session's transaction; both operations can then be committed or rolled back as a single unit of work.

For more information, see Use IBM MQ classes for JMS in the IBM MQ online product documentation.