Rüdiger,
On 21/03/2012 18:20, Rüdiger zu Dohna wrote:
> According to the JMS spec, chapter 4.2, Destinations are administered objects, i.e. type-safe resources that "live"
> in JNDI. The reasoning behind that is absolutely conclusive for connection factories: Decouple the client code from
> the specific, readily configured implementation. But I wonder, is that also true for the Destinations?
>
> Destinations are a named indirection to the actual addressing scheme used by the provider internally. They have to be
> configured, of course, but the clients only address them by their name and do nothing else with them but pass them
> into JMS methods. Connection factories are used to create connections, but Destinations are only passed back to the
> JMS provider.
>
> I think it would be sufficient to only pass the destination name into those methods, instead of Destination objects
> that have to be looked up first. That would further reduce the amount of code required and lessen the mental burden
> of JMS.
>
> Interestingly, this would also permit you to use the same destination name for different JMS providers, which would
> be very helpful for messaging bridges. Currently you can only pass a Destination to the same JMS provider that the
> Destination was configured for; you'll have to use some naming scheme to bridge from one JMS provider's destination
> to another one's.
>
> What do you all think? If I just missed an essential use case, please tell me so!
The use of administered objects avoids the need for the application to hard-code information which may not be known
until the application is deployed. This applies to destinations as well as connection factories, since the actual
destination name may not be known until deployment time.
Also, since JMS does not define what constitutes a valid destination name (e.g. what characters it may contain) any
application that uses destination names directly may not be portable between JMS providers (the javadoc for
Session.createSession(queueName) describes queueName as a "provider-specific name" and warns that "Clients that depend
on this ability are not portable".
However the fact that a Destination is administered object is not without issues:
1. A Destination is a little unusual as an administered object: if you think of a destination as something that needs to
be explicitly created in the JMS provider (the JMS spec states that "the physical creation of topics is an
administrative task") then a Destination object is not an independent object. It can only be used in conjunction with a
ConnectionFactory which points to the JMS server which contains the destination. Yet this dependency is not expressed
anywhere.
2. It is also inconsistent with the way that databases are configured in Java EE. A JMS server may be thought of as
consisting of a number of destinations. In the same way a database may be thought of as consisting of a number of
tables. Yet a destination is an administered object whilst a table is not. As Rüdiger says, this imposes an extra burden
when using JMS.
3. Some applications need to be able to send messages to many thousands of destinations. For example, a market data
provider may need to send stock prices to a different topic for every stock ticker code. Having to explicitly create an
administered object for every destination is a burden compared with simply calling Session.createQueue(queueName).
I'm not sure what changes, if any, we might we want to make in JMS. One thing I'm sure of, however, is that we need to
recognise that the createQueue and createTopic methods are sometimes more appropriate than looking up an administered
object. One idea might be to define a portable format for destination names that would be guaranteed to be valid in any
JMS provider (e.g. defining what characters are valid, what the maximum length is, and so on).
More comments welcome...
Nigel