Java 2 Platform Enterprise Edition (J2EE) では、現在、メッセージ・ドリブン Bean がサポートされていますが、この Bean は静的です。 このシナリオは、動的メッセージ Bean を使用可能にする環境のセットアップ方法について説明します。
すべてのメッセージ送信元は事前に認識されており、デプロイメント時にバインドされる必要があります。 このアクションは、必ずしも実現可能であるとは限りません。特に、証券会社の環境のように流動的なメッセージング環境では、実現は難しくなります。環境の中には、絶え間なく変化する Publish-Subscribe トピック・スペースを持つものがあり、クライアントでは、要求時に任意のトピックをサブスクライブできるサーバーが必要となります。
非同期 Bean アプリケーションは、Java Message Service (JMS) トピックに対してブロッキング受信を実行する作業オブジェクトを作成し、 アプリケーション定義イベント・ソースのイベントとしてメッセージをパブリッシュできます。 このメッセージに対するサブスクリプションを必要とするクライアントは、イベント・リスナーをイベント・ソースに追加できます。リスナーがない場合、イベント・ソースは、作業オブジェクトに通知できます。 その後、イベント・ソースはシャットダウンし、JMS およびスレッド・リソースが使用可能となります。作業オブジェクトは、独自のイベント・ソースにリスナーを 1 つ登録します。 数が再度 1 になった場合、作業オブジェクトはこれが唯一のリスナーであると認識し、作業オブジェクトをシャットダウンする時刻であると認識します。WebSphere トレーダーのサンプル (インストール済みのサンプル・ギャラリーを参照) では、実行時の JMS トピックの動的なサブスクライブに対してこのパターンを使用して、株価を収集します。 詳細については、サンプルの概要を参照してください。
サーバーは、切断または破壊されているクライアントをどのようにしてキャッチするのでしょうか。 サーバーは、クライアントをモニターするサブシステム・モニターを作成し、デッド・イベントをキャッチするための イベント・リスナーを追加します。 デッド・イベントが発生した場合、サーバー・アプリケーションは、クライアントのサーバー状態をクリーンアップします。 例えば、サーバー・アプリケーションは、クライアントのイベント・リスナーを動的メッセージ Bean から除去できます。これにより、そのサーバーは必要に応じて、動的トピックをサブスクライブできるようになります。