メッセージングドメイン

メッセージングミドルウェアは、メッセージのプロデュースとコンシュームを行うことにより、コンポーネントおよびアプリケーションの通信を実現します。JMS API では、この通信を制御するパターン、すなわちメッセージングドメインとして、ポイントツーポイントメッセージングとパブリッシュ / サブスクライブメッセージングの 2 つを規定しています。JMS API は、これらのパターンをサポートするように構成されています。基本的な JMS オブジェクト、つまりコネクション、セッション、プロデューサ、コンシューマ、送信先、メッセージが、両方のドメインでメッセージング動作を指定するために使用されます。

ポイントツーポイントメッセージング

ポイントツーポイントドメインでは、メッセージプロデューサは送信側と呼ばれ、コンシューマは受信側と呼ばれます。これらは、キューと呼ばれる送信先を使用してメッセージを交換します。送信側は、キューへメッセージをプロデュースし、受信側はキューからメッセージをコンシュームします。

図 2–1 に、ポイントツーポイントドメインでのもっとも単純なメッセージング操作を示します。MyQueueSender は、 Msg1 をキュー送信先 MyQueue1 に送信します。続いて、 MyQueueReceiver は MyQueue1 からメッセージを取得します。

図 2–1 単純なポイントツーポイントメッセージング

図 2–2 に、このドメインでの可能性を表すために、より複雑なポイントツーポイントメッセージングのイメージを示します。2 つの送信側、MyQSender1 と MyQSender2 は、同じコネクションを使用して、メッセージを MyQSender1 に送信します。 MyQSender3 は、別のコネクションを使用して、メッセージを MyQueue1 に送信します。受信側では、MyQReceiver1 が MyQueue1 からメッセージをコンシュームし、MyQReceiver2 と MyQReceiver3 は、コネクションを共有して、MyQueue1 からメッセージをコンシュームします。

図 2–2 複雑なポイントツーポイントメッセージング

この複雑な図では、ポイントツーポイントメッセージングに関するその他の要点が多数示されています。

• 複数のプロデューサから 1 つのキューにメッセージを送信できる。プロデューサは、1 つのコネクションを共有することも、別々のコネクションを使用することもできますが、すべてが同じキューにアクセスできます。

• 複数の受信側がキューからメッセージをコンシュームできるが、それぞれのメッセージは、単一の受信側でしかコンシュームできない。このため、Msg1、Msg2、および Msg3 は、別々の受信側にコンシュームされます。これは Message Queue の拡張機能です。

• 受信側は、1 つのコネクションを共有することも、別々のコネクションを使用することもできるが、すべてが同じキューにアクセスできる。これは Message Queue の拡張機能です。

• 送信側と受信側はタイミング依存性がない。受信側は、クライアントがメッセージを送信したときに稼働していてもしていなくても、メッセージを取り出せます。

• 送信側と受信側は、実行時に、動的に追加および削除できるので、必要に応じて、メッセージングシステムを拡張したり縮小したりできる。

• メッセージは、送信順にキューに入れられるが、コンシュームされる順番は、メッセージの有効期限、メッセージの優先度、メッセージのコンシュームでセレクタを使用するかどうかなどの要因によって決まる。

ポイントツーポイントモデルには、次のような多くのメリットがあります。

• 複数の受信側が同じキューからメッセージをコンシュームできることにより、メッセージを受信する順序が重要でない場合は、メッセージコンシュームをロードバランスできる。これは Message Queue の拡張機能です。

• 受信側がない場合でも、キューに送られるメッセージは常に保持される。

• Java クライアントは、キューブラウザオブジェクトを使用して、キューの内容を調べることができる。続いてクライアントは、この調査から得られた情報に基づいて、メッセージをコンシュームできます。つまり、コンシュームモデルは通常 FIFO (先入れ先出し) ですが、メッセージセレクタを使用することにより、どのメッセージが必要であるかがわかれば、コンシューマはキューの先頭にはないメッセージでもコンシュームできます。管理クライアントも、キューブラウザを使用して、キューの内容を監視できます。

パブリッシュ / サブスクライブメッセージング

パブリッシュ / サブスクライブドメインでは、メッセージプロデューサはパブリッシャーと呼ばれ、メッセージコンシューマはサブスクライバと呼ばれます。これらは、トピックと呼ばれる送信先を使用してメッセージを交換します。パブリッシャーは、トピックへメッセージをプロデュースし、サブスクライバはトピックへサブスクライブして、トピックからメッセージをコンシュームします。

図 2–3 に、パブリッシュ / サブスクライブドメインの単純なメッセージング操作を示します。MyTopicPublisher は、Msg1 を送信先 MyTopic へパブリッシュします。続いて、MyTopicSubscriber1 と MyTopicSubscriber2 はそれぞれ、 MyTopic から Msg1 のコピーを受信します。

