JMSキューおよびトピックの命名規則に関する提案

Question

大規模なJMSデプロイメントの命名規則に関するベストプラクティスの提案は何ですか？

現在、 Sun Developer Networkブループリントの提案に従っています。例：

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

システム内のキューとトピックが増えるにつれて、これをスケーリングすることを心配しています。階層的な命名法を使用した経験と、人々が命名規則をどのように決定したかについて、特に興味があります。

Answer 1

企業グループ、アプリケーション、およびバージョン情報をネームスペース階層に組み込むものを提案します。

例： jms / mygroup.myproject.version.resource.queue

これは、同じjmsサーバークラスタを使用する異なる技術グループがある場合に役立ちます。また、<！> quot; crosstalk <！> quot;を防ぎます。同じアプリケーションの異なるバージョン間。

Answer 2

以前私が働いていた会社は、JMS for SOAに大きく依存していました。また、ドメイン駆動型の設計も行っていたため、ビジネスドメインごとに<！> lt; domain <！> gt; / <！> lt; function <！> gt; / <！> lt; versionの形式でサービスを整理しました。 <！> gt;。たとえば、price / compute-foobar-maintenance-fee / 1.0です。

プロジェクトは名前の一部ではありませんでした。異なるプロジェクト独自の<！ > quot; version of the truth <！> quot; -2つのアプリに独自のcompute-foobar-maintenance-feeサービスはありません。また、どのアプリケーションがサービスを提供するかは、サービスの命名とは無関係です。私のアプリケーションが今日サービスを提供しているかもしれませんが、来年、私のアプリケーションは廃止され、別のアプリケーションが引き継ぎます。契約が同じである限り、クライアントは違いを知らない/すべきではありません。