JMS queue resources (queues and queue connection factories) are provided by the default messaging provider for JMS point-to-point messaging and supported by a service integration bus.
The following figure shows a bus with two members, a server and cluster. The two members each have a JMS queue. An application sends messages to one JMS queue and retrieves messages from the other JMS queue. There are queue destinations on a service integration bus and the JMS connection factories. These objects are described in detail below.
An administrator can define a JMS queue, an administrative object that encapsulates the name of a queue destination on a service integration bus. Applications can obtain the JMS queue by looking its name up in the JNDI namespace.
Applications that uses JMS point-to-point messaging act as producers or consumers of messages with JMS queues, and have no need to know about the service integration resources that support JMS queues.
The administrator assigns the queue to only one member (an application server or server cluster) of the bus. The messaging engine in the bus member hosts the message point for the queue, known as a queue point. The queue point is the location where messages for the queue are stored and processed on the bus.
If the bus member has more than one messaging engine, the queue is partitioned across the messaging engines. Each messaging engine hosts a separate queue point for the queue.
With JMS 1.1, you are recommended to use domain-independent JMS connection factories for new applications. Domain-specific queue connection factories are supported for backwards compatibility for JMS applications developed to use domain-specific queue interfaces, as described in section 1.5 of the JMS 1.1 specification.
For more information about creating temporary JMS destinations, see section 4.43 of the JMS 1.1 specification.
For a temporary JMS queue, the service integration bus creates a temporary destination, which the administrator can list and browse but usually does not have to act on.