Suggestions pour les conventions de dénomination de la file d'attente et des sujets JMS

Question

Pour les déploiements JMS plus importants, quelles sont vos meilleures pratiques pour les conventions de dénomination?

Nous suivons actuellement les suggestions figurant dans les Modèles du réseau de développeurs Sun . Par exemple:

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

Je suis préoccupé par la réduction de ce nombre, car nous avons de plus en plus de files d'attente et de sujets dans le système. Je suis particulièrement intéressé à entendre parler d’expériences utilisant des noms hiérarchiques et de la façon dont les gens ont choisi leurs conventions de noms.

Answer 1

Je suggérerais quelque chose qui intègre les informations sur les groupes corporatifs, les applications et les versions dans une hiérarchie d'espace de noms.

Par exemple: jms / mygroup.myproject.version.resource.queue

Ceci est utile si vous avez des groupes techniques disparates utilisant le même cluster de serveurs jms. En outre, il empêche & "; Diaphonie &"; entre différentes versions de la même application.

Answer 2

Une entreprise pour laquelle je travaillais auparavant comptait énormément sur JMS for SOA. Comme ils étaient également axés sur la conception par domaine, ils ont organisé leurs services par domaine métier au format & Lt; domaine & Gt; / & Lt; fonction & Gt; / & Lt; version > ;. Par exemple, price / compute-foobar-maintenance-fee / 1.0.

Le projet ne faisait pas partie du nom car différents projets ne devraient pas avoir leur propre "version de la vérité &"; - deux applications n'auraient pas leur propre service de calcul, de maintenance et de maintenance. Et quelle application fournit le service est sans importance pour le nommer. Peut-être que ma demande fournit le service aujourd'hui, mais l'année prochaine, ma demande sera retirée et une autre prendra la relève. Tant que le contrat reste le même, le client ne sait pas / ne devrait pas savoir la différence.