Vorschläge für JMS Queue und Topic Namenskonventionen

Question

Für größere JMS-Implementierungen, was die beste Praxis Vorschläge sind für Namenskonventionen?

Derzeit sind wir im Anschluss an die Vorschläge in der Sun Developer Network Blueprints. Zum Beispiel:

Ich bin besorgt über die Skalierung, wie wir mehr und mehr Warteschlangen und Themen im System bekommen. Ich bin besonders daran interessiert, von Erfahrungen zu hören, die hierarchische Benennungen verwenden, und darüber, wie sich Menschen für ihre Namenskonventionen entschieden haben.

Answer 1

Ich würde etwas vorschlagen, die Unternehmensgruppe umfasst, Anwendung und Versionsinformationen in eine Namespace-Hierarchie.

Zum Beispiel: jms/mygroup.myproject.version.resource.queue

Dies ist nützlich, wenn Sie unterschiedliche technische Gruppen mit den gleichen jms-Server-Cluster haben. Außerdem verhindert es "Übersprechen" zwischen verschiedenen Versionen derselben Anwendung.

Answer 2

Eine Firma für die ich verließ sich sehr stark auf JMS für SOA zu arbeiten, verwendet. Sie waren auch in domain-driven Design, so dass sie ihre Dienste nach Geschäftsdomäne im Format < Domäne >/ Funktion >/<Version> organisiert. Zum Beispiel, Preis/Compute-Foobar-Wartungsgebühr/1.0.

Das Projekt war nicht Teil des Namens, weil verschiedene Projekte shouldn't have their own "version of the truth" - zwei Apps nicht ihren eigenen Compute-Foobar-Wartungsgebühren-Service hätten. Und welche Anwendung den Dienst bereitstellt, ist für die Benennung des Dienstes irrelevant. Vielleicht stellt meine Anwendung heute den Service zur Verfügung, aber nächstes Jahr wird meine Bewerbung zurückgezogen und eine andere wird übernehmen. Solange der Vertrag gleich bleibt, würde/würde der Kunde den Unterschied nicht kennen.