Provide simpler mechanism to refer to queues and topics in a portable way

In the JMS 1.1 API, individual queues and topics are referred to not by name but by using javax.jms.Queue and javax.jms.Topic objects, where the javax.jms.Queue and javax.jms.Topic interfaces both extend the javax.jms.Destination interface.

This is because JMS 1.1 expects the way that a queue or topic is specified to be proprietary to a JMS provider. In order to allow these proprietary aspects to be isolated from the application, JMS 1.1 expects javax.jms.Queue and javax.jms.Topic objects to be "placed in a JNDI namespace by an administrator", for subsequent lookup by a portable application.

Another benefit of storing queue and topic objects in JNDI is that it allows an administrator (or, in Java EE, a deployer) to configure a mapping between the queue or topic JNDI name specified in the application with the actual queue or topic name used by the JMS provider which can be modified without the need to change the application code.

Applications can by-pass this mechanism by using the createQueue(String name) and createTopic(String name) methods on Session to convert a provider-specific queue or topic name to a javax.jms.Queue or javax.jms.Topic object. Since queue or topic names are not portable this usage is, however, not recommended.

There are two main reasons why an application might want to avoid the need to bind and lookup objects in JNDI. For a Java SE application which would otherwise have no use for JNDI, this is an additional complication for the application. For a Java EE application which uses many thousands of destinations (e.g. a market data application that uses a separate topic for every stock code on a stock exchange), then even though a JNDI provider comes built-in, having to create many thousands of administered object is an administrative burden.

This issue therefore raises the issue of whether JMS should be enhanced to allow applications to refer to queues and topics in a portable way without always having to create administered objects in JNDI. Possibilities include:

• Perhaps defining a portable format for queue and topic names to allow the use of createQueue(String name) and createTopic(String name) methods on Session to be portable.

• Perhaps providing methods on JMSContext which allow a queue or topic to be specified as a string (and which therefore call createQueue(String name) or createTopic(String name) internally) - though this might require the domain required (queue or topic) to be passed in as an additional parameter.

• Perhaps adding some defaulting mechanism to the JNDI namespace to allow a javax.jms.Queue or javax.jms.Topic to be looked up in JNDI in some special namespace and for the administered object to be created dynamically.

• There are other possibilities which might be considered as well.

Affected Versions

[1.1]

Review JMS 1.1's Session.createQueue/createTopic, JMSContext, and JNDI usage described in the issue; no repository files or tests are named. Done would require a decided portable mechanism and an agreed API or specification change, rather than choosing among the listed possibilities.