JMS Queue and Topic Naming Conventions

Question

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

We are currently following the recommendations of the Sun Developer Network Blueprints . For example:

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

I am worried about scaling, as we get more and more queues and topics in the system. I am particularly interested in learning about experience using hierarchical naming and how people made decisions about their naming conventions.

Answer 1

I would suggest something that includes information about the corporate group, application, and version in the 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. It also prevents “crosstalk” between different versions of the same application.

Answer 2

The company I worked with relied heavily on JMS for SOA. They were also focused on domain management, so they organized their services on a business domain in the format <domain> / <function> / <version>. For example, price / compute-foobar-maintenance-fee / 1.0.

The project was not part of the name, because different projects should not have their own "version of the truth" - two applications will not. They have their own service for calculation and maintenance. And which application provides the service has nothing to do with naming the service. Perhaps my application provides a service today, but next year my application will be fired, and another will take over. As long as the contract remains unchanged, the client should not / should not know the difference.