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