ガイドライン Java Messaging Service (JMS)
トピック
概論
Java Message Service (JMS) は、コンポーネント間の通信に使用できます。
JMS は、非同期通信や保証付き配信などの機能を備えているため、エンタープライズ・アプリケーションでよく使用されます。JMS は、同期通信にも使用されますが、非同期に使用されるのが主流です。
このガイドラインでは、JMS を使用するタイミング、モデリング方法、関連する設計上の考慮事項について説明します。
JMS について詳しくは、『概念: Java Messaging Service』を参照してください。
JMS のモデリング
JMS クライアントはクラスとしてモデリングされます。次のダイアグラムは、JMS を使用してメッセージを送信するメッセージ・プロデューサーの典型的な相互作用を表しています。
例では、送信先としてキューを使用します。

JMS クライアントは、メッセージ・リスナー・インターフェースを実装する必要があります。JMS プロバイダーは、メッセージを受信するごとに特別なメソッド onMessage が必ず呼び出されるようにします。

次のダイアグラムは、JMS コンシューマー・クライアントの一般的な設定を表しています。

JMS の設計
JMS アプリケーションの設計には、主に 2 つの方法があります。ポイント・ツー・ポイント とパブリッシュ・サブスクライブ です。
ポイント・ツー・ポイントモデルでは、1 つのクライアントへのメッセージ配信に JMS を使用します。

メッセージ・プロデューサーは、1 つのキュー宛てにメッセージを送信することによって、メッセージ・コンシューマーと通信します。理論上は、キューには 1 つのコンシューマーのみ存在しますが、多くの JMS プロバイダーでは、複数のコンシューマーの間でロード・バランシングをサポートしています。複数コンシューマーを使用する場合、それぞれのメッセージは 1 つのコンシューマーのみによって処理されます。メッセージは、処理されるか期限が切れるまで、キューに保持されます。
パブリッシュ・サブスクライブ・モデルでは、通信パターンによって、複数のプロデューサーが複数のコンシューマーにメッセージを配信できます。コンシューマーがトピックにサブスクライブすると、ミドルウェアはコンシューマーにメッセージを配信します。

ポイント・ツー・ポイント・モデルとは異なり、パブリッシュ・サブスクライブ・モデルでは、メッセージはすべてのクライアントが受信するまでトピックに保持されます。
注: JMS 1.1 以降、同じ JMS アプリケーションでこの 2 つのモデルを組み合わせることができます。
|