WebLogic Server FAQ 集
|
 |
 |
|
J2EE 標準の JMS (メッセージング)、JTA (トランザクション)、および JNDI (ネーミング) は連携して、異なるホスト マシンや異なるベンダ間に信頼性のある Java-to-Java メッセージングを提供します。BEA WebLogic Server には、これらの API を活用してリモート JMS プロバイダとローカル アプリケーションとの統合を支えるさまざまな機能が用意されています。
以下の節では、WebLogic Server とリモート JMS プロバイダの統合に関する情報を示します。
A. リモート JMS プロバイダとは、ローカルのスタンドアロン WebLogic Server の外側、または WebLogic Server クラスタの外側でホストされている JMS サーバのことです。リモート JMS サーバは、WebLogic JMS サーバでも、WebLogic 以外の (外部) JMS サーバでもかまいません。
A. JNDI (Java Naming and Directory Interface) は、名前をサービスやリソースにマッピングする J2EE のルックアップ サービスです。JNDI によって、スタンドアロンの (クラスタ化されていない) 特定の WebLogic Server または WebLogic Server クラスタに存在する、公開されたサービスのディレクトリが提供されます。リソースの例としては、JMS 接続ファクトリ、JMS 送り先、JDBC (データベース) データ ソース、および EJB アプリケーションがあります。
クライアントは、WebLogic クラスタ内のいずれかの WebLogic Server に接続すると、そのクラスタ内の WebLogic Server にホストされていて、JNDI によって公開されているサービスやリソースであれば、どれでも透過的に参照することができます。クライアントでは、目的のリソースがクラスタ内のどの WebLogic Server でホストされているのかを明示的に調べる必要はありません。
A. JMS 接続ファクトリは、JNDI に格納されている名前付きのエンティティ リソースです。アプリケーション、メッセージ駆動型 Bean (MBD)、およびメッセージング ブリッジは、JNDI で JMS 接続ファクトリをルックアップし、その接続ファクトリを使用して JMS 接続を作成します。JMS 接続は、メッセージの送受信ができる JMS セッション、プロデューサ、およびコンシューマの作成に使用されます。
A. JMS 接続 ID は、JMS クライアント接続に名前を付ける際に使用されます。恒久サブスクライバは名前付きの接続を要求します。それ以外の場合、通常は接続には名前がありません。クラスタ化されたサーバ群またはスタンドアロン サーバでは、1 度に 1 つの JMS クライアント接続のみが、名前付きの接続を使用できます。既存の接続と同じ名前で新しい接続を作成しようとすると、失敗します。
A. JMS キューは 1 つのメッセージを 1 つのコンシューマに配信します。これに対し JMS トピックは、メッセージのコピーを複数のコンシューマのそれぞれに 1 つずつ配信します。
A. トピック サブスクリプションは、特定のサブスクライバへの配信を待つメッセージの内部的なキューであると考えることができます。この内部的なキューには、サブスクリプションが作成されてから、トピックにパブリッシュされた各メッセージのコピーが蓄積されます。つまり、そのサブスクリプションが作成される前に送信されたメッセージは蓄積されません。サブスクリプションを共有することはできません。1 度に 1 つのサブスクライバのみが、特定のサブスクリプションにサブスクライブできます。
A. 非恒久サブスクライバは、JMS クライアントの生存期間中にのみ存在する、名前のないサブスクリプションを作成します。メッセージのパブリッシャで永続的なサービスの品質 (QOS) が指定されている場合でも、非恒久サブスクリプションにあるメッセージは永続化されません。JMS サーバを停止すると、すべての非恒久サブスクリプションが終了します。
A. 恒久サブスクライバは名前付きのサブスクリプションを作成します。このサブスクリプションは、恒久サブスクライバの終了後やサーバの再起動後にも存在し続けます。恒久サブスクライバは、トピック名、接続 ID、およびサブスクライバ ID を指定して、サブスクリプションに接続します。接続 ID とサブスクライバ ID を一緒に指定することで、クラスタ内のサブスクライバのサブスクリプションが特定されます。トピックにパブリッシュされた永続メッセージのコピーは、各トピックの恒久サブスクリプションで永続化されます。サーバがクラッシュしたり再起動したりした場合、恒久サブスクリプションとその中にある消費されていない永続メッセージは回復されます。
A. トランザクションとは、アプリケーションの個別の処理の集まりで、最小の単位として扱う必要のあるものです。一貫性を保つために、1 つのトランザクションのすべての処理がすべて成功するか、すべて失敗する必要があります。『WebLogic JTA プログラマーズ ガイド』の「トランザクションについて」を参照してください。
Q. なぜトランザクションは統合にとって重要なのでしょうか。
A. 統合アプリケーションではデータの一貫性を保証するためにトランザクションを使用することがよくあります。たとえば、メッセージが正確に 1 回だけ転送されるように、ソース送り先からのメッセージの受信とターゲット送り先への送信という 2 つの処理を含む 1 つのトランザクションを使用します。また、データベースの更新やメッセージング処理の実行の原子性を確保するためにトランザクションがよく使用されます。
Q. JTA/XA/グローバル トランザクションとは何ですか。
A. J2EE では、1 つのグローバル トランザクションを指して、JTA トランザクション、XA トランザクション、ユーザ トランザクション、およびグローバル トランザクションという語が交互に用いられています。1 つのトランザクションには、複数の異なる XA 対応リソースや異なるリソース タイプに対する処理が含まれていることがあります。 JTA トランザクションは常に現在のスレッドに関連付けられており、あるアプリケーションが別のアプリケーションを呼び出すと、サーバからサーバに渡されます。XA トランザクションの一般的な例としては、WebLogic JMS の処理と JDBC (データベース) の処理の両方とも含まれているトランザクションがあります。
A. JMS ローカル トランザクションは、1 つのリソースまたは 1 つのサービスのみが参加できるトランザクションです。JMS ローカル トランザクションは、1 つのベンダの送り先が参加する特定の JMS セッションに関連付けられています。XA トランザクションとは異なり、データベース処理は JMS ローカル トランザクションには参加できません。
Q. JMS ではローカル トランザクションをどのように実現していますか。
A. ローカル トランザクションは、トランザクション セッション (transacted session) という JMS 固有の API によって有効になります。WebLogic JMS 以外のベンダの場合、トランザクション セッションのスコープは通常 1 つの JMS サーバに限定されています。WebLogic JMS では、クラスタ内の複数の送り先での複数の JMS 処理を、1 つのトランザクション セッションのトランザクションに参加させることができます。つまり、スコープは WebLogic クラスタに設定されており、その JMS セッションのクラスタにとってリモートの JMS プロバイダは、トランザクションに参加できません。JMS トピック ページから入手できるホワイト ペーパー「WebLogic JMS Performance Guide」を参照してください。
Q. JMS ローカル トランザクションは統合に役立ちますか。
A. ローカル トランザクションは、1 つのリソース (通常はメッセージング サーバやデータベース サーバ) にスコープが限定されているため、一般に統合には役立ちません。
A. 以下の条件を満たす場合、データベース サーバやメッセージング サーバなどのリソースに対する処理は、J2EE JTA トランザクションに参加します。
XA 対応リソースに対する処理をトランザクションに自動的に参加させることを、専門用語で「自動登録」といいます。
外部ベンダの自動登録を行える JMS の機能には次のようなものがあります。
WebLogic 以外のベンダの JMS 接続ファクトリが XA 対応かどうかを確認するには、ベンダのドキュメントを参照してください。トランザクション セッション (ローカル トランザクション) をサポートしていても、グローバル/XA トランザクションをサポートしているとは限らないことに注意してください。
Q. リモート JMS プロバイダと通信するために JMS クライアントは何をしますか。
A. JMS プロバイダと通信するには、JMS クライアントは以下の手順を実行する必要があります。
Q. リモート JMS プロバイダとの通信を設定するために必要な情報は何ですか。
A. リモート JMS プロバイダとの通信を設定するには、以下の情報が必要になります。
t3://hostaddress:port になります。HTTP 上でトンネリングしている場合は、URL の先頭を t3 ではなく http にします。サーバ アプリケーション コードが、同じ WebLogic Server または WebLogic クラスタ上に存在する WebLogic JMS サーバにアクセスする場合、URL は必要ありません。JMS アプリケーションでトランザクションが必要な場合は、接続ファクトリを XA 対応にする必要があります。 WebLogic のドキュメントでは、XA 対応ファクトリのことをユーザ トランザクション対応と呼んでいます。
WebLogic Server にはデフォルトで以下の 3 つの接続ファクトリが用意されています。この接続ファクトリはコンフィグレーションできません。
Q. 外部 JMS プロバイダの JNDI サービスで機能が制限されている場合はどうしますか。
A. JMS プロバイダの接続ファクトリと送り先を検索する最適な方法は、標準の J2EE JNDI ルックアップを使用することです。WebLogic 以外の JMS プロバイダの JNDI サービスは、使いやすくなかったり、信頼性がない場合があります。解決策としては、WebLogic Server 上で動作する起動クラスまたは起動時にロードされるサーブレットを作成して、以下の処理を行います。
サンプル コードについては、JMS トピック ページから入手できるホワイトペーパー「Using Foreign JMS Providers with WebLogic Server」の「Creating Foreign JNDI Objects in a Startup Class」を参照してください。
Q. JMS リソースをプールするにはどうすればよいですか。
A. クライアント接続やセッションなどのリモートおよびローカルの JMS リソースは、パフォーマンスを向上するためにプールされることがよくあります。メッセージ駆動型 EJB では内部の JMS コンシューマを自動的にプールしています。リソース参照を介してアクセスされる JMS コンシューマおよびプロデューサも自動的にプールされます。カスタム プールの記述方法などリソース プールの詳細については、JMS トピック ページから入手できるホワイトペーパー「BEA WebLogic JMS Performance Guide」を参照してください。
Q. WebLogic ではバージョン間の相互運用性はどのようになっていますか。
A. WebLogic Server 6.1 以降のすべてのリリースは、リリース間で支障なく相互運用します。たとえば、WebLogic 8.1 の JMS クライアントは、6.1 の JMS サーバにメッセージを直接送信できます。また、この逆も可能です。メッセージング ブリッジを使用すると、WebLogic 5.1 の JMS メッセージを WebLogic Server 6.1 以降のリリースとの間でやり取りできます。
Q. リモート JMS プロバイダと統合するにはどのような方法がありますか。
A. 以下の表に、リモート JMS プロバイダと統合する際の方法をまとめました。
Q. EJB またはサーブレットでリモート JMS プロバイダからメッセージを受信するにはどうすればよいですか。
A. メッセージ駆動型 EJB を使用してください。同期的な受信はお勧めしません。同期的な受信の場合、メッセージを待機して受信者がブロックされている間、サーバサイド スレッドがアイドル状態になるためです。「メッセージ駆動型 EJB (MDB) とは何ですか。」および「MDB はどのような場合に使用するのですか。」を参照してください。
Q. EJB またはサーブレットからリモート JMS プロバイダにメッセージを送信するにはどうすればよいですか。
A. リソース参照を使用してください。リソース参照では、プールと自動登録を行えます。「JMS リソース参照とは何ですか。」および「JMS リソース参照の利点は何ですか。」を参照してください。ラッパーでは不十分な場合は、プールを行うコードを独自に作成してもかまいません。JMS トピック ページで入手できるホワイト ペーパー「BEA WebLogic JMS Performance Guide」を参照してください。
ターゲット送り先がリモートの場合は、ローカル送り先とメッセージング ブリッジを追加して、ストア アンド フォワード方式の可用性の高い設計を実装することも検討してください。「メッセージング ブリッジとは何ですか。」および「メッセージング ブリッジはどのような場合に使用するのですか。」を参照してください。
もう 1 つのベスト プラクティスは外部 JMS サーバ定義を使用することです。外部 JMS サーバ定義を使用すると、アプリケーションの JMS リソースを管理者が変更できるため、アプリケーション コードに URL をハードコード化する際の問題を避けることができます。また、外部 JMS サーバ定義では、リソース参照にリモート JMS プロバイダを参照させる必要があります。「外部 JMS サーバ定義とは何ですか。」および「外部 JMS サーバ定義はどのような場合に使用するのですか。」を参照してください。
Q. クライアントからリモート JMS プロバイダと通信するにはどうすればよいですか。
A. WebLogic Server で送り先が用意されておらず、送り先に対する処理をグローバル トランザクションに含める必要がある場合は、サーバ プロキシを使用して、外部ベンダに対する EJB の JMS 処理をカプセル化します。WebLogic Server 上で動作するアプリケーションには、トランザクション (XA) 対応の非 WebLogic JMS プロバイダを現在のトランザクションに登録する機能があります。「EJB またはサーブレットでリモート JMS プロバイダからメッセージを受信するにはどうすればよいですか。」および「EJB またはサーブレットからリモート JMS プロバイダにメッセージを送信するにはどうすればよいですか。」を参照してください。
ストア アンド フォワード機能が必要な場合は、ローカル送り先にメッセージを送信し、メッセージング ブリッジを使用して外部送り先に転送する方法を検討してください。「メッセージング ブリッジとは何ですか。」および「メッセージング ブリッジはどのような場合に使用するのですか。」を参照してください。
これ以外に、リモート ベンダの JNDI と JMS API を直接使用する方法や、参照をハードコード化しないように外部 JMS プロバイダをコンフィグレーションする方法もあります。外部プロバイダのクラス ライブラリをクライアントのクラスパスに追加してください。
Q. WebLogic JMS の相互運用性機能をチューニングするにはどうすればよいですか。
A. メッセージ駆動型 EJB と WebLogic メッセージング ブリッジのチューニングについては、JMS トピック ページで入手できるホワイトペーパー「BEA WebLogic JMS Performance Guide」を参照してください。
A. 外部 JMS サーバ定義とは、JMS 接続ファクトリや送り先オブジェクトのようなリモート JNDI ディレクトリ内の JNDI オブジェクトと、スタンドアロンの WebLogic Server または WebLogic クラスタの JNDI 名空間にある JNDI 名との間のシンボリック リンクのことで、管理者によってコンフィグレーションされます。Administration Console や標準の JMX MBean API を使用したり、プログラム的にスクリプトを使用してコンフィグレーションできます。Administration Console オンライン ヘルプの「リモートまたは外部 JMS プロバイダへの単純なアクセス」を参照してください。
Q. 外部 JMS サーバ定義はどのような場合に使用するのですか。
A. このリリースでは、外部 JMS サーバ定義を使用して、JMS JNDI パラメータを使いやすく 1 箇所にまとめることができます。1 つの定義を EJB、サーブレット、およびメッセージング ブリッジの間で共有できます。デプロイメント記述子を再コンパイルしたり変更したりせずに、定義を変更することができます。特に次のような場合に便利です。
A. リソース参照はサーブレットや EJB アプリケーションの開発者が指定し、アプリケーションと一緒にパッケージ化されるものです。アプリケーションで、JNDI 名をソース コードに直接ハードコード化せずに、EJB 記述子に定義された JNDI 名を参照できるという間接的で使いやすい方法です。
JMS リソース参照にはこれ以外に 2 つの機能があります。
EJB またはサーブレット アプリケーション コードで JMS リソース参照を使用するには、デプロイメント記述子に resource-ref 要素を指定しておきます。JNDI コンテキストを使用し、java:comp/env/jms/<reference name> という構文で JMS リソース参照をルックアップします。
リソース参照はアプリケーション コードの外側には何の機能も提供しないため、メッセージ駆動型 Bean のソース送り先やメッセージング ブリッジのソースまたはターゲット送り先をコンフィグレーションする際には役に立ちません。
JMS リソース参照のプールに関する WebLogic のドキュメントについては、『WebLogic JMS プログラマーズ ガイド』の「EJB とサーブレットでの JMS の使い方」を参照してください。
Q. 外部 JMS プロバイダでリソース参照はどのように使用するのですか。
A. リソース参照にリモート JMS プロバイダを参照させるには、外部 JMS 定義を一緒に使用する必要があります。リソース参照には URL または初期コンテキスト ファクトリを指定する手段がないためです。「外部 JMS サーバ定義とは何ですか。」を参照してください。
Q. 非トランザクション メッセージングではリソース参照をどのように使用するのですか。
A. トランザクションを行わない場合は、メッセージングのパフォーマンスに影響を与えるので、グローバル トランザクション (XA) 対応の接続ファクトリを使用しないでください。使用した場合、リソース参照はメッセージング処理が行われるたびに、自動的に内部トランザクションを開始してコミットします。「トランザクションとは何ですか。」を参照してください。
A. メッセージング ブリッジは WebLogic Server で動作するサービスであり、管理者がコンフィグレーションします。コンフィグレーション済みのソース JMS 送り先からターゲット JMS 送り先にメッセージを自動的に転送します。送り先は、ブリッジとは別のサーバ上にあっても、外部の (WebLogic 以外の) 送り先であってもかまいません。各ブリッジ送り先は、リモート プロバイダの一般的な 4 つのプロパティを使用してコンフィグレーションします。
トランザクションを使用するようにメッセージング ブリッジをコンフィグレーションして、XA 対応 (グローバル トランザクション対応) の JMS プロバイダから別の所にメッセージが必ず 1 回転送されるようにすることができます。
Q. メッセージング ブリッジはどのような場合に使用するのですか。
A. 通常、メッセージング ブリッジはストア アンド フォワード方式の可用性の高い設計を実現するために使用します。コンフィグレーションされたメッセージング ブリッジは、送信側のローカルの送り先からメッセージを受け取り、リモートにある実際のターゲット送り先にそのメッセージを転送します。この方法では、リモートのターゲット送り先がアクセス不能の状態でも、送信側はローカルの送り先にメッセージを送信できるため、可用性が高くなります。リモートのターゲット送り先がアクセス不能の場合は、その送り先が再びアクセス可能になり、ブリッジがメッセージを転送できるようになるまで、ローカルの送り先が自動的にメッセージを保存します。
Q. どのような場合にメッセージング ブリッジの使用を避けるべきですか。
A. メッセージ駆動型 EJB は、標準の JMS API を内部的に使用して、ローカル、リモート、または外部の JMS 送り先からメッセージを非同期的に受信し、アプリケーション コードを呼び出してそのメッセージを処理する EJB コンテナです。MDB には以下のような特性があります。
onMessage() に含まれています。 詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照してください。
A. MDB は、JMS メッセージを受信して処理する WebLogic Server アプリケーションに適したメカニズムです。
Q. MDB でメッセージング ブリッジを使用する必要はありますか。
A. MDB と送り先の間にメッセージング ブリッジを挿入するよりも、ソース送り先から直接メッセージを受け取るように MDB をコンフィグレーションしてください。ソース送り先がアクセス不能の場合、MDB はソース送り先への接続を自動的に再試行します。したがって、可用性を高めるために、メッセージ パスにメッセージング ブリッジを挿入する必要はありません。メッセージング ブリッジを導入するとパフォーマンスに影響を与える可能性があります。「どのような場合にメッセージング ブリッジの使用を避けるべきですか。」を参照してください。
Q. MDB の最適なコンフィグレーション方法を教えてください。
A. MDB のコンフィグレーションに関するヒントを以下に示します。
max-beans-in-free-pool および dispatch-policy 記述子フィールドを使用します。WebLogic は、MDB のスレッド プールにある使用可能なサーバ スレッドの数に応じて、max-beans-in-free-pool よりも少ない数のインスタンスを同時に作成します。transaction-type が Container に、trans-attribute が Required に設定されていて、JMS 接続ファクトリが XA 対応である場合、MDB はコンテナ管理の XA トランザクションをサポートします。この手順を行っていないと、MDB はトランザクション対応にはなりません。WebLogic のデフォルトの設定では、MDB 接続ファクトリは XA 対応です。MDB はトランザクションを自動的に開始し、受信したメッセージをトランザクションに自動的に登録します。Q. JMS の相互運用性に関するその他の情報はありますか。
A. WebLogic JMS の一般的な情報については、JMS トピック ページを参照してください。
|
|
|