図 2–3 単純なパブリッシュ / サブスクライブメッセージング

パブリッシュ / サブスクライブモデルでは、複数のサブスクライバが必要になるわけではありませんが、このドメインが複数のメッセージをブロードキャストできることを強調するために、図では 2 つのサブスクライバを示しています。トピックに対応するすべてのサブスクライバが、このトピックへパブリッシュされた任意のメッセージのコピーを取得します。

サブスクライバは、非永続でも永続でもかまいません。ブローカは、すべてのアクティブなサブスクライバのメッセージを保持しますが、非アクティブなサブスクライバのメッセージは、これらのサブスクライバが永続である場合にのみ保持します。

図 2–4 に、このパターンによって実現する可能性を表すために、より複雑なパブリッシュ / サブスクライブメッセージングのイメージを示します。複数のプロデューサがメッセージを Topic1 送信先にパブリッシュします。複数のサブスクライバが、Topic1 送信先からメッセージをコンシュームします。サブスクライバがセレクタを使用してメッセージをフィルタ処理しないかぎり、各サブスクライバは、選択したトピックへパブリッシュされたすべてのメッセージを取得します。図 2–4 では、MyTSubscriber2 は Msg2 をフィルタで除外しています。

図 2–4 複雑なパブリッシュ / サブスクライブメッセージング

この複雑な図では、パブリッシュ / サブスクライブメッセージングに関するその他の要点が多数示されています。

• 複数のプロデューサから 1 つのトピックにメッセージをパブリッシュできる。プロデューサは、1 つのコネクションを共有することも、別々のコネクションを使用することもできますが、すべてが同じトピックにアクセスできます。

• 複数のサブスクライバが 1 つのトピックからメッセージをコンシュームできる。サブスクライバは、セレクタを使用してメッセージをフィルタで除外したり、コンシューム前にメッセージの有効期限が切れないかぎり、トピックへパブリッシュされたすべてのメッセージを取得します。

• サブスクライバは、1 つのコネクションを共有することも、別々のコネクションを使用することもできるが、すべてが同じトピックにアクセスできる。

• 永続サブスクライバは、アクティブでも非アクティブでもかまわない。非アクティブの間、サブスクライバへのメッセージはブローカが保持します。

• パブリッシャーとサブスクライバは、実行時に、動的に追加および削除できるので、必要に応じて、メッセージングシステムを拡張したり縮小したりできる。

• メッセージは、送信順にトピックへパブリッシュされるが、コンシュームされる順番は、メッセージの有効期限、メッセージの優先度、メッセージのコンシュームでセレクタを使用するかどうかなどの要因によって決まる。

• パブリッシャーとサブスクライバはタイミング依存性がある。トピックサブスクライバは、サブスクリプションの作成後にパブリッシュされたメッセージだけをコンシュームできます。

パブリッシュ / サブスクライブモデルの主要なメリットは、複数のサブスクライバへメッセージをブロードキャストできるという点です。

ドメイン固有 API と統合 API

JMS API では、ポイントツーポイントドメインまたはパブリッシュ / サブスクライブドメインのいずれかの実装に使用できるインタフェースとクラスを規定しています。これらは、表 2–1 の 2 列目と 3 列目に示したドメイン固有 API です。JMS API では、そのほかに統合ドメインを規定しており、これを使用すれば、汎用メッセージングクライアントをプログラムできます。このようなクライアントの動作は、メッセージのプロデュース先でありメッセージのコンシューム元である送信先のタイプによって決定されます。送信先がキューの場合、メッセージングはポイントツーポイントのパターンに従って動作します。送信先がトピックの場合、メッセージングはパブリッシュ / サブスクライブパターンに従って動作します。

表 2–1 JMS プログラミングドメインとオブジェクト

基本タイプ (統合ドメイン)	ポイントツーポイントドメイン	パブリッシュ / サブスクライブドメイン
Destination (Queue または Topic)	Queue	Topic
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver	TopicSubscriber

統合ドメインは、JMS バージョン 1.1 から導入されています。以前の 1.02b 仕様に適合する必要がある場合は、ドメイン固有 API を使用できます。ドメイン固有 API を使用すると、特定のプログラミングエラーを防止するクリーンなプログラムインタフェースが得られます。たとえば、キュー送信先に対する永続サブスクライバの作成などです。ただしドメイン固有 API には、同じトランザクションまたは同じセッションにおいて、ポイントツーポイント操作とパブリッシュ / サブスクライブ操作を組み合わせることができないというマイナス面もあります。両方の操作を組み合わせる必要がある場合は、統合ドメイン API を選択してください。2 つのドメインの組み合わせ例については、「要求 / 応答パターン」を参照してください。