| Oracle® Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング 11g リリース1 (10.3.6) B61425-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング 11g リリース1 (10.3.6) B61425-04 |
|
前 |
次 |
WebLogic Server MDBは、ポイント・ツー・ポイント(キュー)またはパブリッシュ/サブスクライブ(トピック)メッセージング・モデルのいずれかで使用できます。それらのモデルの詳細は、『Oracle WebLogic Server JMSのプログラミング』の「WebLogic JMSについて」を参照してください。
以降の節では、ポイントツーポイント・メッセージング・アプリケーションとパブリッシュ/サブスクライブ・メッセージング・アプリケーションの主な違いを説明します。
ポイントツーポイント・モデルでは、JMSキューからのメッセージが1つのMDBリスナーによって取り出され、処理されるまでキューに留まります。そのMDBがダウンした場合、メッセージはMDBが再びアクティブになるのをキューの中で待ちます。
例: ある売り場では、1日を通して売れた品目を反映してバックエンドの在庫システムを更新する必要があります。在庫の値を減らす各メッセージは、必ず一度だけ処理されなければなりません。メッセージはそれが生成された直後に処理されたり、特定の順序で処理されたりする必要はありませんが、各メッセージが必ず処理されることが重要です。
図3-1は、ポイント・ツーポイント・アプリケーションを示しています。各メッセージは、MDB_Aの1つのインスタンスによって処理されます。メッセージ「M1」はMDB_A(1)で処理され、「M2」はMDB_A(2)で処理され、「M3」はMDB_A(3)で処理されます。
パブリッシュ/サブスクライブ・モデルでは、JMSトピックは各メッセージのコピーを各論理サブスクリプションにパブリッシュします。論理サブスクリプションは、1つ以上の物理的なサブスクリプションから構成され、各物理サブスクリプションは分散トピックの異なるメンバーに関連付けられます。スタンドアロン(非分散)トピックの場合、論理サブスクリプションは常にトピック上の単一の物理サブスクリプションから構成されます。MDBがダウンする場合、トピックが恒久サブスクリプション・トピックでないかぎり、当該MDBはメッセージを見失います。恒久サブスクリプションの情報および構成の手順は、第10章「サブスクリプション恒久性の設定」を参照してください。
例: 金融ニュース・サービスは、株価と金融情報をサブスクライバ(ニュース配信サービスなど)にブロードキャストします。各メッセージは、各サブスクライバに配信されます。
図3-2は、パブリッシュ/サブスクライブ・アプリケーションを示します。ポイント・ツー・ポイント・アプリケーションとは対照的に、パブリッシュ/サブスクライブ・モデルでは、メッセージのコピーは論理サブスクリプションのそれぞれに対して処理されます。この図では、2つの論理サブスクリプションがあり、各論理サブスクリプションは単一のトピック上の個別の物理サブスクリプションから構成されます。MDB_Aには、単一の専用サブスクリプションのメッセージを処理する2つのインスタンスがあります。同様に、MDB_Bには、異なる単一の専用サブスクリプションのメッセージを処理する2つのインスタンスがあります。メッセージM1は、MDB_AのインスタンスおよびMDB_Bのインスタンスによって処理されます。同様に、メッセージM2は、サブスクライブ側の各MDBのインスタンスによって処理されます。
MDBアプリケーションは各メッセージを1回以上処理します。メッセージは、複数回処理される場合もあります。
onMessage()メソッドの途中、またはこのメソッドが完了した後で、メッセージが確認応答またはコミットされる前にアプリケーションで障害が起きるか、トランザクションがロールバックされるか、ホスト・サーバー・インスタンスで障害が発生した場合、メッセージは再配信されて再び処理されます。
非永続的なメッセージも障害時には再配信されますが、メッセージのホストJMSサーバーが停止またはクラッシュしたときは除きます(この場合はメッセージが破棄されます)。
メッセージが必ず1回処理されるようにするには、コンテナ管理によるトランザクションを使用します。そうすれば、障害が発生したときにトランザクションMDBの処理がロールバックされ、メッセージが強制的に再配信されます。
