|
|
JMS (メッセージング)、JTA (トランザクション)、JNDI (命名) の J2EE 標準は連携して動作し、さまざまなホスト マシン間だけではなく、ベンダ間でも信頼性のある 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 に接続するクライアントは、JNDI で公開されているすべてのサービス、またはクラスタ内のすべての WebLogic server 上でホストされているリソースを透過的に参照できます。クライアントは、クラスタ内のどの特定の WebLogic server が目的のリソースをホストするのかを明示的に知っておく必要はありません。
A. JMS 接続ファクトリは、JNDI に格納された名前を持つエンティティ リソースです。アプリケーション、メッセージ駆動型 Bean (MDB) およびメッセージング ブリッジは、JNDI の JMS 接続ファクトリをルックアップして、JMS 接続の作成に利用します。次に JMS 接続を使用してメッセージを送受信できる JMS セッション、プロデューサ、およびコンシューマを作成することができます。
A. JMS 接続 ID は、JMS クライアント接続の命名に使用します。恒久サブスクライバには名前の付いた接続が必要です。通常は接続に名前がありません。クラスタ化された一連のサーバまたはスタンドアロン サーバ内で、特定の名前が付いた接続を使用できるのは、1 つの JMS クライアント接続のみです。既存の名前と同じ名前を持つ新しい接続は作成できません。
A. JMS キューは 1 つのコンシューマにメッセージを配信し、JMS トピックは各コンシューマに各メッセージのコピーを配信します。
A. トピック サブスクリプションは、特定サブスクライバへの配信を待つメッセージの内部的なキューです。この内部的なキューは、サブスクリプションの作成後にトピックに対してパブリッシュされる各メッセージのコピーを蓄積します。反対に、サブスクリプションが作成される前に送信されたメッセージは蓄積しません。サブスクリプションは共有できません。一度に特定のサブスクリプションにサブスクライブできるのは、1 人だけです。
A. 非恒久サブスクライバは、JMS クライアントの稼働時間にのみ存続する、名前のないサブスクリプションを作成します。非恒久サブスクリプションのメッセージは、メッセージのパブリッシャで永続的なサービス品質 (QOS) を指定しても保持されません。JMS サーバを停止すると、すべての非恒久サブスクリプションが停止されます。
A. 恒久サブスクライバは名前を指定したサブスクリプションを作成します。これは、恒久サブスクライバの終了後やサーバの再起動後も存在し続けます。恒久サブスクライバは、トピック名、接続 ID、およびサブスクライバ ID を指定してサブスクリプションに接続します。接続 ID、およびサブスクライバ ID を組み合わせてクラスタ内のサブスクライバのサブスクリプションにユニークな名前を付けます。トピックに対して公開された各永続的メッセージのコピーは、トピックの各恒久サブスクリプションに対して永続化されます。サーバがクラッシュ時や再起動時には、恒久サブスクリプションとその消費されていない永続的メッセージが回復されます。
A. トランザクションは個別アプリケーションのオペレーションのセットであり、最小単位として処理する必要があります。一貫性を維持するために、1 つのトランザクションに含まれるすべての処理が、すべて成功か失敗でなければなりません。詳細については、『WebLogic JTA プログラマーズ ガイド』の「 トランザクションについて」を参照してください。
A. Integration アプリケーションは、データの一貫性を確保するためにトランザクションを利用することがあります。たとえば、メッセージが確実に 1 回転送されるよう、1 つのトランザクションにソース送り先からメッセージを受信して対象送り先へ送信するという 2 つの処理を含めることがよくあります。データベース更新およびメッセージング処理の実行の原子性を確保する場合も、トランザクションがよく利用されます。
Q. JTA トランザクション、XA トランザクション、グローバル トランザクションとは
A. J2EE では、単一グローバル トランザクションを指すのに、JTA トランザクション、XA トランザクション、ユーザ トランザクション、グローバル トランザクションという用語が同じ意味で使われます。このようなトランザクションには、さまざまな XA 対応リソースやリソース タイプに対する処理までもが含まる場合があります。JTA トランザクションは常に現在のスレッドと関連付けられ、1 つのアプリケーションがほかのアプリケーションを呼び出すと、サーバからサーバへ渡されます。XA トランザクションの一般的な例として、WebLogic JMS オペレーションと JDBC (データベース) オペレーションの両方を含むトランザクションがあります。
A. JMS ローカル トランザクションは、単一のリソースまたはサービスのみが参加できるトランザクションのことです。JMS ローカル トランザクションは、単一のベンダ送り先が参加する特定の JMS セッションと関連付けられます。XA トランザクションとは異なり、データベース オペレーションは、JMS ローカル トランザクションに参加できません。
Q. JMS がローカル トランザクションを提供する方法とは
A. ローカル トランザクションは、トランザクション セッションという JMS 固有の API によって有効化されます。WebLogic JMS 以外のベンダでは、トランザクション セッションの範囲は通常、単一の JMS サーバに限られます。WebLogic JMS では、1 つのクラスタ内の複数の送り先上にある複数の JMS オペレーションは、単一のトランザクション セッションのトランザクションに参加できます。つまり、WebLogic クラスタを対象としているため、JMS セッションのクラスタに対するリモート JMS プロバイダはトランザクションに参加できません。
A. ローカル トランザクションの範囲はメッセージングやデータベース サーバなどの単一リソースに限られているため、通常は統合に利用することはできません。
A. 以下の条件を満たす場合、データベース サーバやメッセージング サーバなどのリソース上のオペレーションは J2EE JTA トランザクションに参加します。
トランザクションにおける XA 対応リソース上でのオペレーションの自動参加は、技術的には自動登録とみなされます。
外部ベンダに対する自動登録を行なう JMS 機能は以下のとおりです。
WebLogic 以外の JMS 接続ファクトリが XA 対応かどうか判断するには、ベンダが提供するドキュメントを参照してください。トランザクション セッション (ローカル トランザクション) をサポートしていても、グローバル トランザクションや XA トランザクションをサポートしているとは限りません。
Q. JMS クライアントがリモート JMS プロバイダと通信する方法とは
A. JMS プロバイダと通信するには、JMS クライアント側で以下の手順に従います。
Q. リモート JMS プロバイダと通信するために設定が必要な情報とは
A. リモート JMS プロバイダとの通信を設定するには、以下の情報が必要です。
JMS アプリケーションにトランザクションが必要な場合は、接続ファクトリが XA 対応でなければなりません。WebLogic ドキュメントでは、XA 対応ファクトリはユーザ トランザクション対応と呼ばれます。
デフォルトでは、WebLogic server は以下の 3 つのコンフィグレーション不可能な接続ファクトリを自動的に提供します。
Q. 外部 JMS プロバイダの JNDI サービス機能が制限されている場合はどうなるか。
A. JMS プロバイダ接続ファクトリおよび送り先を調べる方法としては、標準 J2EE JNDI ルックアップを使用することを推奨します。WebLogic 以外の JMS プロバイダによる JNDI サービスは、使いにくかったり、信頼性に欠ける場合があります。これを解決するには、以下の処理を行なう WebLogic server 上で動作する起動クラスまたは load-on-start サーブレットを作成します。
サンプル コードについては、「Dev2Dev」上の「Using Foreign JMS Providers with WebLogic Server」の「Creating Foreign JNDI Objects in a Startup Class」を参照してください。
A. クライアント接続とセッションなど、リモートとローカルの JMS リソースは、パフォーマンスを向上させるためにプールされることがあります。メッセージ駆動 EJB は、その内部 JMS コンシューマを自動的にプールします。リソースの参照によってアクセスされた JMS コンシューマとプロデューサも自動的にプールされます。カスタム プールの書き込みなど、リソース プーリングの詳細については、「Dev2Dev」上の『BEA WebLogic JMS Performance Guide』を参照してください。
Q. WebLogic はどのようなバージョンの相互運用を備えているか
A. WebLogic server リリース 6.1 とそれ以降のリリースはすべて、リリース間で自由に相互運用ができます。たとえば、WebLogic 8.1 JMS クライアントから 6.1 JMS サーバに直接メッセージを送信できます。JMS サーバから JMS クライアントに送信することもできます。メッセージング ブリッジを使用して、WebLogic server リリース 6.1 とその以降のリリースとの間で WebLogic 5.1 JMS メッセージを転送することができます。
Q. リモート JMS プロバイダとの統合に利用可能なツールとは
A. リモート JMS プロバイダとの統合に利用可能なツールを以下の表に示します。
Q. EJB またはサーブレット内のリモート JMS プロバイダからメッセージを受信するには
A. メッセージ駆動 EJB を使用します。同期受信は、レシーバ ブロックがメッセージを待っているときにサーバ側のスレッドをアイドルにするため、推奨しません。「Q. メッセージ駆動 EJB (MDB) とは」および「Q. MDB はいつ使用するか」を参照してください。
Q. EJB やサーブレット内のリモート JMS プロバイダからメッセージを送信するには
A. リソース参照を使用します。これは、プーリングと自動登録を提供します。「Q. JMS リソース参照とは」および「Q. JMS リソース参照の利点とは」を参照してください。ラッパが不十分な制限付きのケースでは、独自のプーリング コードを書き込み可能です。「Dev2Dev」上の『BEA WebLogic JMS Performance Guide』を参照してください。
対象送り先がリモートの場合、ストア アンド フォワードの高可用性設計を実装するため、ローカル送り先およびメッセージング ブリッジを追加してください。「Q. メッセージング ブリッジとは」および「Q. メッセージング ブリッジはいつ使用するか」を参照してください。
この他に、外部 JMS サーバ定義を使用するベスト プラクティスもあります。外部 JMS サーバ定義を使用すると、管理者がアプリケーションの JMS リソースを変更し、アプリケーション コード内の URL のハードコード化の問題を回避することができます。また、リソース参照を利用可能にしてリモート JMS プロバイダを参照するには外部 JMS サーバ定義が必要です。「Q. 外部 JMS サーバ定義とは」および「Q. 外部 JMS サーバ定義の使用に最適なタイミングとは」を参照してください。
Q. クライアントからリモート JMS プロバイダと通信するには
A. WebLogic Server から送り先が提供されず、グローバル トランザクションで送り先上の操作を含める場合は、EJB の外部ベンダ上での JMS 操作をカプセル化するためにサーバ プロキシを使用します。WebLogic server で実行中のアプリケーションは、現在のトランザクションとのトランザクション (XA) に対応する WebLogic 以外の JMS プロバイダを登録する機能があります。「Q. EJB またはサーブレット内のリモート JMS プロバイダからメッセージを受信するには」および「Q. EJB やサーブレット内のリモート JMS プロバイダからメッセージを送信するには」を参照してください。
ストア アンド フォワード機能が必要な場合、メッセージをローカルの送り先に送信し、メッセージング ブリッジを使用して外部送り先に転送してください。以下を参照してください。
単にリモート ベンダの JNDI および JMS API を直接使用するか、ハードコード化された参照を回避するために外部 JMS プロバイダをコンフィグレーションするオプションもあります。クライアントのクラスパスに外部プロバイダのクラス ライブラリを追加する必要があります。
Q. WebLogic JMS の相互運用機能をチューニングするには
A. 『WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic Server EJB のチューニング」、「WebLogic メッセージング ブリッジのチューニング」および「WebLogic JMS ストア アンド フォワードのチューニング」を参照してください。
A. 外部 JMS サーバ定義は、管理者がコンフィグレーションする、リモート JNDI ディレクトリ内の JNDI オブジェクト (JMS 接続ファクトリや送り先オブジェクト) とスタンドアロンの WebLogic Server や WebLogic クラスタに対する JNDI ネーム スペース内の JNDI 名との間のシンボリック リンクです。これらは Administration console である標準 JMX MBean API を使用するか、スクリプトを使用してプログラム的にコンフィグレーションできます。Administration Console オンライン ヘルプの「リモートまたは JMS プロバイダへの単純なアクセス」を参照してください。
A. このリリースでは、外部 JMS サーバ定義を使用して JMS JNDI パラメタを中心部にまとめて移動できます。EJB、サーブレットおよびメッセージング ブリッジの間で 1 つの定義を共有できます。デプロイメント記述子を変更したり再コンパイルしたりせずに定義に変更を加えることができます。これらは以下のような場合に特に便利です。
A. リソース参照はサーブレットと EJB アプリケーションの開発者が指定し、アプリケーションにパッケージ化されています。リソース参照は使いやすく、間接レベルを提供します。これにより、アプリケーションに直接アプリケーション ソース コードにハードコード化された JNDI 名ではなく、EJB 記述子で定義されている JNDI 名を参照させることができます。
JMS リソースのリファレンスは 2 つの追加機能を提供します。
EJB またはサ-ブレット アプリケーション コード内で、デプロイメント記述子に resource-ref 要素を含めて JMS リソース参照を使用し、次に java:comp/env/jms/<reference name> 構文を使用して JNDI コンテキストを使用してこれらの JMS リソース参照をルックアップします。
リソース参照はアプリケーション コード外では機能しないため、メッセージ駆動 EJB のソース送り先、またはメッセージング ブリッジのソースや対象送り先のコンフィグレーションには使えません。
JMS リソース参照のプーリングについては、『WebLogic JMS プログラマーズ ガイド』の「EJB やサーブレットと組み合わせた JMS の使用」を参照してください。
Q. リソース参照を外部 JMS プロバイダとどのように使用するか
A. リモート JMS プロバイダを参照するためにリソース参照を利用可能にするには、リソース参照を外部 JMS 定義と組み合わせて使用する必要があります。これは、リソースのリファレンスには、URL や初期コンテキスト ファクトリを指定する場所がないためです。「Q. 外部 JMS サーバ定義とは」を参照してください。
Q. リソース参照は非トランザクションのメッセージ処理とどのように使用するか
A. 非トランザクションの場合、グローバル トランザクション (XA) 対応の接続ファクトリを使用しないでください。この接続ファクトリはメッセージングのパフォーマンスに影響を与えます。使用すると、リソース参照が自動的に始まり、各メッセージ処理に対して内部的なトランザクションをコミットします。「Q. トランザクションとは」を参照してください。
Q. WebLogic ストア アンド フォワード サービスとは
A. WebLogic ストア アンド フォワード (SAF) サービスを使用すると、WebLogic Server で、複数の WebLogic Server インスタンスに分散されているアプリケーション間でメッセージを確実に配信することができます。たとえば、SAF サービスを利用すると、ローカルの WebLogic Server インスタンス上で動作するアプリケーション、またはローカルの WebLogic Server インスタンスに接続するアプリケーションは、リモート サーバ上の送り先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に送り先が使用不能になっている場合、メッセージはローカルのサーバ インスタンスに保存されて、リモートの送り先が使用可能になった時点で転送されます。『WebLogic ストア アンド フォワードのコンフィグレーションと管理』の「ストア アンド フォワード サービスについて」を参照してください。
Q. WebLogic ストア アンド フォワード サービスはいつ使用するか
A. WebLogic ストア アンド フォワード (SAF) サービスは、WebLogic Server 9.0 以降のドメイン間で JMS メッセージを転送する時に使用します。SAF サービスによるメッセージの配信対象間の関係は、以下のとおりです。
Q. WebLogic ストア アンド フォワード サービスが使用できないのはどのような場合か
A. 以下の状況では WebLogic ストア アンド フォワード サービスを使用できません。
A. JMS SAF クライアント機能は、WebLogic Server 9.0 で導入された JMS ストア アンド フォワード サービスをスタンドアロン JMS クライアントに拡張したものです。この機能を使用することで、(一時的なネットワーク接続の障害などが原因で) JMS クライアントが送り先にアクセスできない場合でも、JMS クライアントはサーバサイドの JMS 送り先にメッセージを確実に送信できるようになります。サーバとの接続が切断されている間、JMS SAF クライアントによって送信されたメッセージはクライアントのファイル システム上でローカルに格納され、クライアントが再接続するときに、サーバサイドの JMS 送り先に転送されます。「JMS SAF クライアントによる確実なメッセージ送信」を参照してください。
A. WebLogic 9.2 以上のドメインで JMS メッセージに対してストア アンド フォワードの高可用性を提供するときに使用します。
Q. WebLogic JMS SAF クライアントはいつ使用するか
A. WebLogic Server 9.0 以上のドメインで JMS メッセージを転送するときに使用します。
A. 「JMS SAF クライアントの使用に関する制限」を参照してください。
A. メッセージング ブリッジは管理者がコンフィグレーションするサービスで、WebLogic server 上で実行されます。メッセージング ブリッジを使って、コンフィグレーション済みソースの JMS 送り先からコンフィグレーション済み対象の JMS 送り先に自動的にメッセージを転送します。これらの送り先はブリッジとは異なるサーバ上にあり、外部 (WebLogic 以外) の送り先である可能性もあります。各ブリッジの送り先は、以下のリモート プロバイダの 4 つの共有プロパティを使用してコンフィグレーションされます。
メッセージング ブリッジは、トランザクションを使用して、XA 対応 (グローバル トランザクション対応) JMS プロバイダから他のプロバイダに 1 回だけメッセージが転送されたことを確認するようコンフィグレーションできます。
A. 通常、メッセージング ブリッジはストア アンド フォワードという高可用性の設計要件を提供するために使用します。メッセージング ブリッジは、送信者のローカルの送り先からメッセージを消費したり、送信者の実際の対象であるリモートの送り先に転送するためにコンフィグレーションされます。これにより、高可用性を提供できます。これは、送信者が対象とするリモートの送り先にアクセスできなくても、そのローカルの送り先にメッセージを送信することができるためです。リモートの送り先にアクセスできない場合、ローカルの送り先は、ブリッジが対象の送り先にアクセスできるようになり、メッセージを対象の送り先に送信するまで、そのメッセージを自動的に格納し始めます。
Q. メッセージング ブリッジの使用を避けるのはどのような場合か
A. メッセージ駆動 EJB は EJB コンテナであり、内部的に標準 JMS API を使用して、ローカルとリモートだけではなく、外部 JMS 送り先からも非同期的にメッセージを受信したり、アプリケーションのコードを呼び出してそのメッセージを処理します。MDB には以下のような特性があります。
詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照してください。
A. MDB は、JMS メッセージを受信して処理する WebLogic server アプリケーションに推奨されるメカニズムです。
Q. メッセージング ブリッジは MDB と使用する必要があるか
A. MDB はメッセージング ブリッジを MDB 間に挿入するのではなく、そのソース送り先から直接 MDB を消費するようにコンフィグレーションします。MDB は、ソース送り先にアクセスできない場合、自動的に接続を再試行するので、高可用性を実現するためにメッセージ パスにメッセージング ブリッジを挿入する必要はありません。メッセージング ブリッジを使用すると、パフォーマンスに影響を与える可能性があります。「Q. メッセージング ブリッジの使用を避けるのはどのような場合か」を参照してください。
A. 以下の節では、MDB をコンフィグレーションするためのヒントを示します。
A. WebLogic JMS に関する一般的な情報については、「メッセージングのトピック ページ」を、JMS に関する記事については、「http://dev2dev.bea.com/jms/」を参照してください。
  
|
