jms-spec
  1. jms-spec
  2. JMS_SPEC-90

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

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        chris.barrow added a comment - - edited

        I would vote for the first option (defining a portable format for queue and topic names to allow the use of createQueue and createTopic). The portable format just needs to specifiy a minimum set of characters which are valid in a topic or queue name. This is very similar to JMS_SPEC_94 (for durable or shared subscription name).

        I think this would be a very useful enhancement and we should try to get it into JMS 2.0.

        Show
        chris.barrow added a comment - - edited I would vote for the first option (defining a portable format for queue and topic names to allow the use of createQueue and createTopic). The portable format just needs to specifiy a minimum set of characters which are valid in a topic or queue name. This is very similar to JMS_SPEC_94 (for durable or shared subscription name). I think this would be a very useful enhancement and we should try to get it into JMS 2.0.
        Hide
        axel_podehl added a comment -

        I think createTopic/createQueue is already used in many applications and the real behaviour differs from provider to provider.

        How about adding a method like this one, similar to the properties of the JMSDestinationDefinition annotation:

        Session.createTopic( String jndiName, String destinationName, String description, String[] properties)

        or along the lines of ConnectionMetaData:

        Session.createTopic( String jndiName, DestinationMetaData destDefinition )

        and Session.createTopic( String name ) would then use the method above, and each provider should comment on the actual arguments used.

        Show
        axel_podehl added a comment - I think createTopic/createQueue is already used in many applications and the real behaviour differs from provider to provider. How about adding a method like this one, similar to the properties of the JMSDestinationDefinition annotation: Session.createTopic( String jndiName, String destinationName, String description, String[] properties) or along the lines of ConnectionMetaData: Session.createTopic( String jndiName, DestinationMetaData destDefinition ) and Session.createTopic( String name ) would then use the method above, and each provider should comment on the actual arguments used.

          People

          • Assignee:
            Unassigned
            Reporter:
            Nigel Deakin
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: