| Oracle® Fusion Middleware Oracle WebLogic Server JMSアプリケーションの開発 12c (12.1.2) E48081-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JMSアプリケーションの開発 12c (12.1.2) E48081-02 |
|
前 |
次 |
この章では、WebLogic ServerとリモートJMSプロバイダを統合する方法について説明します。JMS(メッセージング)、JTA(トランザクション)、およびJNDI(ネーミング)の各Java EE標準は、相互に連携することで、異なるホスト・マシン間(さらには異なるベンダー間)において信頼性の高いJava対Javaメッセージングを提供します。Oracle WebLogic Serverには、これらのAPIを利用してリモートJMSプロバイダをローカル・アプリケーションに統合するための各種ツールが用意されています。
Q. リモートJMSプロバイダとは何ですか。
A. リモートJMSプロバイダは、ローカルのスタンドアロンWebLogicサーバーの外部、またはWebLogicサーバー・クラスタの外部でホストされるJMSサーバーです。リモートJMSサーバーとしては、WebLogic JMSサーバーだけでなく、非WebLogic (外部) JMSサーバーも使用できます。
Q. JNDIとは何ですか。
A. JNDI (Java Naming and Directory Interface)は、サービスやリソースに名前をマップする、Java EEルックアップ・サービスです。JNDIは、特定の(クラスタリングされていない)スタンドアロンWebLogicサーバー内、またはWebLogicサーバー・クラスタ内に存在する公開リソースのディレクトリを提供します。これらのリソースとしては、JMS接続ファクトリ、JMS宛先、JDBC (データベース)データ・ソース、アプリケーションEJBなどがあります。
WebLogicクラスタ内のいずれかのWebLogicサーバーに接続しているクライアントは、クラスタ内のすべてのWebLogicサーバーでホストされているどのJNDI公開サービスおよびリソースでも透過的に参照できます。クライアントは、クラスタ内の特定のWebLogicサーバーについての明確な情報がなくても、そのサーバーでホストされているリソースにアクセスできます。
Q. JMS接続ファクトリとは何ですか。
A. JMS接続ファクトリは、JNDIに保持されている名前付きエンティティ・リソースです。アプリケーション、メッセージドリブンBean (MDB)、およびメッセージング・ブリッジは、JNDI内のJMS接続ファクトリをルックアップし、これを使用してJMS接続を作成します。最終的には、このJMS接続を使用して、メッセージを送信または受信するためのJMSセッション、プロデューサ、およびコンシューマを作成します。
Q. JMS接続IDとは何ですか。
A. JMS接続IDは、JMSクライアント接続の命名に使用します。恒久サブスクライバでは名前付きの接続が必要になります。それ以外の場面では、接続に名前を付けることはあまりありません。なお、クラスタリングされたサーバー群内(またはスタンドアロンのサーバー内)では、特定の名前付き接続を複数のJMSクライアントから同時に使用することはできません。また、既存の接続と同じ名前の接続を新たに作成しようとしても失敗します。
Q. JMSトピックとJMSキューの違いは何ですか。
A. JMSキューは、1つのコンシューマにメッセージを配信します。一方、JMSトピックは、複数のコンシューマにメッセージのコピーを配信します。
Q. トピック・サブスクリプションとは何ですか。
A. トピック・サブスクリプションは、特定のサブスクライバへの配信を待機しているメッセージの内部キュー、と捉えることができます。サブスクリプションを作成すると、トピックに対してパブリッシュされた各メッセージのコピーがこの内部キューに蓄積されます。ただし、サブスクリプションが作成される前に送信されたメッセージは蓄積されません。サブスクリプションは共有できないため、複数のサブスクライバが特定のサブスクリプションを同時にサブスクライブすることはできません。
Q. 非恒久トピック・サブスクライバとは何ですか。
A. 非恒久トピック・サブスクライバは、JMSクライアントの存続期間のみ存続する名前なしのサブスクリプションを作成します。非恒久サブスクリプション内のメッセージは永続化されることはありません。これは、メッセージのパブリッシャによって永続的なサービス品質(QOS)が指定されている場合でも同様です。JMSサーバーを停止すると、すべての非恒久サブスクリプションが終了します。
Q. 恒久サブスクライバとは何ですか。
A. 恒久サブスクライバは、サーバーの再起動後や恒久サブスクライバの終了後も存続する名前付きサブスクリプションを作成します。恒久サブスクライバは、トピック名、接続ID、およびサブスクライバIDを指定してそのサブスクリプションに接続します。クラスタ内にあるサブスクライバのサブスクリプションは、接続IDとサブスクライバIDの組合せによって一意に命名されます。トピックに対してパブリッシュされた各永続メッセージのコピーは、そのトピックの恒久サブスクリプションに永続化されます。サーバーのクラッシュや再起動が発生した場合は、恒久サブスクリプションおよびその未消費の永続メッセージが回復します。
Q. トランザクションとは何ですか。
A. トランザクションは、複数のアプリケーション操作をまとめたもので、最小単位として処理する必要のあるものです。一貫性を維持するため、トランザクション内のすべての操作は、すべてが成功するかすべてが失敗するかのどちらかでなければなりません。『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクションの概要に関する項を参照してください。
Q. 統合においてトランザクションが重要なのはなぜですか。
A. アプリケーションの統合においては、トランザクションを使用してデータの一貫性を維持するのが一般的です。たとえば、メッセージが必ず1回のみ転送されるようにする場合には、単一のトランザクションを使用して、2つの操作(ソース宛先からのメッセージの受信、およびターゲット宛先への送信)を1つにまとめることができます。また、トランザクションを使用することで、データベースの更新やメッセージング操作の実行における原子性を維持することもできます。
Q. JTAトランザクション、XAトランザクション、グローバル・トランザクションとは何ですか。
A. Java EEでは、単一のグローバル・トランザクションのことを、明確に区別することなくJTAトランザクション、XAトランザクション、ユーザー・トランザクション、グローバル・トランザクションなどと呼びます。このようなトランザクションには、複数の異なるXA対応リソースに対する操作が含まれている場合や、タイプの異なるリソースに対する操作が含まれている場合さえあります。JTAトランザクションは、常に現在のスレッドに関連付けられており、1つのアプリケーション呼出しとしてサーバー間で受け渡すこともできます。XAトランザクションの典型的な例は、WebLogicのJMS操作およびJDBC (データベース)操作の両方が含まれているトランザクションです。
Q. ローカル・トランザクションとは何ですか。
A. JMSローカル・トランザクションとは、単一のリソースまたはサービスのみが参加するトランザクションです。JMSローカル・トランザクションは、単一のベンダーの宛先が参加する特定のJMSセッションに関連付けられます。XAトランザクションと異なり、データベース操作をJMSローカル・トランザクションに参加させることはできません。
Q. JMSでは、ローカル・トランザクションをどのような方法で提供しているのですか。
A. ローカル・トランザクションは、transacted sessionsと呼ばれるJMS固有のAPIによって提供されます。WebLogic JMS以外のベンダーの場合、トランザクション・セッションのスコープを単一のJMSサーバーに限定しているのが一般的です。WebLogic JMSでは、クラスタ内の複数の宛先での複数のJMS操作を、単一のトランザクション・セッションのトランザクションに参加させることができます。言い換えると、トランザクション・セッションのスコープはWebLogicクラスタであり、そのJMSセッションのクラスタの外部にあるリモートJMSプロバイダをトランザクションに参加させることはできません。
Q. JMSローカル・トランザクションは統合にも利用できますか。
A. ローカル・トランザクションは、スコープが単一のリソース(たとえばメッセージング・サーバーやデータベース・サーバー)に限定されるため、通常は統合には使用しません。
Q. 動トランザクション登録とは何ですか。
A. 自動トランザクション登録とは、以下に示す条件に基づいて、Java EE JTAトランザクションに参加するデータベース・サーバーやメッセージング・サーバーなどのリソースに対して実行する操作です。
リソースがXAトランザクション対応です
リソースが現在のトランザクションに登録されています
リソースへのアクセスに使用されるクライアント・ライブラリがトランザクション対応(XA対応)です
技術的には、トランザクション内のXA対応リソースに対する操作を自動的に参加させることを自動登録と呼びます。
XA対応WebLogic APIを使用するWebLogicクライアントには、現在のスレッドのJTAトランザクション内の操作が自動的に登録されます。XA対応のWebLogicクライアントとしては、WebLogic JMS XA対応(またはユーザー・トランザクション対応)接続ファクトリ、グローバル・トランザクション対応のJDBC接続プール・データ・ソースなどがあります。
外部(非WebLogic) JMSクライアントには、現在のJTAトランザクションは自動登録されません。このようなクライアントの場合は、現在のトランザクション内で別手順によってプログラム的に登録するか、WebLogicが提供する機能を使用して外部JMSクライアントをラップし、ラッパーAPI経由で外部JMSクライアントにアクセスしたときに自動登録されるようにする必要があります。
外部ベンダーに対して自動登録を提供するためのJMS機能は以下のとおりです。
メッセージドリブンEJB
JMS resource-referenceプール
メッセージング・ブリッジ
WebLogic以外のベンダーのJMS接続ファクトリがXA対応かどうかは、そのベンダーのドキュメントで確認してください。なお、トランザクション・セッション(ローカル・トランザクション)のサポートには、グローバル/XAトランザクションのサポートは含まれていません。
Q. JMSクライアントは、どのような手順でリモートJMSプロバイダと通信するのですか。
A. JMSクライアントでは、どのJMSプロバイダと通信する場合でも、次の手順を実行する必要があります。
JNDIを使用して、JMS接続ファクトリ・オブジェクトとJMS宛先オブジェクトをルックアップする
接続ファクトリ・オブジェクトを使用してJMS接続を作成する
JMS接続とJMS宛先オブジェクトを使用して、メッセージ・コンシューマまたはプロデューサを作成する
Q. リモートJMSプロバイダとの通信を設定するためにはどのような情報が必要ですか。
A. リモートJMSプロバイダとの通信を設定するためには、以下の情報を用意する必要があります。
宛先タイプ(リモートJMS宛先がキューであるかトピックであるか)。
リモートJMS宛先のJNDI名。
恒久トピック・サブスクライバの場合は、それを一意に特定するための接続ID名とサブスクライバID名。メッセージドリブンEJBは、これらの値のデフォルト値をEJB名に基づいて提供します。
非WebLogicリモートJMSプロバイダの場合
初期コンテキスト・ファクトリ・クラス名(JMSプロバイダのJNDIルックアップ・サービスのJavaクラス名)
JMSプロバイダのJMSクライアント・ライブラリおよびJNDIクライアント・ライブラリを保持するJava jarファイルの格納場所。これらのjarファイルが、ローカルJVMのクラスパスに指定されていることを確認してください。
リモート・プロバイダのJNDIサービスのURL。WebLogicサーバーの場合、このURLは通常t3://hostaddress:portという形式になっています。HTTP上でトンネリングする場合は、URLの先頭をt3ではなくhttpにします。アプリケーションと同じWebLogicサーバー(またはWebLogicクラスタ)上に存在するWebLogic JMSサーバーにアクセスする場合は、サーバー・アプリケーション・コードにURLを記述する必要はありません。
リモート・プロバイダのJMS接続ファクトリのJNDI名。この接続ファクトリは、ローカル・プロバイダではなくリモート・プロバイダ上に存在している必要があります。
JMSアプリケーションでトランザクションを使用する場合は、接続ファクトリをXA対応にする必要があります。WebLogicドキュメントでは、XA対応ファクトリをユーザー・トランザクション対応と表現しています。
WebLogicサーバーでは、以下に示す構成不可の接続ファクトリ3つがデフォルトで提供されます。
weblogic.jms.ConnectionFactory (XA対応でないファクトリ)
weblogic.jms.XAConnectionFactory (XA対応ファクトリ)
weblogic.jms.MessageDrivenBeanConnectionFactory (メッセージドリブンEJB用のXA対応ファクトリ)
その他のWebLogic JMS接続ファクトリは、明示的に構成する必要があります。
Q. 部JMSプロバイダのJNDIサービスの機能性に制限がある場合はどうしたらよいですか。
A. JMSプロバイダの接続ファクトリおよび宛先を特定する方法として好ましいのは、標準のJava EE JNDIルックアップを使用する方法です。しかし、非WebLogic JMSプロバイダのJNDIサービスは、使い勝手が悪い場合や信頼性に欠ける場合があります。この問題を解決するには、WebLogicサーバーで動作する起動クラスまたはload-on-startupサーブレットを作成して、以下の処理を実行します。
外部プロバイダ独自の(非JNDI) APIを使用して、接続ファクトリとJMS宛先を特定します
JMS宛先とJMS接続ファクトリをWebLogic JNDI内に登録します
Q. JMSリソースをプールする方法について教えてください。
A. リモートおよびローカルのJMSリソース(たとえば、クライアント接続およびセッション)は、プールすることでパフォーマンスを向上させることができます。メッセージドリブンEJBでは、その内部JMSコンシューマが自動的にプールされます。また、リソース参照によってアクセスするJMSコンシューマおよびプロデューサも自動的にプールされます。
Q. リモートJMSプロバイダを統合するためのツールは用意されていますか。
A. 次の表に、リモートJMSプロバイダを統合するために使用できるツールをまとめます。
| 方法 | 自動登録 | JMSリソース・プーリング |
|---|---|---|
|
リモート・プロバイダのJMSクライアントの直接使用 |
WebLogicサーバー・プロバイダの場合は「はい」。その他のプロバイダの場合は、プログラム的に登録を実行する必要があります。 |
いいえ。ただし、プログラム的に実行できます。 |
|
メッセージング・ブリッジ |
はい |
なし |
|
外部JMSサーバー定義 |
いいえ。自動登録を実現するには、JMSリソース参照またはMDBと組み合せて使用します。 |
いいえ。リソース・プーリングを実現するには、JMSリソース参照またはMDBと組み合せて使用します。 |
|
JMSリソース参照 |
はい |
はい |
|
メッセージドリブンEJB |
はい |
はい |
|
SAFクライアント |
なし |
なし |
|
SAF |
はい |
なし |
Q. EJBまたはサーブレット内でリモートJMSプロバイダからメッセージを受信するにはどうしたらよいですか。
A. メッセージドリブンEJBを使用します。ただし、同期受信では、レシーバがメッセージの待機をブロックしている間、サーバー側スレッドがアイドル状態になるためお薦めできません。「メッセージングBeanの使用」を参照してください。
Q. EJBまたはサーブレット内からリモートJMSプロバイダにメッセージを送信するにはどうしたらよいですか。
A. リソース参照を使用します。プーリングと自動リスト登録が提供されます。「EJB/サーブレットのJMSリソース参照の使用」を参照してください。ラッパーが十分でない場合は、独自のプーリング・コードを記述できます。
ターゲット宛先がリモートである場合は、ローカル宛先とメッセージング・ブリッジを追加して、ストア・アンド・フォワードによる高可用性設計を実装することを検討してください。「メッセージング・ブリッジの使用」を参照してください。
もう1つのベスト・プラクティスは、外部JMSサーバー定義を使用する方法です。外部JMSサーバー定義を使用すると、アプリケーションのJMSリソースを管理的に変更できるため、アプリケーション・コードにURLをハード・コード化するのを避けることができます。また、リモートJMSプロバイダを参照するためのリソース参照を有効にする場合には、外部JMSサーバー定義が必要になります。「外部JMSサーバー定義の使用」を参照してください。
Q. クライアントからリモートJMSプロバイダと通信するにはどうしたらよいですか。
A. 宛先がWebLogic Serverによって提供されたものでなく、グローバル・トランザクションないの宛先での操作を含める必要がある場合は、EJB内の外部ベンダーでのJMS操作をサーバー・プロキシを使用してカプセル化します。WebLogicサーバーで実行されているアプリケーションは、現在のトランザクションにおいてトランザクション(XA)対応の非WebLogic JMSプロバイダを登録するための機能を備えています。
ストア・アンド・フォワード機能が必要な場合は、メッセージをローカル宛先に送信し、メッセージング・ブリッジを使用して外部宛先に転送することを検討してください。次を参照してください。
別の選択肢としては、単純にリモート・ベンダーのJNDIおよびJMS APIを直接使用するか、外部JMSプロバイダを構成して、参照のハード・コード化を避ける方法もあります。その場合は、外部プロバイダのクラス・ライブラリをクライアントのクラス・パスに追加する必要があります。
Q. WebLogic JMSの相互運用機能をチューニングするにはどうしたらよいですか。
A. 『Oracle WebLogic Serverのパフォーマンスのチューニング』のWebLogic Server EJBのチューニングに関する項、WebLogicメッセージング・ブリッジのチューニングに関する項、およびWebLogic JMSストア・アンド・フォワードのチューニングに関する項を参照してください。
Q. 外部JMSサーバー定義とは何ですか。
A. 外部JMSサーバー定義は、管理的に構成されたシンボリック・リンクです。スタンドアロンのWebLogicサーバーやWebLogicクラスタにおいては、この外部JMSサーバー定義によって、リモートJNDIディレクトリ内のJNDIオブジェクト(JMS接続ファクトリ、宛先オブジェクトなど)と、JNDIネームスペース内のJNDI名との間をリンクさせています。それらは、管理コンソールまたは標準のJMX MBean APIを使用して構成せきます。または、スクリプトを使用してプログラム的に構成できます。「外部JMSプロバイダへのアクセスの簡略化」を参照してください。
Q. 外部JMSサーバー定義を使用するのが最適なのはどのような場合ですか。
A. このリリースでは、外部JMSサーバー定義を使用することで、JMS JNDIパラメータを1箇所にまとめることができます。1つの定義を、複数のEJB、サーブレット、およびメッセージング・ブリッジで共有できます。定義を変更する場合にも、デプロイメント記述子を再コンパイルしたり変更したりする必要はありません。それらは、以下の場合に特に便利です:
メッセージドリブンEJB (MDB)の標準JMS通信プロパティを、アプリケーションのEJBデプロイメント記述子にハード・コード化するのではなく、構成によって管理することが望ましい場合。これは、MDBのソース宛先がリモートでない場合にも当てはまります。
MDBにリモート宛先が含まれている場合。この場合は、デプロイメント記述子の構成が簡略化され、管理制御を強化できます。
EJBまたはサーブレットにおいて、リモート宛先との送受信を行う場合。
リソース参照を有効にして、リモートJMSプロバイダを参照する場合。「EJB/サーブレットのJMSリソース参照の使用」を参照してください。
Q. JMSリソース参照とは何ですか。
A. リソース参照は、サーブレットおよびEJBアプリケーションの開発者が指定し、アプリケーションにパッケージ化するものです。リソース参照を使用すると、一定レベルの間接性を簡単に実現できます。つまり、JNDI名をアプリケーションのソース・コードに直接ハード・コード化するかわりに、EJB記述子に定義したJNDI名をアプリケーションから参照することが可能になります。
JMSリソース参照は、以下の2つの機能を提供します。
JMSリソースがアプリケーションによって閉じられた場合に、それらのリソースを自動的にプーリングする
JMSリソースを現在のトランザクションに自動登録する(非WebLogic JMSプロバイダの場合も可能)
EJBまたはサーブレットのアプリケーション・コード内でJMSリソース参照を使用するには、デプロイメント記述子にresource-ref要素を追加し、JNDIコンテキストを使用してjava:comp/env/jms/<参照名>という構文で参照をルックアップします。
リソース参照の機能は、アプリケーション・コードの外部には提供されません。したがって、メッセージドリブンEJBのソース宛先の構成や、メッセージング・ブリッジのソース宛先またはターゲット宛先の構成には使用できません。
JMSリソース参照のプーリングの詳細は、第4章「WebLogic JMSをEJBやサーブレットと組み合せて使用するために拡張されたサポート」を参照してください。
Q. JMSリソース参照を使用する利点は何ですか。
A. JMSリソース参照には以下の利点があります。
サーブレットおよびEJBアプリケーションの移植性を確保できます。JMSリソース参照を使用することで、アプリケーションのソース・コードを再コンパイルすることなく、アプリケーションのJMSリソースを変更できます。
JMS Connection、Session、およびMessageProducerオブジェクトの自動プーリングが可能になります。
非WebLogic JMSプロバイダの自動トランザクション登録が可能になります。ただし、JMSプロバイダがXA対応である必要があります。リソース参照を使用しない場合、非WebLogic JMSプロバイダを現在のトランザクションに登録するには、プログラム手順を別途記述する必要があります。
Q. 外部JMSプロバイダでは、リソース参照をどのように使用したらよいですか。
A. リソース参照でリモートJMSプロバイダを参照できるようにするには、リソース参照と外部JMS定義を組み合せて使用する必要があります。これは、リソース参照には、URLや初期コンテキスト・ファクトリを指定する場所が用意されていないためです。「外部JMSサーバー定義の使用」を参照してください。
Q. 非トランザクション・メッセージングでは、リソース参照をどのように使用したらよいですか。
A. 非トランザクションの場合は、グローバル・トランザクション(XA)対応の接続ファクトリは使用しないでください。これによって、メッセージングのパフォーマンスが影響を受けます。使用した場合は、リソース参照が各メッセージング処理の内部トランザクションを自動的に開始およびコミットし、メッセージングのパフォーマンスに影響を及ぼします。「トランザクションの理解」を参照してください。
Q. WebLogicストア・アンド・フォワード・サービスとは何ですか。
A. WebLogic ServerでWebLogicストア・アンド・フォワード(SAF)サービスを使用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信することができます。たとえば、SAFサービスを利用すると、ローカルのWebLogic Serverインスタンス上で動作するアプリケーション、またはローカルのWebLogic Serverインスタンスに接続するアプリケーションは、リモート・サーバー上の宛先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存されて、リモートの宛先が使用可能になった時点で転送されます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。
Q. WebLogicストア・アンド・フォワード・サービスはどのような場合に使用すべきですか。
A. WebLogicストア・アンド・フォワード(SAF)サービスは、WebLogic Server 9.0以降のドメインの間でJMSメッセージを転送する場合に使用します。SAFサービスによるメッセージの配信対象間の関係は、以下のとおりです。
2つのスタンドアロンのサーバー・インスタンス間
クラスタ内のサーバー・インスタンス間
ドメイン内の2つのクラスタ間
異なるドメイン間
Q. WebLogicストア・アンド・フォワード・サービスを使用できないのはどのような場合ですか。
A. WebLogicストア・アンド・フォワード・サービスは、以下の状況では使用できません。
リモート宛先から受信する場合 - メッセージドリブンEJBを使用するか、クライアント・コンシューマを直接実装してください。
ローカル宛先にメッセージを送信する場合 - ローカル宛先に直接送信してください。
以前のリリースのWebLogic Serverにメッセージを転送する場合。「メッセージング・ブリッジの使用」を参照してください。
サード・パーティのJMS製品(MQSeriesなど)と相互運用する場合。「メッセージング・ブリッジの使用」を参照してください。
リクエストにレスポンスを戻すためにJMSReplyToで一時的な宛先を使用する場合
メッセージのレイテンシをあまり許容できない環境。SAFによってレイテンシが増加し、スループットが低下する可能性があります。
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クライアントの使用に関する制限」を参照してください。
Q. メッセージング・ブリッジとは何ですか。
A. メッセージング・ブリッジは、WebLogic Server上で動作する管理的に構成されたサービスです。構成されたソースJMS宛先から、構成されたターゲットJMS宛先に、メッセージを自動的に転送します。これらの宛先は、ブリッジとは別のサーバーに構成できます。また、外部(非WebLogic)宛先を構成することも可能です。ブリッジの各宛先は、リモート・プロバイダの以下の4つのプロパティを使用して構成します。
初期コンテキスト・ファクトリ
接続URL
接続ファクトリのJNDI名
宛先のJNDI名
メッセージング・ブリッジでトランザクションを使用するように構成して、すべてのXA対応(グローバル・トランザクション対応) JMSプロバイダから別のプロバイダに「必ず1回」転送されるようにすることも可能です。
Q. メッセージング・ブリッジはどのような場合に使用すべきですか。
A. 通常、メッセージング・ブリッジは、ストア・アンド・フォワードによる高可用性設計要件を満たすために使用します。メッセージング・ブリッジは、送信者のローカル宛先からのメッセージを消費し、これを送信者の実際のターゲットのリモート宛先に転送するように構成されます。つまり、ターゲットのリモート宛先にアクセスできない場合でも、送信者がそのローカル宛先にメッセージを送信できるようにすることで、高可用性を提供します。リモート宛先にアクセスできない場合は、ローカル宛先が自動的にメッセージのストアを開始し、ターゲット宛先がアクセス可能になり、ブリッジからメッセージを転送できるようになるまで継続します。
Q. メッセージング・ブリッジを使用すべきでないのはどのような場合ですか。
A. 以下のような状況では、他の方法を使用することをお薦めします。
リモート宛先から受信する場合 - メッセージドリブンEJBを使用するか、クライアント・コンシューマを直接実装してください。
ローカル宛先にメッセージを送信する場合 - ローカル宛先に直接送信してください。
メッセージのレイテンシをあまり許容できない環境。メッセージング・ブリッジではメッセージのレイテンシが長くなり、スループットが低下する可能性があります。メッセージング・ブリッジでは、メッセージ・パス内の追加宛先が導入されるためメッセージのレイテンシが長くなり、シングル・スレッドでメッセージを転送するためスループットが低下する可能性があります。
WebLogic 9.0のドメイン間でメッセージを転送する場合 - WebLogicストア・アンド・フォワード機能を使用してください。「WebLogicストア・アンド・フォワードの使用」を参照してください。
Q. 一部のメッセージが転送されないのはなぜですか。
A. 通常、メッセージング・ブリッジはすべてのメッセージを転送します。一部のメッセージが転送されない場合は次の理由が考えられます。
一部のメッセージに有効期限がある場合、ソース宛先またはターゲット宛先のJMSプロバイダによりメッセージが失効します。
セレクタ・フィルタを指定するようにブリッジ・ソース宛先を構成した場合、フィルタ処理されたメッセージのみが転送されます。
ブリッジでは、転送の制限回数を超えた場合、メッセージをエラー宛先に自動で移動したり、自動で削除したりするオプションは直接提供されません。JMSプロバイダには、ブリッジ・ソース宛先でメッセージに関する同様の機能をもたらすオプションがあります。ブリッジ・ソース宛先をホストするJMSプロバイダで再配信制限オプションが有効な場合、ブリッジの自動再試行メカニズムがメッセージの再配信制限を超えないようにプロバイダを再構成する必要があります。
Q. メッセージドリブンEJB (MDB)とは何ですか。
A. メッセージドリブンEJBは、標準のJMS APIを内部的に使用するEJBコンテナです。ローカル、リモート、または外部JMS宛先から非同期でメッセージを受信し、そのメッセージを処理するアプリケーション・コードを呼び出します。MDBには以下のような特性があります。
ソース宛先に自動的に接続し、リモート宛先にアクセスできない場合は自動的に接続を再試行します。
JMSプロバイダがWebLogicでない場合でも、コンテナ管理のトランザクションでの受信メッセージの自動登録をサポートします。
JMS接続、セッション、およびコンシューマを自動的にプールします。
MDBのソース宛先、URL、および接続ファクトリは、アプリケーションの一部としてパッケージ化されるEJBおよびWebLogic記述子に構成されます。
メッセージング処理のアプリケーション・ロジックは、単一のメソッド・コールバックonMessage()に含まれています。
トランザクション、セキュリティ、JDBCなどの典型的なEJBアクションをサポートする完全なEJBです。
詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のメッセージドリブンEJBに関する項を参照してください。
Q. MDBはどのような場合に使用すべきですか。
A. MDBは、JMSメッセージを受信および処理するWebLogic Serverアプリケーションに適したメカニズムです。
Q. MDBと一緒にメッセージング・ブリッジを使用する必要はありますか。
A. MDB間にメッセージング・ブリッジを配置するのではなく、MDBがソース宛先から直接消費するように構成してください。MDBは、ソース宛先にアクセスできない場合には自動的に接続を再試行するため、メッセージ・パス内にメッセージング・ブリッジを配置してさらに高可用性を提供する必要はありません。メッセージング・ブリッジを配置すると、パフォーマンスに影響が及ぶ可能性があります。「メッセージング・ブリッジの使用」を参照してください。
Q. MDBにはどのような構成が最適ですか。
A. 以下に、MDBを構成する際のヒントを示します。
MDBの同時実行性とスレッド・プールを構成するには、max-beans-in-free-poolおよびdispatch-policy記述子フィールドを使用します。MDBのスレッド・プール内の使用可能なサーバー・スレッドの数によっては、同時に作成されるインスタンスの数がmax-beans-in-free-poolの値よりも少なくなることがあります。
リモートJMSプロバイダから消費するようにMDBを構成する場合は、外部JMSサーバー定義を使用します。WebLogic MDB記述子から直接リモート宛先を参照するように構成することも可能ですが、この情報はアプリケーションにパッケージ化されてしまうため、動的に変更することができません。外部JMSサーバー定義を構成し、MDBが外部定義を参照するように構成することをお薦めします。なお、一部のドキュメントでは、外部JMSサーバー定義を「ラッパー」と呼んでいます。「外部JMSサーバー定義の使用」を参照してください。
コンテナ管理のトランザクション用にMDBを構成する場合は注意が必要です。MDBでコンテナ管理のXAトランザクションをサポートするには、MDBの記述子ファイルでtransaction-typeをContainer、trans-attributeをRequiredに設定し、XA対応のJMS接続ファクトリを使用する必要があります。このように設定しないと、MDBはトランザクション非対応になります。WebLogicのデフォルト設定では、MDBの接続ファクトリはXA対応になっています。MDBは、トランザクションを自動的に開始し、トランザクション内で受信したメッセージを自動的に登録します。
Q. AQ JMSと相互運用できますか。
A. Oracle WebLogic Serverアプリケーションでは、WebLogic Serverリソース(Webアプリケーション、EJB、MDB)またはスタンドアロン・クライアントを使用し、JMS APIを介してOracle Streamsアドバンスト・キューイング(AQ)と相互運用します。AQ JMSでは、WebLogic Serverクラスタ全体にアクセス可能なデータベースに格納されたJMSメッセージと、データベース接続を使用して、データベース機能やデータ操作およびバックアップのツールを利用できるようにします。
WebLogic Serverリソース(Webアプリケーション、EJB、MDB)またはスタンドアロン・クライアントを使用し、JMS APIを介してOracle Streamsアドバンスト・キューイング(AQ)と相互運用するにはJMS外部サーバー構成を使用します。『Oracle WebLogic Server JMSリソースの管理』のOracle AQ JMSとの相互運用に関する項を参照してください。
Q. 作成したOC4JアプリケーションをWebLogic Serverに移行するにはどうすればよいですか。
A. Oracle OC4JアプリケーションをOracle WebLogic Serverアプリケーションに移行する方法については、『Oracle Fusion Middleware Java EEアップグレード・ガイド』を参照してください。
