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

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

図 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 (先入れ先出し) ですが、メッセージセレクタを使用することにより、どのメッセージが必要であるかがわかれば、コンシューマはキューの先頭にはないメッセージでもコンシュームできます。管理クライアントも、キューブラウザを使用して、キューの内容を監視できます。