TM| ドキュメントのダウンロード | サイト マップ | Glossary | TM|
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
TM |
|
|||||||
 |
| e-docs > WebLogic ServerTM > WebLogic エンタープライズ JavaBeans プログラマーズ ガイド > メッセージ駆動型 Bean の設計 |
|
WebLogic エンタープライズ JavaBeans プログラマーズ ガイド
|
以下の節では、メッセージ駆動型 Bean を開発し、WebLogic Server にデプロイする方法について説明します。 メッセージ駆動型 Bean では標準の Java Messaging Service (JMS) API を部分的に利用するので、メッセージ駆動型 Bean を実装する前に WebLogic JMS を理解する必要があります。詳細については、『WebLogic JMS プログラマーズ ガイド』を参照してください。
メッセージ駆動型 Bean は、WebLogic JMS メッセージング システムでメッセージ コンシューマとして機能する EJB です。標準の JMS メッセージ コンシューマの場合と同じように、メッセージ駆動型 Bean では JMS キューまたは JMS トピックからメッセージを受信し、そのメッセージの内容に基づいてビジネス ロジックを実行します。
デプロイメント時にキューまたはトピックのリスナを作成すると、WebLogic Server では受信メッセージを処理するために必要に応じてメッセージ駆動型 Bean のインスタンスが自動的に作成および削除されます。
メッセージ駆動型 Bean と標準の JMS コンシューマとの違い
メッセージ駆動型 Bean は EJB として実装されるため、標準の JMS コンシューマでは利用できないサービスからの恩恵を受けます。最も重要なことは、メッセージ駆動型 Bean のインスタンスは、全面的に WebLogic Server EJB コンテナによって管理されるということです。1 つのメッセージ駆動型 Bean クラスを使用することで、WebLogic Server では大量のメッセージを並行して処理するために必要に応じて複数の EJB インスタンスが作成されます。それとは対照的に、標準的な JMS メッセージング システムの場合は、サーバ全体のセッション プールを利用する MessageListener クラスを開発者が作成しなければなりません。
WebLogic Server コンテナでは、セキュリティ サービスや自動トランザクション管理など、他の標準的な EJB サービスもメッセージ駆動型 Bean に対して提供されます。 それらのサービスの詳細については、トランザクション管理とメッセージ駆動型 Bean でのトランザクション サービスの使用を参照してください。
また、メッセージ駆動型 Bean は、EJB の「一度書けば、どこにでもデプロイできる」性質からも恩恵を受けます。JMS MessageListener は特定のセッション プール、キュー、またはトピックと関連付けられますが、メッセージ駆動型 Bean はサービス リソースにとらわれずに開発できます。メッセージ駆動型 Bean のキューとトピックはデプロイメント時にのみ割り当てられ、WebLogic Server にあるリソースが利用されます。
注意: 標準の JMS リスナにはないメッセージ駆動型 Bean の 1 つの制限は、特定のメッセージ駆動型 Bean のデプロイメントが 1 つのキューまたはトピックとしか関連付けられないことです (メッセージ駆動型 Bean の呼び出しを参照)。アプリケーションにおいて、1 つの JMS コンシューマで複数のキューまたはトピックからのメッセージに対応しなければならない場合は、標準の JMS コンシューマを使用するか、または複数のメッセージ駆動型 Bean クラスをデプロイする必要があります。
メッセージ駆動型 Bean とステートレス セッション EJB との違い
メッセージ駆動型 Bean のインスタンスの動的な作成と割り当ては、ステートレス セッション EJB のインスタンスの動作にいくつかの点で似ています。ただし、メッセージ駆動型 Bean は、以下のような重要な点でステートレス セッション EJB (および他の種類の EJB) とは異なります。
注意: WebLogic Server コンテナだけが、必要に応じて Bean のインスタンスを作成し、JMS メッセージをインスタンスに渡すことによってメッセージ駆動型 Bean と直接対話します。
メッセージ駆動型 Bean (MDB) は、トピックおよびキューの並行処理をサポートしています。 以前は、キューの並行処理のみがサポートされていました。
同時実行性をサポートするには、コンテナで実行キューのスレッドを使用します。weblogic-ejb-jar.xml ファイルの max-beans-in-free-pool デプロイメント記述子のデフォルト設定では、ほとんどの並行処理がサポートされます。並行して実行されるコンシューマの数を制限する場合を除き、この値を変更しないでください。
注意: メッセージを一度に受け取るための最大 MDB 数 (max-beans-in-free-pool デプロイメント記述子要素でコンフィグレーションする) は、最大実行スレッド数を超過できません。たとえば、max-beans-in-free-pool が 50 に設定されており、最大実行スレッド数が 25 に設定されている場合、実際にメッセージを受け取る MDB は 25 個だけです。
max-beans-in-free-pool の詳細については、max-beans-in-free-poolを参照してください。
メッセージ駆動型 EJB を作成するには、Bean を適切に動作させるための一般的な慣習に従うだけでなく、JavaSoft EJB 2.0 仕様で説明されている規約にも従う必要があります。メッセージ駆動型 Bean クラスを作成したら、XML 形式の EJB デプロイメント記述子ファイルで Bean のデプロイメント記述子要素を指定することによって、WebLogic Server 用に Bean をコンフィグレーションします。
メッセージ駆動型 Bean を作成するには、次の手順に従います。
メッセージ駆動型 Bean クラスの出力例について、詳しくは メッセージ駆動型 Bean クラスの必要条件を参照してください。
XML ファイルの指定について、詳しくはEJB デプロイメント記述子の指定と編集を参照してください。
次の例は、ejb-jar.xml ファイルでのメッセージ駆動型 Bean の指定方法を示したものです。
図3-1 ejb-jar.xml ファイルの XML スタンザの例
<enterprise-beans>
<message-driven>
<ejb-name>exampleMessageDriven1</ejb-name>
<ejb-class>examples.ejb20.message.MessageTraderBean</ejb-class>
<transaction-type>Container</transaction-type>
<message-driven-destination>
<destination-type>
javax.jms.Topic
</destination-type>
</message-driven-destination>
...
</message-driven>
...
</enterprise-beans>
次の例は、weblogic-ejb-jar.xml ファイルでのメッセージ駆動型 Bean の設定方法を示したものです。
図3-2 weblogic-ejb-jar.xml ファイルの XML スタンザの例
<message-driven-descriptor>
<destination-jndi-name>...</destination-jndi-name>
</message-driven-descriptor>
コンテナは、メッセージ駆動型 Bean インスタンスを実行時に管理します。
EJB 2.0 仕様では、メッセージ駆動型 Bean クラスでメソッドを定義するための詳細なガイドラインが提供されます。次の出力は、メッセージ駆動型 Bean クラスの基本的な構成要素を示しています。クラス、メソッド、およびメソッド宣言は、太字で表示されています。
図3-3 メッセージ駆動型 Bean の基本コンポーネントの出力例
public class MessageTraderBean implements MessageDrivenBean, MessageListener{ public MessageTraderBean() {...};// EJB コンストラクタは必須。パラメータは
// 受け付けない。コンストラクタは
// abstract としては宣言しない
public void ejbCreate() (...)
// ejbCreate () は必須。パラメータは受け付けない
// throws 句を使用する場合は、アプリケーション例外を
// 含めない。ejbCreate() は final または static としては宣言しない
public void onMessage(javax.jms.Message MessageName) {...}// onMessage() は必須であり、javax.jms.Message 型の
// パラメータを必ず 1 つとる。throws 句を使用する場合は
// アプリケーション例外を含めない。onMessage() は final
// または static としては宣言しない
public void ejbRemove() {...}// ejbRemove() は必須。パラメータは受け付けない。
// throws 句を使用する場合は、アプリケーション例外を
//含めない。ejbRemove() は final または static としては宣言しない
// EJB クラスでは finalize() メソッドを定義できない
}
WebLogic Server では、setMessageDrivenContext() を呼び出して、メッセージ駆動型 Bean インスタンスをコンテナ コンテキストと関連付けます。これは、クライアント コンテキストではありません。クライアント コンテキストは、JMS メッセージでは渡されません。WebLogic Server では、コンテナ コンテキストが EJB に提供されます。そのプロパティには、MessageDrivenContext インタフェースの以下のメソッドを使用してインスタンスからアクセスできます。
注意: getEJBHome() も MessageDrivenContext インタフェースの一部として継承されますが、メッセージ駆動型 Bean にはホーム インタフェースがありません。メッセージ駆動型 EJB のインスタンスから getEJBHome() を呼び出すと、IllegalStateException が送出されます。
メッセージ駆動型 Bean の onMessage() メソッドでは、その EJB のビジネス ロジックが実装されます。WebLogic Server では、EJB と関連付けられている JMS キューまたは JMS トピックがメッセージを受信したときに、JMS メッセージ オブジェクトをそのまま引数として渡して onMessage() を呼び出します。メッセージを解析し、onMessage() の必要なビジネス ロジックを実行するのは、メッセージ駆動型 Bean の役割です。
ビジネス ロジックが非同期のメッセージ処理に対応できるようにしておきます。たとえば、EJB では、クライアントから送信された順序でメッセージを受信できるわけではありません。コンテナでのインスタンス プーリングにより、メッセージが順番に受信または処理されることはありません。ただし、メッセージ駆動型 Bean の特定のインスタンスに対する個々の onMessage() 呼び出しはシリアライズされます。
詳細については、javax.jms.MessageListener.onMessage() を参照してください。
メッセージ駆動型 Bean のメソッドは、onMessage() であっても、アプリケーション例外または RemoteException を送出してはなりません。メソッドでそのような例外が送出されると、WebLogic Server では ejbRemove() を呼び出すことなく即座に EJB のインスタンスが削除されます。ただし、クライアントの観点からすれば、その EJB は依然として存在していることになります。なぜなら、以降のメッセージは WebLogic Server によって作成される新しい Bean インスタンスに転送されるからです。
JMS キューまたは JMS トピックがメッセージを受信すると、WebLogic Server では次のようにして関連するメッセージ駆動型 Bean を呼び出します。
フリー プールに使用可能な Bean インスタンスがなく、max-beans-in-free-pool で指定された制限に達している場合、WebLogic Server は Bean インスタンスが解放されるまで待機します。 この属性の詳細については、9-60 ページの「max-beans-in-free-pool」を参照してください。
Bean インスタンスがフリー プールになく、max-beans-in-free-pool で指定された制限に達していない場合、WebLogic Server は Bean の ejbCreate() メソッドを呼び出して新しい Bean インスタンスを作成し、続けて Bean の setMessageDrivenContext() メソッドを呼び出してそのインスタンスをコンテナ コンテキストに関連付けます。 メッセージ駆動型 Bean コンテキストの使用で説明されているように、Bean ではこのコンテキストの要素を利用できます。
onMessage() によるビジネス ロジックの実装を参照してください。
WebLogic Server コンテナでは、メッセージ駆動型 Bean の ejbCreate() および ejbRemove() メソッドを呼び出して、Bean クラスのインスタンスを作成または削除します。各メッセージ駆動型 Bean には、少なくとも 1 つの ejbCreate() および ejbRemove() メソッドが必要です。WebLogic Server コンテナでは、これらのメソッドを使用して、JMS キューまたはトピックからメッセージを受信して Bean インスタンスが作成されたときに作成関数を、トランザクションがコミットされて Bean インスタンスが削除されたときに削除関数を処理します。WebLogic Server は、JMS キューまたはトピックからメッセージを受け取ります。
他の EJB タイプの場合と同じように、ejbCreate() メソッドでは Bean の活動に必要なあらゆるリソースを用意しなければなりません。ejbRemove() メソッドでは、WebLogic Server によってインスタンスが削除される前にリソースを解放しなければなりません。
メッセージ駆動型 Bean では、ejbRemove() メソッドの外側においても何らかのかたちで通常のクリーンアップ ルーチンを実行する必要があります。なぜなら、実行時例外が送出されるなどして、ejbRemove() が呼び出されないこともあり得るからです。
WebLogic Server でのメッセージ駆動型 Bean のデプロイ
メッセージ駆動型 Bean のデプロイ先は、初めて起動した場合の WebLogic Server、または実行中の WebLogic Server です。 Bean のデプロイの詳細については、WebLogic Server 起動時の EJB のデプロイメントまたは動作中の WebLogic Server への EJB のデプロイを参照してください。
メッセージ駆動型 Bean でのトランザクション サービスの使用
その他の型の EJB と同じく、メッセージ駆動型 Bean では Bean 管理のトランザクションを使用して独自のトランザクション境界を設定することも、WebLogic Server のコンテナにトランザクションを管理させる (コンテナ管理のトランザクション) こともできます。どちらの場合でも、メッセージ駆動型 Bean が、メッセージを送信するクライアントからトランザクション コンテキストを受け取ることはありません。WebLogic Server では常に、Bean のデプロイメント記述子ファイルで指定されたトランザクション コンテキストを使用して Bean の onMessage() メソッドを呼び出します。
どのクライアントでもメッセージ駆動型 Bean に対する呼び出しのためのトランザクション コンテキストは提供されないので、コンテナ管理のトランザクションを使用する Bean は ejb-jar.xml ファイルの container-transaction 要素で Required または NotSupported trans-attribute を指定してデプロイする必要があります。
ejb-jar.xml ファイルの次の例は、メッセージ駆動型 Bean のトランザクション コンテキストの指定方法を示しています。
図3-4 ejb-jar.xml ファイルの XML スタンザの例
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>MyMessageDrivenBeanQueueTx</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
</assembly-descriptor>
EJB の onMessage() メソッドを呼び出すきっかけとなる JMS メッセージの受信は、通常はトランザクションのスコープには含まれません。ただし、Bean 管理のトランザクションとコンテナ管理のトランザクションに関しては別の方法で処理されます。
コンテナ管理によるトランザクションの境界設定を使用するメッセージ駆動型 Bean の場合は、EJB トランザクションがコミットされたときに WebLogic Server で自動的にメッセージの確認応答が行われます。 EJB で Bean 管理のトランザクションが使用される場合、メッセージの受信と確認応答は両方とも EJB トランザクション コンテキストの外側で行われます。Bean 管理のトランザクションを使用する EJB では WebLogic Server によって自動的にメッセージの確認応答が行われますが、ejb-jar.xml ファイルで定義される acknowledge-mode デプロイメント記述子要素を使用して確認応答のセマンティクスをコンフィグレーションできます。
WebLogic Server では、メッセージ駆動型 Bean の移行と回復のサービスをサポートします。移行と回復のサービスを提供するため、WebLogic JMS では WebLogic Server が提供する移行フレームワークに則って移行の要求に応え、障害発生後に JMS サーバをオンラインに戻します。JMS サーバを使用可能なサーバに移行する際には、関連付けられているメッセージ駆動型 Bean を障害サーバから同じ WebLogic Server クラスタ内の使用可能なサーバに手動で移行する必要があります。メッセージ駆動型 Bean はクラスタ化されたサーバ間でのみ移行サービスを利用できます。移行サービスは複数のクラスタ間をまたいで利用できません。
WebLogic Server が JMS サーバとともにメッセージ駆動型 Bean をクラスタ内の使用可能なサーバに移行しないとすれば、JMS 送り先にメッセージが溢れることになります。元のサーバが回復するまでの間、メッセージ駆動型 Bean を円滑に回復するために、メッセージ駆動型 Bean ではそれ自身が移行可能なことをマークし、WebLogic Server は移行サービス プロセスを実装します。Bean を他のサーバに移行した後、そのサーバは JMS サーバに接続し、障害サーバの代わりに JMS 送り先からメッセージのプルを再開します。
メッセージ駆動型 Bean の移行サービスを有効化するには、次の手順に従います。
この手順については、「分散送り先のコンフィグレーション」を参照してください。
WebLogic Server クラスタ内において、障害サーバから使用可能なサーバにメッセージ駆動型 Bean を移行するには、次の手順に従います。
メッセージ駆動型 Bean は JMS サーバの移行先を調べることができるので、メッセージ駆動型 Bean に対して移行先を変更する必要はありません。
しかし、メッセージ駆動型 Bean はクラスタ内、あるいは、JMS サーバの移行先リストにあるすべてのサーバ上にデプロイされる必要があります。 メッセージ駆動型 Bean は移行の間、有効でないためです。 メッセージ駆動型 Bean は移行先リストに含まれるすべてのサーバ上に JMS 送り先とともにデプロイされ、JMS 送り先が非アクティブな間は非アクティブなままです。
WebLogic Server は、メッセージ駆動型 Bean をアクティブにした時点で JMS サーバを探索し、その Bean に指定された JMS 送り先からメッセージのプルを開始します。
非 BEA JMS プロバイダのメッセージ駆動型 Bean のコンフィグレーション
IBM MQSeries などの非 BEA JMS プロバイダで機能するように、メッセージ駆動型 Bean をコンフィグレーションすることができます。 WebLogic Server 7.0 以降、Bean 管理によるトランザクションをサポートする MDB (トランザクション非対応 MDB) に加えて、コンテナ管理によるトランザクションをサポートする MDB (トランザクション対応 MDB) に関してこのコンフィグレーションが可能です。
つまり、トランザクション MDB のあるアプリケーションは、MDB によって処理されるメッセージに関して非 BEA JMS プロバイダとの間で「かならず 1 回」のセマンティクスを実現できます。WebLogic Server は XA を使用して、非 BEA JMS プロバイダをトランザクションの中に自動的に取得します。
トランザクション非対応 MDB のあるアプリケーションの場合、MDB は少なくとも 1 回のメッセージ処理セマンティクスを提供し、XA は必要ありません。
非 BEA JMS プロバイダが XA をサポートしていない場合、そのプロバイダではコンテナ管理によるトランザクションをサポートする MDB をデプロイすることはできません。 また、JMS プロバイダが XA をサポートしている場合は、weblogic-ejb-jar.xml ファイル内で指定する JMS 接続ファクトリが XA をサポートするということを保証する必要があります。この指定方法は、各 JMS プロバイダでさまざまです。
MDB をトランザクション対応として指定するには、次の手順に従います。
また、非 BEA JMS プロバイダに合わせて weblogic-ejb-jar.xml ファイルの destination-jndi-name、initial-context-factory、provider-url、および connection-factory-jndi-name 要素を適切に設定します。
トランザクション対応 MDB の場合、connection-factory-jndi-name で指定された JMS 接続ファクトリが JMS に対するオプションの XA 拡張をサポートしている必要があります。
MDB をトランザクション非対応として指定するには、次の手順に従います。
非 BEA プロバイダを使用するための MDB のコンフィグレーションの方法の例については、ホワイト ペーパー「Using Foreign JMS Providers with WLS Message Driven Beans」 (jmsmdb.pdf) を参照してください。
JMS サーバまたは非 BEA サービス プロバイダへの再接続
メッセージ駆動型 Bean は、非クラスタ WebLogic Server インスタンスまたは非 BEA サービス プロバイダにデプロイされている JMS サーバの JMS 送り先をリスンします。 サーバがダウンしたためにその送り先との接続が失われた場合、メッセージ駆動型 Bean は一定の間隔で送り先との再接続を試みます。 この間隔は、Bean の weblogic-ejb-jar.xml ファイルの jms-polling-interval-seconds 要素を設定して秒単位で指定します。
JMS 分散送り先でリスンするための MDB のコンフィグレーション
WebLogic JMS では、1 つの分散送り先セットのメンバーとして複数の物理的送り先 (キューおよびトピック) をコンフィグレーションできるため、クラスタ内の WebLogic Server インスタンスで障害が発生してもサービスを継続することができます。このようにコンフィグレーションすると、プロデューサおよびコンシューマは、1 つの送り先のように見える送り先を介してメッセージを送受信します。
しかし実際には、メッセージングの負荷が分散送り先内のすべての送り先メンバーに分散されます。サーバの障害などによって使用できない送り先メンバーがある場合は、セット内の他の送り先メンバーにトラフィックがリダイレクトされます。
このリリースから、MDB がクラスタ内のサーバにデプロイされると、WebLogic Server は分散送り先のメンバーを自動的に列挙し、MDB が各メンバーで必ずリスンするようにします。
MDB がクラスタ内のサーバにデプロイされると、WebLogic Server は分散送り先のメンバーを自動的に列挙し、MDB が各メンバーで必ずリスンするようにします。
次の手順に従って、分散送り先に対してメッセージ駆動型 Bean をコンフィグレーションします。
デプロイ時に、MDB は WebLogic Server インスタンス上に存在する分散送り先のメンバーを検出し、自身をそのメンバーに固定し、メッセージの処理を開始します。
メッセージ駆動型 Bean のセキュリティ ID のコンフィグレーション
メッセージ駆動型 Bean (MDB) が JMS キューまたはトピックからメッセージを受信する場合、EJB コンテナは資格マッピング プロバイダおよび資格マップを使用して、JMS 接続を確立するときに使用するセキュリティ ID (ユーザ名とパスワード) を取得します。 資格マッピングは、MDB 開始時の 1 回だけ行われます。 EJB コンテナが接続すると、JMS プロバイダはセキュリティ ID を使用して、すべてのメッセージを取得します。 セキュリティ ID は、MDB を使用して非 BEA JMS プロバイダ (別のベンダの JMS プロバイダまたは別の WebLogic Server ドメイン内で動作している WebLogic Server JMS プロバイダ) からメッセージを受信するときに特に重要です。
MDB のセキュリティ ID をコンフィグレーションするには、次の手順に従います。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||