Suggestions for JMS Queue and Topic naming conventions

Question

For larger JMS deployments what are your best practice suggestions for naming conventions?

Currently we're following the suggestions in the Sun Developer Network Blueprints . For example:

jms/<resource-name>[Queue|Topic]

I am concerned about scaling this as we get more and more queues and topics in the system. I'm particularly interested in hearing about experiences using hierarchical naming and how people have decided upon their naming conventions.

Answer 1

I would suggest something that incorporates corporate group, application and version information into a namespace hierarchy.

For example: jms/mygroup.myproject.version.resource.queue

This is useful if you have disparate technical groups using the same jms server cluster. Also it prevents "crosstalk" between different versions of the same application.

Answer 2

A company I used to work for relied very heavily on JMS for SOA. They were also into domain-driven design, so they organized their services by business domain in the format <domain>/<function>/<version>. For example, price/compute-foobar-maintenance-fee/1.0.

The project wasn't part of the name because different projects shouldn't have their own "version of the truth" - two apps wouldn't have their own compute-foobar-maintenance-fee service. And which application provides the service is irrelevant to naming the service. Maybe my application provides the service today but next year, my application will be retired and another will take over. As long as the contract remains the same, the client wouldn't/shouldn't know the difference.