|
|
JMS (メッセージング)、JTA (トランザクション)、および JNDI (ネーミング) の各 Java EE 標準は、相互に連携することで、異なるホスト マシン間 (さらには異なるベンダ間) において信頼性の高い Java 対 Java メッセージングを提供します。Oracle WebLogic Server には、これらの API を利用してリモート JMS プロバイダをローカル アプリケーションに統合するための各種ツールが用意されています。
以下の節では、WebLogic Server とリモート JMS プロバイダを統合する方法について説明します。
A. リモート JMS プロバイダは、ローカルのスタンドアロン WebLogic サーバの外部、または WebLogic サーバ クラスタの外部でホストされる JMS サーバです。リモート JMS サーバとしては、WebLogic JMS サーバだけでなく、非 WebLogic (外部) JMS サーバも使用できます。
A. JNDI (Java Naming and Directory Interface) は、サービスやリソースに名前をマップする、Java EE ルックアップ サービスです。JNDI は、特定の (クラスタ化されていない) スタンドアロン WebLogic サーバ内、または WebLogic サーバ クラスタ内に存在する公開リソースのディレクトリを提供します。これらのリソースとしては、JMS 接続ファクトリ、JMS 送り先、JDBC (データベース) データ ソース、アプリケーション EJB などがあります。
WebLogic クラスタ内のいずれかの WebLogic サーバに接続しているクライアントは、クラスタ内のすべての WebLogic サーバでホストされているどの JNDI 公開サービスおよびリソースでも透過的に参照できます。クライアントは、クラスタ内の特定の WebLogic サーバについての明確な情報がなくても、そのサーバでホストされているリソースにアクセスできます。
A. JMS 接続ファクトリは、JNDI に保持されている名前付きエンティティ リソースです。アプリケーション、メッセージ駆動型 Bean (MDB)、およびメッセージング ブリッジは、JNDI 内の JMS 接続ファクトリをルックアップし、これを使用して JMS 接続を作成します。最終的には、この JMS 接続を使用して、メッセージを送信または受信するための JMS セッション、プロデューサ、およびコンシューマを作成します。
A. JMS 接続 ID は、JMS クライアント接続の命名に使用します。恒久サブスクライバでは名前付きの接続が必要になります。それ以外の場面では、接続に名前を付けることはあまりありません。なお、クラスタ化されたサーバ群内 (またはスタンドアロンのサーバ内) では、特定の名前付き接続を複数の JMS クライアントから同時に使用することはできません。また、既存の接続と同じ名前の接続を新たに作成しようとしても失敗します。
A. JMS キューは、1 つのコンシューマにメッセージを配信します。一方、JMS トピックは、複数のコンシューマにメッセージのコピーを配信します。
A. トピック サブスクリプションは、特定のサブスクライバへの配信を待機しているメッセージの内部キュー、と捉えることができます。サブスクリプションを作成すると、トピックに対してパブリッシュされた各メッセージのコピーがこの内部キューに蓄積されます。ただし、サブスクリプションが作成される前に送信されたメッセージは蓄積されません。サブスクリプションは共有できないため、複数のサブスクライバが特定のサブスクリプションを同時にサブスクライブすることはできません。
A. 非恒久トピック サブスクライバは、JMS クライアントの存続期間のみ存続する名前なしのサブスクリプションを作成します。非恒久サブスクリプション内のメッセージは永続化されることはありません。これは、メッセージのパブリッシャによって永続的なサービス品質 (QOS) が指定されている場合でも同様です。JMS サーバを停止すると、すべての非恒久サブスクリプションが終了します。
A. 恒久サブスクライバは、サーバの再起動後や恒久サブスクライバの終了後も存続する名前付きサブスクリプションを作成します。恒久サブスクライバは、トピック名、接続 ID、およびサブスクライバ ID を指定してそのサブスクリプションに接続します。クラスタ内にあるサブスクライバのサブスクリプションは、接続 ID とサブスクライバ ID の組み合わせによってユニークに命名されます。トピックに対してパブリッシュされた各永続メッセージのコピーは、そのトピックの恒久サブスクリプションに永続化されます。サーバのクラッシュや再起動が発生した場合は、恒久サブスクリプションおよびその未消費の永続メッセージが回復します。
A. トランザクションは、複数のアプリケーション操作をまとめたもので、最小単位として処理する必要のあるものです。一貫性を維持するため、トランザクション内のすべての操作は、すべてが成功するかすべてが失敗するかのどちらかでなければなりません。詳細については、『WebLogic JTA プログラマーズ ガイド』の「トランザクションについて」を参照してください。
A. アプリケーションの統合においては、トランザクションを使用してデータの一貫性を維持するのが一般的です。たとえば、メッセージが必ず 1 回のみ転送されるようにする場合には、単一のトランザクションを使用して、2 つの操作 (ソース送り先からのメッセージの受信、および対象送り先への送信) を 1 つにまとめることができます。また、トランザクションを使用することで、データベースの更新やメッセージング操作の実行における原子性を維持することもできます。
Q. JTA トランザクション、XA トランザクション、グローバル トランザクションとは何ですか。
A. Java EE では、単一のグローバル トランザクションのことを、明確に区別することなく 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 では、クラスタ内の複数の送り先での複数の JMS 操作を、単一のトランザクション セッションのトランザクションに参加させることができます。言い換えると、トランザクション セッションのスコープは WebLogic クラスタであり、その JMS セッションのクラスタの外部にあるリモート JMS プロバイダをトランザクションに参加させることはできません。
Q. JMS ローカル トランザクションは統合にも利用できますか。
A. ローカル トランザクションは、スコープが単一のリソース (たとえばメッセージング サーバやデータベース サーバ) に限定されるため、通常は統合には使用しません。
A. 自動トランザクション登録とは、以下に示す条件に基づいて、Java EE JTA トランザクションに参加するデータベース サーバやメッセージング サーバなどのリソースに対して実行する操作です。
技術的には、トランザクション内の XA 対応リソースに対する操作を自動的に参加させることを自動登録と呼びます。
外部ベンダに対して自動登録を提供するための JMS 機能は以下のとおりです。
WebLogic 以外のベンダの JMS 接続ファクトリが XA 対応かどうかは、そのベンダのドキュメントで確認してください。なお、トランザクション セッション (ローカル トランザクション) のサポートには、グローバル/XA トランザクションのサポートは含まれていません。
Q. JMS クライアントは、どのような手順でリモート JMS プロバイダと通信するのですか。
A. JMS クライアントでは、どの JMS プロバイダと通信する場合でも、次の手順を実行する必要があります。
Q. リモート JMS プロバイダとの通信を設定するためにはどのような情報が必要ですか。
A. リモート JMS プロバイダとの通信を設定するためには、以下の情報を用意する必要があります。
JMS アプリケーションでトランザクションを使用する場合は、接続ファクトリを XA 対応にする必要があります。WebLogic ドキュメントでは、XA 対応ファクトリをユーザ トランザクション対応と表現しています。
Q. 外部 JMS プロバイダの JNDI サービスの機能性に制限がある場合はどうしたらよいですか。
A. JMS プロバイダの接続ファクトリおよび送り先を特定する方法として好ましいのは、標準の Java EE JNDI ルックアップを使用する方法です。しかし、非 WebLogic JMS プロバイダの JNDI サービスは、使い勝手が悪い場合や信頼性に欠ける場合があります。この問題を解決するには、WebLogic サーバで動作する起動クラスまたは load-on-startup サーブレットを作成して、以下の処理を実行します。
Q. JMS リソースをプールする方法について教えてください。
A. リモートおよびローカルの JMS リソース (たとえば、クライアント接続およびセッション) は、プールすることでパフォーマンスを向上させることができます。メッセージ駆動型 EJB では、その内部 JMS コンシューマが自動的にプールされます。また、リソース参照によってアクセスする JMS コンシューマおよびプロデューサも自動的にプールされます。
Q. WebLogic で提供されるバージョン相互運用性について教えてください。
A. リリース 8.1 以降のすべての WebLogic サーバでは、異なるバージョン間での相互運用が完全にサポートされています。たとえば、WebLogic 10.0 JMS クライアントと WebLogic 8.1 JMS サーバの間でメッセージを送受信できます。
Q. リモート JMS プロバイダを統合するためのツールは用意されていますか。
A. 次の表に、リモート JMS プロバイダを統合するために使用できるツールをまとめます。
Q. EJB またはサーブレット内でリモート JMS プロバイダからメッセージを受信するにはどうしたらよいですか。
A. メッセージ駆動型 EJB を使用します。ただし、同期受信では、レシーバがメッセージの待機をブロックしている間、サーバ サイド スレッドがアイドル状態になるためお勧めできません。「Q. メッセージ駆動型 EJB (MDB) とは何ですか。」および「Q. MDB はどのような場合に使用すべきですか。」を参照してください。
Q. EJB またはサーブレット内からリモート JMS プロバイダにメッセージを送信するにはどうしたらよいですか。
A. リソース参照を使用します。リソース参照を使用することで、リソース プーリングと自動登録が可能になります。「Q. JMS リソース参照とは何ですか。」および「Q. JMS リソース参照を使用する利点は何ですか。」を参照してください。ラッパーが十分でない場合は、独自のプーリング コードを記述できます。
対象送り先がリモートである場合は、ローカル送り先とメッセージング ブリッジを追加して、ストア アンド フォワードによる高可用設計を実装することを検討してください。「Q. メッセージング ブリッジとは何ですか。」および「Q. メッセージング ブリッジはどのような場合に使用すべきですか。」を参照してください。
もう 1 つのベスト プラクティスは、外部 JMS サーバ定義を使用する方法です。外部 JMS サーバ定義を使用すると、アプリケーションの JMS リソースを管理的に変更できるため、アプリケーション コードに URL をハードコード化するのを避けることができます。また、リモート JMS プロバイダを参照するためのリソース参照を有効にする場合には、外部 JMS サーバ定義が必要になります。「Q. 外部 JMS サーバ定義とは何ですか。」および「Q. 外部 JMS サーバ定義を使用するのが最適なのはどのような場合ですか。」を参照してください。
Q. クライアントからリモート JMS プロバイダと通信するにはどうしたらよいですか。
A. 送り先が WebLogic Server によって提供されたものでなく、グローバル トランザクションないの送り先での操作を含める必要がある場合は、EJB 内の外部ベンダでの JMS 操作をサーバ プロキシを使用してカプセル化します。WebLogic サーバで実行されているアプリケーションは、現在のトランザクションにおいてトランザクション (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 サーバ定義は、管理的にコンフィグレーションされたシンボリック リンクです。スタンドアロンの WebLogic サーバや WebLogic クラスタにおいては、この外部 JMS サーバ定義によって、リモート JNDI ディレクトリ内の JNDI オブジェクト (JMS 接続ファクトリ、送り先オブジェクトなど) と、JNDI ネームスペース内の JNDI 名との間をリンクさせています。外部 JMS サーバ定義をコンフィグレーションするには、Administration console または標準の JMX MBean API を使用します。また、スクリプトを使用して、プログラム的にコンフィグレーションすることも可能です。「リモートまたは外部 JMS プロバイダへのアクセスの簡略化」を参照してください。
Q. 外部 JMS サーバ定義を使用するのが最適なのはどのような場合ですか。
A. このリリースでは、外部 JMS サーバ定義を使用することで、JMS JNDI パラメータを 1 箇所にまとめることができます。1 つの定義を、複数の EJB、サーブレット、およびメッセージング ブリッジで共有できます。定義を変更する場合にも、デプロイメント記述子を再コンパイルしたり変更したりする必要はありません。外部 JMS サーバ定義は、以下の場合には特に便利です。
A. リソース参照は、サーブレットおよび EJB アプリケーションの開発者が指定し、アプリケーションにパッケージ化するものです。リソース参照を使用すると、一定レベルの間接性を簡単に実現できます。つまり、JNDI 名をアプリケーションのソース コードに直接ハードコード化する代わりに、EJB 記述子に定義した JNDI 名をアプリケーションから参照することが可能になります。
EJB またはサーブレットのアプリケーション コード内で JMS リソース参照を使用するには、デプロイメント記述子に resource-ref 要素を追加し、JNDI コンテキストを使用して java:comp/env/jms/<参照名> という構文で参照をルックアップします。
リソース参照の機能は、アプリケーション コードの外部には提供されません。したがって、メッセージ駆動型 EJB のソース送り先のコンフィグレーションや、メッセージング ブリッジのソース送り先または対象送り先のコンフィグレーションには使用できません。
JMS リソース参照のプーリングの詳細については、「WebLogic JMS を EJB やサーブレットと組み合わせて使用するために拡張されたサポート」を参照してください。
Q. 外部 JMS プロバイダでは、リソース参照をどのように使用したらよいですか。
A. リソース参照でリモート JMS プロバイダを参照できるようにするには、リソース参照と外部 JMS 定義を組み合わせて使用する必要があります。これは、リソース参照には、URL や初期コンテキスト ファクトリを指定する場所が用意されていないためです。「Q. 外部 JMS サーバ定義とは何ですか。」を参照してください。
Q. 非トランザクション メッセージングでは、リソース参照をどのように使用したらよいですか。
A. 非トランザクションの場合は、グローバル トランザクション (XA) 対応の接続ファクトリは使用しないでください。使用した場合は、リソース参照が各メッセージング処理の内部トランザクションを自動的に開始およびコミットし、メッセージングのパフォーマンスに影響を及ぼします。「Q. トランザクションとは何ですか。」を参照してください。
Q. WebLogic ストア アンド フォワード サービスとは何ですか。
A. WebLogic Server で WebLogic ストア アンド フォワード (SAF) サービスを使用すると、複数の WebLogic Server インスタンスに分散されているアプリケーション間でメッセージを確実に配信することができます。たとえば、SAF サービスを利用すると、ローカルの WebLogic Server インスタンス上で動作するアプリケーション、またはローカルの WebLogic Server インスタンスに接続するアプリケーションは、リモート サーバ上の送り先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に送り先が使用不能になっている場合、メッセージはローカルのサーバ インスタンスに保存されて、リモートの送り先が使用可能になった時点で転送されます。『WebLogic ストア アンド フォワードのコンフィグレーションと管理』の「ストア アンド フォワード サービスについて」を参照してください。
Q. WebLogic ストア アンド フォワード サービスはどのような場合に使用すべきですか。
A. WebLogic ストア アンド フォワード (SAF) サービスは、WebLogic Server 9.0 以降のドメインの間で JMS メッセージを転送する場合に使用します。SAF サービスによるメッセージの配信対象間の関係は、以下のとおりです。
Q. WebLogic ストア アンド フォワード サービスを使用できないのはどのような場合ですか。
A. WebLogic ストア アンド フォワード サービスは、以下の状況では使用できません。
Q. WebLogic JMS SAF クライアントとは何ですか。
A. JMS SAF クライアント機能は、WebLogic Server 9.0 で導入した JMS ストア アンド フォワード サービスをスタンドアロン JMS クライアントに拡張したものです。この機能を使用することで、(一時的なネットワーク接続の障害などが原因で) JMS クライアントが送り先にアクセスできない場合でも、JMS クライアントはサーバサイドの JMS 送り先にメッセージを確実に送信できるようになります。サーバとの接続が切断されている間、JMS SAF クライアントによって送信されたメッセージはクライアントのファイル システム上でローカルに格納され、クライアントが再接続するときに、サーバサイドの JMS 送り先に転送されます。「JMS SAF クライアントによる確実なメッセージ送信」を参照してください。
Q. WebLogic JMS SAF クライアントはどのような場合に使用すべきですか。
A. JMS メッセージを WebLogic Server 9.0 以降のドメインに転送する場合に使用します。
Q. JMS SAF クライアントを使用する場合、何か制限はありますか。
A. 「JMS SAF クライアントの使用に関する制限」を参照してください。
A. メッセージング ブリッジは、WebLogic Server 上で動作する管理的にコンフィグレーションされたサービスです。コンフィグレーションされたソース JMS 送り先から、コンフィグレーションされた対象 JMS 送り先に、メッセージを自動的に転送します。これらの送り先は、ブリッジとは別のサーバにコンフィグレーションできます。また、外部 (非 WebLogic) 送り先をコンフィグレーションすることも可能です。ブリッジの各送り先は、リモート プロバイダの以下の 4 つのプロパティを使用してコンフィグレーションします。
メッセージング ブリッジでトランザクションを使用するようにコンフィグレーションして、すべての XA 対応 (グローバル トランザクション対応) JMS プロバイダから別のプロバイダに「必ず 1 回」転送されるようにすることも可能です。
Q. メッセージング ブリッジはどのような場合に使用すべきですか。
A. 通常、メッセージング ブリッジは、ストア アンド フォワードによる高可用性設計要件を満たすために使用します。メッセージング ブリッジは、送信者のローカル送り先からのメッセージを消費し、これを送信者の実際の対象リモート送り先に転送するようにコンフィグレーションされます。つまり、対象リモート送り先にアクセスできない場合でも、送信者がそのローカル送り先にメッセージを送信できるようにすることで、高い可用性を提供します。リモート送り先にアクセスできない場合は、ローカル送り先が自動的にメッセージのストアを開始し、対象送り先がアクセス可能になり、ブリッジからメッセージを転送できるようになるまで継続します。
Q. メッセージング ブリッジを使用すべきでないのはどのような場合ですか。
A. 以下のような状況では、他の方法を使用することをお勧めします。
A. メッセージ駆動型 EJB は、標準の JMS API を内部的に使用する EJB コンテナです。ローカル、リモート、または外部 JMS 送り先から非同期でメッセージを受信し、そのメッセージを処理するアプリケーション コードを呼び出します。MDB には以下のような特性があります。
詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照してください。
A. MDB は、JMS メッセージを受信および処理する WebLogic Server アプリケーションに適したメカニズムです。
Q. MDB と一緒にメッセージング ブリッジを使用する必要はありますか。
A. MDB 間にメッセージング ブリッジを配置するのではなく、MDB がソース送り先から直接消費するようにコンフィグレーションしてください。MDB は、ソース送り先にアクセスできない場合には自動的に接続を再試行するため、メッセージ パス内にメッセージング ブリッジを配置してさらに高い可用性を提供する必要はありません。メッセージング ブリッジを配置すると、パフォーマンスに影響が及ぶ可能性があります。「Q. メッセージング ブリッジを使用すべきでないのはどのような場合ですか。」を参照してください。
Q. MDB にはどのようなコンフィグレーションが最適ですか。
A. 以下に、MDB をコンフィグレーションする際のヒントを示します。
Q. JMS の相互運用性に関するドキュメントは他にもありますか。
A. WebLogic JMS の一般的な情報については、「Oracle® WebLogic Server 10g リリース 3 メッセージング」を参照してください。
  
|