| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 11g リリース1(10.3.3) B61636-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JMSの構成と管理 11g リリース1(10.3.3) B61636-01 |
|
前 |
次 |
以下の節では、Oracle AQ JMSとの相互運用の方法について説明します。
『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。
Oracle WebLogic Serverアプリケーションでは、WebLogic Serverリソース(Webアプリケーション、EJB、MDB)またはスタンドアロン・クライアントを使用し、JMS APIを介してOracle Streamsアドバンスト・キューイング(AQ)と相互運用できます。AQ JMSでは、WebLogic Serverクラスタ全体にアクセス可能なデータベースに格納されたJMSメッセージと、データベース接続を使用して、データベース機能やデータ操作およびバックアップのツールを利用できるようにします。必要なクラスは、インストールしたWebLogic Serverにすべて含まれているので、WebLogic Serverのclasspathにファイルを追加する必要はありません。
WebLogic AQ JMSでは、WebLogic JMS外部サーバー・フレームワークが使用されます。これによって、WebLogic Serverアプリケーションやスタンドアロン・クライアントでの標準WebLogic JNDIコンテキストを使用したAQ JMS接続ファクトリおよび宛先のルックアップや、アプリケーションやクライアントでの標準JEE API群を使用したAQ JMSのロードおよび呼出しが可能になります。必要なデータベースへの参照、JDBCドライバ、およびデータ・ソースは、このフレームワークの一部として構成されています。
WebLogic ServerのJVM内で実行されるアプリケーションのために、次のような仕組みが提供されています。
構成済みのWebLogicデータ・ソースで、特定のJDBCドライバを参照し、JDBC接続をプールして、AQ JMSをホストするOracleデータベースへの接続を提供します。
構成済みのWebLogic外部サーバーで、データ・ソースを参照します。
WebLogic JMS外部サーバー構成の一部として、AQ JMSの接続ファクトリおよび宛先用にローカルJNDI名が定義されます。これらのJNDI名は、既存のAQ接続ファクトリや宛先にマップするように構成されます。
言い換えると、MDBなどのWebLogic Serverアプリケーションは、このローカルJNDI名を参照することになります。
AQ外部宛先は、メッセージを送受信するアプリケーションやMDBを実行するサーバー対してローカルにする必要があります。WebLogic AQ JMSは、リモート接続をサポートしないデータ・ソース/DB接続を使用します。また、あるドメイン内のAQ宛先と、別のドメインで実行するアプリケーション/MDBとの間でメッセージング・ブリッジを使用する方法もあります。「WebLogicメッセージング・ブリッジ」を参照してください。
WebLogic AQ JMSは、Oracleデータベースとの通信にJDBCドライバを必要とします。このリリースでは、インストールしたWebLogic Serverに含まれているOracle JDBC 11gシン・ドライバのみがサポートされます。Oracle OCI JDBCドライバや、非Oracle JDBCドライバはサポートされません。
グローバルXA (JTA)トランザクションと、ローカルJMSでトランザクション処理されるセッション・トランザクションがサポートされます。グローバル・トランザクションではXAベースの接続ファクトリを使用する必要があり、一方のローカル・トランザクションでは、XAベースでないJMS接続ファクトリが使用されます。
非XA JDBCドライバを選択する場合、ローカル・トランザクションでのみWebLogic AQ JMSを使用できます。
XA JDBCドライバを選択する場合、ローカルとグローバルの両方のトランザクションでWebLogic AQ JMSを使用できます。
このリリースでは、ロギング・ラスト・リソース(LLR)、1相コミット(JTS)、エミュレート2相コミットといったグローバル・トランザクション・オプションを伴う非XA JDBCドライバのデータ・ソースはサポートされません。「グローバル・トランザクションのサポート」が選択されている場合、警告メッセージがログに記録されます。
グローバル・トランザクションは、XA JDBCドライバの1相コミットが最適化されている場合にのみサポートされます。AQ JMSとJDBCの処理の両方に同じXA対応データ・ソースを使用した場合、XAトランザクションの動作は、単一のデータ・ソース(トランザクション・マネージャで単一のリソースとして扱われるもの)の中に2つの接続がある状態と同等になります。そのため、同じJTAトランザクションでAQ JMSとJDBCの処理が呼び出され、そのトランザクションに他のリソースが関わらない場合、トランザクションでは2相コミットではなく1相コミットの最適化が使用されるか、読取り専用の最適化が使用されます。
『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』の「トランザクションについて」を参照してください。
WebLogic AQ JMSでは、Oracle Real Application Clusters (RAC)とWebLogicマルチ・データ・ソースの併用がサポートされ、RAC環境でのフェイルオーバーが提供されます。『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』の「Oracle RACでのWebLogic Serverの使い方」を参照してください。
JMS外部サーバーを使用したAQ JMSとの相互運用を目的とするものを除き、AQ JMX固有のMBeanや、管理コンソールでのAQ JMSの構成のサポートはありません。AQのキュー表の作成や削除、宛先の作成や削除、および統計問合せといったAQの管理およびモニターを行うには、SQLスクリプトまたはその他のツールを使用してください。
以下の節では、OracleデータベースにAQ JMSキューおよびトピックを構成し、WebLogic ServerにJMS外部サーバーを構成して、アプリケーションからAQ JMS接続ファクトリや宛先をWebLogic JNDIコンテキストでルックアップできるようにする方法の一例を紹介します。
AQ JMSキューおよびトピックの準備ができている場合には、WebLogic ConsoleまたはWLSTコマンド・ライン・インタフェースを使用して、以降の構成タスクを実行できます。
WebLogic Serverリソースの構成を開始する前に、Oracleデータベース内にAQ JMSキューおよびトピックが確実にあるようにする必要があります。以下の節では、構成方法の1つを説明します。
AQの使用と構成の詳細は、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。
データベース内にユーザーを作成し、そのユーザーにAQ JMSのパーミッションを与えます。管理者権限を持つデータベース・ユーザーで、以下のタスクを実行します。
Oracle SQL*Plus環境を使用して、管理者ログインでログインします。
connect / as sysdba;
JMSユーザー・スキーマを作成します。以下の例の場合、ユーザー名はjmsuser、パスワードはjmsuserpwd。
Grant connect, resource TO jmsuser IDENTIFIED BY jmsuserpwd;
jmsuserにAQユーザーのロールを付与します。
Grant aq_user_role TO jmsuser;
AQパッケージに対する実行権限を付与します。
Grant execute ON sys.dbms_aqadm TO jmsuser;
Grant execute ON sys.dbms_aq TO jmsuser;
Grant execute ON sys.dbms_aqin TO jmsuser;
Grant execute ON sys.dbms_aqjms TO jmsuser;
AQ JMSの各JMSキューやJMSトピックのデータは、AQキュー表に格納されます。各キュー表が、JMSメッセージのリポジトリの機能を担います。JMSキューまたはJMSトピック(「AQキュー表の作成」を参照)は、基底のAQキュー表への論理的な参照です。
AQキュー表は、個々のJMSユーザー・スキーマ内に作成され、Oracle SQL*PLUSを使用して定義できます。例:
connect jmsuser / jmsuserpwd;
AQキュー表を構成するには、最低でも3つのパラメータが必要です。キュー表の名前、ペイロード・タイプ、そしてAQキュー表で複数のコンシューマを受け入れるかどうかのフラグです。例:
dbms_aqadm.create_queue_table(
queue_table=>"myQueueTable",
queue_payload_type=>'sys.aq$_jms_text_message',
multiple_consumers=>false
);
説明:
queue_table:キュー表の名前。データベースが10.0の場合、大文字と小文字の混在がサポートされます。ただし、この名前は 二重引用符で囲む必要があります。キュー表の名前は24文字を超えないようにします。
queue_payload_type: メッセージのタイプ。すべてのJMSメッセージのインタフェース・タイプをサポートするには、sys.aq$_jms_messageを使用します。
multiple_consumers:キューの場合はfalse、トピックの場合はtrueを設定。
キュー表の作成の詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスのCREATE_QUEUE_TABLEプロシージャに関する項を参照してください。
AQ JMSキューは、キューとトピックの両方を対象としたJMS管理リソースです。AQ JMSキューは、AQキュー表の作成後に、Oracle SQL*PLUSを使用して個々のJMSユーザー・スキーマ内に作成できます。例:
connect jmsuser/jmsuserpwd;
キューまたはトピックを作成するためのPL/SQLプロシージャは、次のような書式になります。
dbms_aqadm.create_queue(
queue_name=>'userQueue',
queue_table=>'myQueueTable'
);
説明:
queue_nameは、JMSキューのユーザー定義名。
queue_tableは、既存のAQキュー表を指している必要があります。
キュー表の作成の詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスのCREATE_QUEUEプロシージャに関する項を参照してください。
初めて使用する前には、AQ JMSキューを開始する必要があります。JMSユーザー・スキーマを使用して、以下のPL/SQLプロシージャを実行します。queue_nameはAQ JMSキューの名前です。
connect jmsuser / jmsuserpwd dbms_aqadm.start_queue(queue_name=>'userQueue'
キューの開始の詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスのSTART_QUEUEプロシージャに関する項を参照してください。
以下の節では、AQ JMSと相互運用するようにWebLogic Serverを構成する方法を説明します。
AQ JMSを使用するWebLogic Serverアプリケーション(MDB、EJB、Webアプリケーションなど)には、AQ JMSサービスを提供するOracleデータベース用のデータ・ソースを構成します。このデータ・ソースは、JMSのユーザーおよびパスワードを使用して、データベース内のスキーマに接続するため、ほとんどの状況ではAQ JMS専用として使用されます。データベース接続で使用されるスキーマに作成した場合は、複数のキューおよびトピックがサポートされます。データ・ソースを構成する場合は、以下の作業を実行します。
Oracle Thin Driverを選択します。
AQ JMSで必要なトランザクションのタイプに基づいて、ドライバのタイプを選択します。
ローカル・トランザクションでAQ JMSと併用するためには、非XAベースJDBCドライバを選択します。
グローバル・トランザクションまたはローカル・トランザクションでAQ JMSと併用するためには、XAベースJDBCドライバを選択します。
非XAドライバのデータ・ソースを構成する場合、「グローバル・トランザクションのサポート」オプションは選択しません。このリリースでは、非XA JDBCドライバのデータ・ソースと、LLR、JTS、エミュレート2相コミットといったグローバル・トランザクション・オプションとの併用はサポートされていません。グローバル・トランザクション・オプションが選択されていると、サーバー・インスタンスでログに警告メッセージが記録されます。グローバル・トランザクションは、XAベースのJDBCドライバでサポートされています。
データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。IDベースの接続プールはサポートされていません。
次を参照してください:
『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』の「JDBCデータ・ソースの構成」。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成に関する項。
Oracle RAC環境では、shrink-frequency-secondsに小さな値を設定することをお薦めします。
例: shrink-frequency-seconds=10
このようにすると、接続が失敗したときに、その接続をデータ・ソースで削除できます。以下を参照してください。
AQリソース用のJMS外部サーバーをホストするために、専用のJMSシステム・モジュールを構成します。そのモジュールを、WebLogic Serverインスタンス、または外部JNDI名をホストする必要のあるクラスタでターゲット指定します。以下を参照してください。
JMS外部サーバーの構成で、以下の内容を指定します。
oracle.jms.AQjmsInitialContextFactoryをJNDI初期コンテキスト・ファクトリとして指定します。
アプリケーション環境に必要なJDBCデータ・ソースを構成します。
次を参照してください:
datasourceというJNDIプロパティを指定します。これは、ローカルにバインドされたWLSデータ・ソースのJNDIの場所です。
例:
<foreign-server> <initial-context-factory>oracle.jms.AQjmsInitialContextFactory</initial-context-factory> <jndi-property> <key>datasource</key> <value>jdbc/aqjmsds</value> </jndi-property> </foreign-server>
datasource JNDIプロパティの値は、AQ JMS Oracleデータベースにアクセスするように構成されているデータ・ソースの名前です。これ以外の構成情報は不要です。
「WebLogicデータ・ソースの構成」を参照してください。
JMS外部サーバーを作成したら、WebLogic ServerのJNDIツリーにAQ JMS接続ファクトリのJNDIマッピングを作成できます。宛先とは異なり、AQ JMSの場合、Oracleデータベースで接続ファクトリを再定義する必要はありません。かわりに、接続ファクトリのリモートJNDI名の特定時に事前定義済みのJNDI名が指定されます。AQ JMS接続ファクトリのリモートJNDI名は、以下のいずれかになります。
表7-1 AQ JMS接続ファクトリのリモートJNDI名
| <AQ JMSの接頭辞値> | JMSインタフェース |
|---|---|
|
|
javax.jms.QueueConnectionFactory |
|
|
javax.jms.TopicConnectionFactory |
|
|
javax.jms.ConnectionFactory |
|
|
javax.jms.XAQueueConnectionFactory |
|
|
javax.jms.XATopicConnectionFactory |
|
|
javax.jms.XAConnectionFactory |
たとえば、AQ JMS外部サーバー用に構成された以下のような2つの接続ファクトリがあるとします。
表7-2 AQ JMS外部サーバーの接続ファクトリ例
| ローカルJNDI名 | リモートJNDI名 |
|---|---|
|
jms/aq/myCF |
ConnectionFactory |
|
aqjms/orderXaTopicFactory |
XATopicConnectionFactory |
WebLogicアプリケーションでjms/aq/myCFにあるJMSファクトリをルックアップした場合、アプリケーションはそのJMSのjavax.jms.ConnectionFactoryインタフェースを実装するAQ JMSオブジェクトを取得します。WebLogicアプリケーションでaq/orderXaTopicFactoryにあるJMSファクトリをルックアップした場合、アプリケーションはそのJMSのjavax.jms.XAToicConnectionFactoryインタフェースを実装するAQ JMSオブジェクトを取得します。
AQ JMS外部サーバーの接続ファクトリを構成するには、以下の作業を行う必要があります。
ローカルおよびリモートのJNDI名を指定します。
ローカルJNDI名は、接続ファクトリをWebLogic JNDIツリーにバインドするために使用される名前。ローカルJNDI名は、ローカルのWebLogic Serverで公開されている他のJNDI名と競合しないように、一意のものとする必要があります。
リモートJNDI名は、AQ JMS接続ファクトリをルックアップするためにAQ JMSへ渡される名前。
AQ JMSをグローバル・トランザクションで使用するように構成する場合、XAベースの接続ファクトリを使用してください。そうしないと、非XAベースの接続ファクトリが構成されます。
これ以外の構成パラメータは不要です。
次を参照してください:
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部接続ファクトリの作成に関する項。
AQ JMSの外部宛先を構成する場合、以下の内容を構成する必要があります。
ローカルJNDI名 - WebLogic JNDIツリーに宛先をバインドするために使用される名前。ローカルJNDI名は、ローカルのWebLogic Serverインスタンスで公開されている他のJNDI名と競合しないように、一意のものとする必要があります。
リモートJNDI名 - ルックアップを行うためにAQ JMSに渡される名前。AQ JMSには、以下の構文に従ったリモートJNDI名が必要です。
宛先がキューの場合、リモートJDNI名はQueues/<queue name>とする必要があります。
宛先がトピックの場合、リモートJDNI名はTopics/<topic name>とする必要があります。
接続ファクトリと同様、AQ JMSの宛先にも、JMSオブジェクト・タイプを識別するために接頭辞の付いたリモートJNDI名が必要です。宛先用には以下の2つの値が用意されています。
AQ JMS接続ファクトリのJNDI名とは異なり、宛先名の値はデータベースに定義されているAQ JMS宛先を表しています。第7章「JMSキューまたはトピックの作成」を参照してください。たとえば、AQ JMS外部サーバーに次の表に示すような2つの宛先が構成されているとします。
jms/myQueueという場所をルックアップするWebLogicアプリケーションは、userQueueで定義されているAQ JMSキューを参照します。AqTopicという場所をルックアップすると、myTopicで定義されているAQ JMSトピックが参照されます。
次を参照してください:
以下の節では、高度なWebLogic AQ JMSトピックについて説明します。
MDBは、AQ JMSとの相互運用に、構成済の外部サーバーを使用します。「JMS外部サーバーの構成」を参照してください。メッセージドリブン・パラメータinitial-context-factoryおよびprovider-urlは、JMS外部サーバーの構成の一部として提供されるため、サポートされません。ejb-jar.xmlファイルで、MDBの宛先の宛先タイプをjavax.jms.Queueまたはjavax.jms.Topicに構成する必要があります。コンテナ管理トランザクション、恒久トピック・サブスクリプションなどのMDB機能を有効にするには、他にもMDBの構成が必要です。
『Oracle Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』を参照してください。
AQ JMS拡張APIがAQ JMSの特定のクラスでサポートされています。AQ JMS拡張は、標準のJMSオブジェクト(接続ファクトリや宛先など)を独自仕様のAQ JMSクラスにキャストすると、呼び出せるようになります。
AQ JMS接続ファクトリのリソース参照を使用する場合、WebLogic Serverでは基底のAQ JMS接続ファクトリがラッパー・オブジェクトでラップされます。このラッパー・オブジェクトはJMSの標準APIを実装していますが、AQ JMS拡張APIを提供するAQ JMSクラスにはそれをキャストできません。ラップ処理を回避するには、リソース参照のリソース・タイプとして、デプロイメント記述子のjavax.jms.XXXConnectionFactoryのかわりにjava.lang.Objectを指定します。この制限事項はAQ JMSに固有のものです。リソース参照はJavaインタフェースを使用して公開される拡張のみをサポートするためです。AQ JMSでは、その拡張用のJavaインタフェースは定義されません。AQ JMSでは、ラップ処理を回避しても、自動JTAトランザクションの登録は無効にならず、プーリングも妨げられません。WebLogicデータ・ソースが組み込まれた状態で使用され、こうした機能が暗黙的に有効な状態になります。
リソース参照を使用することを選択し、リソース・タイプがjavax.jms.XXXConnectionFactoryである場合、ユーザー・アプリケーションに渡されるAQ JMSオブジェクトはラップされます。AQ JMS拡張APIも使用する場合、それらはラップしないようにする必要があります(「AQ JMS拡張」を参照)。
WebLogicリソース参照ラッパーでは、AQ JMS接続は自動的にはプールされません。かわりに、AQ JMSのサーバー側統合はデータ・ソースの接続プーリング機能に依存し、それによってJMS接続およびセッションのオープンとクローズに関わるオーバーヘッドが軽減されます。WebLogicリソース参照でプーリング機能が無効になるのは、AQ JMSプロバイダのJMS接続ファクトリが常にクライアントの識別子で事前に構成されているためです。逆に、このようになっているのでWebLogicリソース参照でプーリング機能が無効になると言うこともできます。
AQ JMSセッションでは、JMSセッションが閉じるまでJDBC接続が維持されます。これは、その接続でデータ・ソースやJDBC URLが使用されるかどうかとは関係なく行われます。セッションが長時間にわたってアイドル状態になった場合、AQ JMSセッションを閉じることをお薦めします。JMSセッションを閉じると、JDBC接続が開放されてWebLogicデータ・ソースのプールに戻るか(「データ・ソースのチューニング」を参照)、データベースおよびJDBC URLのネットワーク・リソースが開放されます。
次の項では、Oracle RAC環境での制限事項について説明します。
Oracle RAC環境でAQ JMS RACのフェイルオーバーを実現するには、WebLogicマルチ・データ・ソースの構成が必要です。『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』の「Oracle RACでのWebLogic Serverの使い方」を参照してください。
Oracle RACのフェイルオーバーは、このリリースではWebLogic AQ JMSスタンドアロン・クライアントの使用時にはサポートされません。
AQ JMSのトレースやデバッグの機能を使用するには、システム・プロパティoracle.jms.traceLevelを設定する必要があります。
このプロパティの値は1 - 6までの整数で、6に設定した場合に詳細度が最大になります。トレースの結果は実行中のJVMの標準出力に出力されます。
以下の節では、WebLogic ServerアプリケーションとAQ JMSを相互運用する場合の高度な相互運用に関して説明します。
スタンドアロンのクライアントとサーバー側のアプリケーションでは、セキュリティのセマンティクスや構成が異なります。セキュリティについて知りたい場合は、この項をよくお読みください。また、WebLogicのロックダウンに関するドキュメントでも、WebLogic Serverやクラスタを保護する方法について説明しています(『Oracle Fusion Middleware Oracle WebLogic Server本番環境の保護』を参照)。次の項では、このリリースでのセキュリティに関する考慮事項について説明します。
AQでは、宛先でのルックアップや、エンキューおよびデキューのため、データベース・ユーザーにENQUEUEまたはDEQUEUEあるいはその両方のパーミッションを構成する必要があります。
以下のユーザー名に対し、ENQUEUEまたはDEQUEUEあるいはその両方のパーミッションを必ず指定します。
スタンドアロン・クライアントの場合。
構成済みのJMS外部サーバーのユーザー名(java.naming.security.principalプロパティを使用して指定されたとおり)。
JMS ConnectionFactory APIのcreateConnection()メソッドを使用してusernameを渡すJavaコードの場合、このusernameにパーミッションが必要です。
サーバー側アプリケーションの場合。
WebLogicデータ・ソースにデータベース・ユーザー名が構成されています。
JMS ConnectionFactory APIのcreateConnection()メソッドでusernameを渡すJDBCデータ・ソース・クライアントに指定されているusernameには、パーミッションを付与しません。このusernameはWebLogicのusernameであり、データベースのusernameではありません。
AQのルックアップ、エンキュー、およびデキューに使用されるJDBC接続の資格証明やパーミッションについては、『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』の「Queue Security and Access Control」を参照してください。
|
注意: 宛先のルックアップ時にパーミッションが失敗すると、アプリケーションの呼出し側に(セキュリティ例外ではなく)「name not found」という例外として明示されます。 |
これまでに説明したように、JMS外部サーバーの構成タスクの一部として、接続ファクトリや宛先のローカルJNDI名を構成する必要があります。こうしたJNDI名には必要に応じてACLを構成することもできます。そのようにすると、JNDIルックアップ時に現在のWebLogic資格証明に基づいてアクセス・チェックが行われます。現在のWebLogic資格証明はクライアントのタイプによって決まります。
アプリケーションのWebLogic JNDIルックアップのセキュリティ・ポリシーの資格証明のチェックで宛先として合格すると、Oracle AQのその宛先リソースが、JMS外部サーバーの宛先で自動的にJDBC接続を使用してルックアップされます。
スタンドアロンのクライアントの場合、この宛先ルックアップの2番目のプロセスで使用される資格証明は、JMS外部サーバーに構成されているusernameおよびpasswordに基づくものです。
サーバー側アプリケーションのJDBCデータ・ソース・クライアントの場合、この2番目の宛先ルックアップで使用される資格証明は、そのデータ・ソースの一部として構成されているデータベースのusernameおよびpasswordに基づきます。このデータ・ソースへのアクセス権を得るために使用される資格証明は、現在のWebLogic資格証明であることに注意してください。このデータ・ソースにWebLogicセキュリティ・ポリシーを構成することも可能です。WebLogicデータ・ソースのIDベースの接続プーリング機能は、この目的のためにはサポートされていません。
前述したように、データベースの資格証明には、宛先の正常なルックアップのため、その宛先に対するAQ JMSのENQUEUEまたはDEQUEUEパーミッションがある必要があります。「AQ宛先のセキュリティの構成」を参照してください。
JMSのQueueSessionおよびTopicSession APIには、宛先のルックアップのために、それぞれcreateQueue()、createTopic()というJNDIにかわるものが用意されています。『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』の「宛先のルックアップ方法」を参照してください。
createQueue()およびcreateTopic()の呼出しでは、JMS接続に関連付けられているデータベース資格証明が使用されます。以降の節では、この資格証明を設定する方法について説明します。
以下の節では、スタンドアロン・クライアント向けのセキュリティ構成について説明します。
JNDIの初期コンテキストの確立時や後続のJNDIルックアップの実行時には、クライアントからWebLogicへのネットワーク通信が発生します。確実にセキュアな通信を行い、プレーン・テキストが渡されないようにするには、SSL対応のプロトコル(t3sやhttpsなど)を使用します。データベース・ログイン用に構成されるJMS外部サーバーの資格証明はもちろん、WebLogicログインに使用される資格証明も、SSLが構成されていない場合にはプレーン・テキストで渡されます。
ネットワーク通信は、AQとの通信時にクライアントからデータベースに対して行われます。この通信はJDBC URLの構成で制御され、JDBC URLがSSLを使用するように構成されていない限り、プレーン・テキストで渡されます。スタンドアロンのクライアントは、AQ JMS APIを使用してデータベース接続でデータベースと直接的に通信し、そのJMSリクエストはWebLogicサーバーを通りません。
WebLogic Serverのユーザー名およびパスワード: クライアントからWebLogicへのネットワーク・ログインは、JNDIの初期コンテキスト確立の一部として実行されます。このコンテキストの作成時にオプションとして指定されるユーザー名およびパスワードのプロパティが、WebLogicのIDとなります(プロパティ名はそれぞれContext.SECURITY_PRINCIPAL = "java.naming.security.principal"、Context.SECURITY_CREDENTIALS = "java.naming.security.credentials")。これが、後続のJNDIルックアップでチェックされる資格証明となります。この資格証明は現在のスレッドとも暗黙的に関連付けられるため、同じスレッドでの後続のWebLogic処理にも使用される資格証明になります。ただし、これはAQ JMS処理に使用される資格証明ではありません。
javax.jms.ConnectionFactory createConnection()メソッドには、オプションのユーザー名とパスワードがあります。スタンドアロン・クライアントの場合、これらが、JMS外部サーバーの構成の一部として構成されているコンテキストの資格証明をオーバーライドします。AQ JMSでは、この指定されたユーザーIDでデータベース接続が作成されます。ユーザー名とパスワードを指定せずにcreateConnection()が呼び出された場合、JMS外部サーバーの構成の一部として構成されているユーザー名およびパスワードを使用して、データベース接続が作成されます。
ユーザー名やパスワードを直接、JDBC URLに含めないこと。かわりにJMS外部サーバーのユーザー名およびパスワードを使用します。
JMS外部サーバーの接続ファクトリに、ユーザー名やパスワードを構成しないでください。このようにした場合の動作はサポートされません。
以下の節では、サーバー側アプリケーション向けのセキュリティ構成について説明します。
スタンドアロン・クライアントのサポートにも使用されているJMS外部サーバーでない限り、そのJMS外部サーバーにjava.naming.security.principalや資格証明を構成しないでください。
JMS外部サーバーの接続ファクトリに、ユーザー名やパスワードを構成しないでください。このようにした場合の動作はサポートされません。
サーバーからデータベースへのネットワーク通信(サーバー側アプリケーション)は、データ・ソースの構成で制御され、そのデータ・ソースがSSLを使用するように構成されていない限り、プレーン・テキストで行われます。
javax.jms.ConnectionFactory createConnection()メソッドには、オプションのユーザー名とパスワードがあります。サーバー側のJMS AQアプリケーションの場合、このメソッドはユーザー名をWebLogicユーザーのものとみなして、WebLogic serverに対する認証を行います。この動作は、他の種類のJMS AQクライアントの動作とは異なります。他の種類のJMS AQクライアントではユーザー名がデータベース・ユーザーとして扱われます。WebLogicデータ・ソースとともに構成されている場合、AQ JMSではそのWebLogicデータ・ソースに認証が委託され、AQ JMSでWebLogicユーザーのセマンティクスが継承されます。
AQ JMS外部サーバーがWebLogicデータ・ソースとともに構成されている場合、そのデータ・ソースは汎用JDBC利用のために公開されます。データ・ソースは、『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』の「JDBCデータ・ソースのセキュリティ」の説明に従って保護することをお薦めします。
WebLogic Serverのユーザー名およびパスワードについて。WebLogicの資格証明は、JNDI内の保護されている名前にアクセスするときや、保護されているデータ・ソースにアクセスするときにチェックされます。サーバー側アプリケーションでは、その同じWebLogic資格証明を自動的にアプリケーションの呼出し側とみなします。あるいはMDBの場合には、この資格証明をMDB構成の一部として構成することも可能です。
WebLogicデータ・ソースのIDベースの接続プーリング機能はサポートされていません。
JNDIコンテキストの資格証明: サーバー側アプリケーション内でJNDIコンテキストの設定の一部として資格証明を指定する必要は通常なく、普通は推奨されません。このようにすると新しい資格証明が作成され、アプリケーションの現在の資格証明がオーバーライドされます。言い換えると、コンテキストの作成時にオプションで指定されたユーザー名およびパスワードのプロパティが、WebLogicのIDとなり、現在のIDと置き換えられます(プロパティ名はそれぞれContext.SECURITY_PRINCIPAL = "java.naming.security.principal"とContext.SECURITY_CREDENTIALS = "java.naming.security.credentials")。このオプションの新しい資格証明は、暗黙的に現在のスレッドと関連付けられるので、同じスレッドの後続のWebLogic処理(JNDIルックアップなど)でもその資格証明が使用されます。この新しい資格証明は、AQ JMS処理に使用される資格証明ではありません。
WebLogicメッセージング・ブリッジは、構成済のソース・ブリッジ宛先およびターゲット・ブリッジ宛先と通信します。ソース宛先とターゲット宛先とのマッピングごとに、メッセージング・ブリッジのインスタンスを構成する必要があります。各メッセージング・ブリッジ・インスタンスは、マッピングするソース宛先とターゲット宛先、メッセージ・フィルタリング・セレクタ、サービスの品質(QOS)、トランザクション・セマンティクスおよび各種再接続パラメータを定義します。
AQ外部宛先が、メッセージを送受信するアプリケーションやMDBを実行するサーバーに対してローカルではない場合、AQ外部宛先に対してローカルなサーバーでメッセージング・ブリッジ・インスタンスを構成する必要があります。ローカル・データベース接続は、AQ宛先からのメッセージの送受信プロセスで使用されます。
WebLogicメッセージング・ブリッジの詳細は、Oracle Fusion Middleware Oracle WebLogic Serverメッセージング・ブリッジの構成と管理のメッセージング・ブリッジの概要に関する項を参照してください。
この項では、あるドメインで外部宛先として構成されたAQ宛先と、別のドメインで実行するアプリケーション/MDBとの間にメッセージング・ブリッジを作成する主な手順について説明します。
AQ宛先が外部宛先として構成されるサーバーにブリッジ・インスタンスを作成します。
ソース・ブリッジ宛先とターゲット・ブリッジ宛先を作成します。
ソース宛先またはターゲット宛先に外部AQ JMS宛先が指定される場合、デフォルトの「メッセージング・プロバイダ」ドロップダウンで「その他のJMS」を選択します。
リソース・アダプタをデプロイします。
メッセージング・ブリッジ・インスタンスを作成します。
メッセージング・ブリッジのサービス品質を「必ず1回」にする場合、データ・ソースをXAベースのJDBCドライバで構成し、XA JMS接続ファクトリ・インタフェースを実装するAQ JMS接続ファクトリを使用する必要があります。「WebLogicデータ・ソースの構成」および「JMS外部サーバー接続ファクトリの構成」を参照してください。
メッセージング・ブリッジのターゲットを指定します。
管理コンソールを使用すると、適切なリソース・アダプタをデプロイし、一部の属性値を設定して、メッセージング・ブリッジを作成できます。使用する環境に合うように、メッセージング・ブリッジの設定変更が必要な場合もあります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの作成に関する項を参照してください。
JDBC URLを使用してJMS外部サーバーで定義されたAQ JMS接続ファクトリおよび宛先をルックアップできる、WebLogic AQ JMSスタンドアロン・クライアントを作成できます。このクライアントでは、クライアント側のclasspathにaqapi.jar、ojdbc6.jar、orai18n.jar、およびWebLogicクライアントjar(wlthint3client.jar、wlclient.jar、wlfullclient.jarのいずれか)を指定する必要があります。
WebLogic ServerのJVMの外部で実行されるアプリケーションについては、以下のような処理が行われます。
構成済みのWebLogic JMS外部サーバーで、データベースのURLや、その他のJDBCドライバの構成が参照されます。「データベースのJDBC URLを使用した外部サーバーの構成」を参照してください。
WebLogic JMS外部サーバー構成の一部として、AQ JMSの接続ファクトリおよび宛先用にローカルJNDI名が定義されます。これらのJNDI名は、既存のAQ接続ファクトリや宛先にマップするように構成されます。
スタンドアロンのクライアントではローカルJNDI名を参照します。WebLogic Serverで実行されるアプリケーションとは異なり、スタンドアロンのクライアントではドライバおよびAQクライアントが確実にclasspathに存在する必要があります。
jndi-properties-credentialsに、db_urlおよびjava.naming.security.principal JNDIプロパティと、パスワードを指定します。
例:
<foreign-server> <initial-context-factory>oracle.jms.AQjmsInitialContextFactory</initial-context-factory> <jndi-properties-credential-encrypted>{3DES}g8yFFu1AhP8=</jndi-properties-credential-encrypted> <jndi-property> <key>java.naming.security.principal</key> <value>j2ee</value> </jndi-property> <jndi-property> <key>db_url</key> <value>jdbc:oracle:thin:@{hostname}:{port}:{sid}</value> </jndi-property> </foreign-server>
説明:
db_url JNDIプロパティの値は、AQ JMS Oracleデータベースへの接続に使用されるJDBC URL。
java.naming.security.principalの値は、AQ JMSでデータベースへの接続に使用されるデータベース・ユーザー名。
jndi-properties-credentialsはデータベースのパスワードを格納。
これ以外の構成プロパティは不要です。
以下の節では、関連ドキュメントへのリンクを紹介します。
『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』
Oracle WebLogic Serverパフォーマンス・チューニング・ガイド
『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』の「FAQ: リモートJMSプロバイダの統合」
『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』
Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング
