針對JMS隊列和主題命名約定的建議

Question

對於較大的JMS部署，您對命名約定有哪些最佳實踐建議？

目前我們正在關注Sun Developer Network Blueprints中的建議。例如：

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

由於我們在系統中獲得越來越多的隊列和主題，所以我非常擔心縮放這個問題。我特別感興趣的是瞭解使用分層命名的經驗以及人們是如何決定其命名約定的。

Answer 1

我會建議將公司組，應用程序和版本信息合併到命名空間層次結構中。

例如： JMS/mygroup.myproject.version.resource.queue

，如果你有使用相同的JMS服務器集羣技術完全不同的羣體，這非常有用。它還可以防止同一應用程序的不同版本之間出現「串擾」。

Answer 2

我曾經工作過的公司非常依賴JMS for SOA。他們還爲領域驅動設計，所以他們通過業務領域格式<域>/<功能>/<版本>組織他們的服務。例如，price/compute-foobar-maintenance-fee/1.0。

該項目不是名稱的一部分，因爲不同的項目shouldn't have their own "version of the truth" - 兩個應用程序不會有自己的compute-foobar-maintenance-fee服務。哪個應用程序提供服務與命名服務無關。也許我的應用程序今天提供服務，但明年我的應用程序將退役，另一個應用程序將接管。只要合同保持不變，客戶不會/不應該知道差異。