前回はJMSの概要をちょっと書いてみました。
今回はJMSの送受信タイプについてちょっと説明してみたいと思います。

JMSは以下のメッセージング・モデルをサポートしています。

・Point-To-Pointメッセージング・モデル(PTP)
・Publish/Subscribeメッセージング・モデル(Pub/Sub)

まずは、Point-To-Pointメッセージングモデルから見てみましょう。

送信側をプロデューサ、受信側をコンシューマといいます。(昔はそれぞれ、センダー、レシーバと呼んでいました)

プロデューサがメッセージを送信する先をキューと呼びます。キューはJMSの「宛先」の1つで、ちょうど郵便局のポストのようなものだと想像してください。キューに入ったデータは一番最初に受信処理を「キュー」に対して行ったコンシューマによって受信されます。受信処理が成功するとキューからデータは消えます。つまり、早い者勝ちで、データが受信され(てコミットされ)しだい、データがキューから消費されます。

プロデューサがメッセージをキューに送信すると、そのメッセージはただひとつのコンシューマに届けられるまでキューに保持される仕組みです。つまりプロデューサとコンシューマは必ず1:1になります。

次に、Publish/Subscribeメッセージングモデルを見てみましょう。

送信側をパブリッシャ、受信側をサブスクライバと呼びます。パブリッシャがメッセージを送信する宛先をトピックと呼びます。
パブリッシャがメッセージをトピックに対して送信すると、その時点で、トピックに対して登録されているサブスクライバ全部に対してメッセージが送付されます。メッセージ送信時に起動していないサブスクライバはメッセージを受け取りません。メッセージを正常にトピックに送付し、その時点で生きているサブスクライバに届けられた後メッセージはトピックから削除されます。

パブリッシャとサブスクライバは1:Nの関係になります。

#起動していないサブスクライバはメッセージを逃す可能性があります。この問題に対処するために、「永続サブスクライバ」という機能が定義されています。永続サブスクライバをトピックに登録すると、トピック中のメッセージは全ての永続サブスクライバへメッセージ送信を完了しない限り消されなくなります。メッセージがトピックへPublishされる時点で起動していなかった永続サブスクライバは後で起動したときに、トピックからデータを受信することができます。

補足:キューの中のデータの取得順番について

基本的にキューはFIFO(First In First Out:先入れ先出し)のモデルをベースとしています。MQ4.1も基本的にFIFOですが、製品によっては違うアルゴリズムを適用することができるものも存在します。キューの中に複数のデータが存在する場合は、古いもの順で消費されます。ただし、メッセージセレクタを利用するとキュー中の任意のデータをレシーブすることができるようになります。

#JMSの詳細な仕様に関しては以下をご覧ください
http://java.sun.com/products/jms/index.html

次回はMQ4.1をPCにインストールしてみましょう !

投稿されたコメント:

コメント
コメントは無効になっています。

This blog copyright 2009 by naokitakemura