The setup and configuration of queues tends to be vendor-specific. A queue may be used exclusively by one consumer, or shared by multiple consumers. It may have a size limit (limiting the number of unconsumed messages held in the queue) with options for in-memory storage versus overflow to disk. In addition, a queue may be configured with a vendor-specific addressing syntax, or special routing capabilities.

JMS doesn't attempt to define a set of APIs for all the possible options on a queue. It should be possible to set these options administratively, using the vendor-specific administration capabilities. Figure 5.1 shows what a graphical administration tool for queues would look like. Most vendors supply a command-line administration tool, a graphical administration tool, or an API for administering queues at runtime. Some vendors supply all three.

Figure 5.1. Queues are created and administered using vendor-specific administration tools

Using vendor-specific administration APIs to create and configure a queue may be convenient at times. However, it is not very portable, and may require that the application have administrator privileges.

JMS provides a QueueSession.createQueue(String queueName) method, but this is not intended to define a new queue in the messaging system. It is intended to return a Queue object that represents an existing queue. There is also a JMS-defined method for creating a temporary queue that can only be consumed by the JMS client that created it: QueueSession.createTemporaryQueue( ). A temporary queue is similar to a temporary topic, and could have been used in our example just like the TemporaryTopic was used in Chapter 4.