この章では、Oracle WebLogic Serverアプリケーションで、WebLogic Serverリソース(Webアプリケーション、EJB、MDB)またはスタンドアロン・クライアントを使用し、JMS APIを介してOracle Streamsアドバンスト・キューイング(AQ)と相互運用する方法について説明します。
『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。
注意: AQ-JMSの統合は、混在クラスタと動的クラスタではサポートされません。この操作を試行しても、例外はスローされません。 |
AQ JMSでは、WebLogic Serverクラスタ全体にアクセス可能なデータベースに格納されたJMSメッセージと、データベース接続を使用して、データベース機能やデータ操作およびバックアップのツールを利用できるようにします。必要なクラスは、インストールしたWebLogic Serverにすべて含まれているので、Oracle AQ JMSと相互運用するためにWebLogic Serverのクラスパス
にファイルを追加する必要はありません。
WebLogic AQ JMSでは、WebLogic JMS外部サーバー・フレームワークが使用されます。これによって、WebLogic Serverアプリケーションやスタンドアロン・クライアントでの標準WebLogic JNDIコンテキストを使用したAQ JMS接続ファクトリおよび宛先のルックアップや、アプリケーションやクライアントでの標準Java EE 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に対してローカルとなる必要があります。1つのWebLogic Serverインスタンス上で実行中のアプリケーションは、AQ JMS外部サーバーおよび別のWebLogic Serverインスタンス上で登録されるデータ・ソースを参照したり使用したりできません。WebLogic AQ JMSは、リモート接続をサポートしないデータ・ソース/DB接続を使用します。あるいは、一方のドメイン上のAQ宛先ともう一方のドメインで実行中のアプリケーション/MDB間のメッセージング・ブリッジを使用します。「WebLogicメッセージング・ブリッジ」を参照してください。
WebLogic AQ JMSでは、Oracleデータベースとの通信にOracleシン・ドライバを必要とします。Oracle OCI JDBCドライバや、非Oracle JDBCドライバはサポートされません。『Oracle WebLogic Serverの新機能』のサポートされている構成に関する項を参照してください。
グローバル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 WebLogic Server JMSアプリケーションの開発』のトランザクションの理解に関する項を参照してください。
WebLogic AQ JMSでは、Oracle Real Application Clusters (RAC)とWebLogicマルチデータ・ソースの併用がサポートされ、RAC環境でのフェイルオーバーが提供されます。『Oracle WebLogic Server JDBCデータ・ソースの管理』のOracle RACでのWebLogic Serverの使用に関する項を参照してください。
注意: AQ JMSを使用する |
JMS外部サーバーを使用したAQ JMSとの相互運用を目的とするものを除き、AQ JMX固有のMBeanや、管理コンソールでのAQ JMSの構成のサポートはありません。AQのキュー表の作成や削除、宛先の作成や削除、および統計問合せといったAQの管理およびモニターを行うには、SQLスクリプトまたはその他のツールを使用してください。
以下の節では、OracleデータベースにAQ JMSキューおよびトピックを構成し、WebLogic ServerにJMS外部サーバーを構成して、アプリケーションからAQ JMS接続ファクトリや宛先をWebLogic JNDIコンテキストでルックアップできるようにする方法の一例を紹介します。
AQ JMSキューおよびトピックの準備ができている場合には、WebLogicコンソールまたは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 WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成に関する項
AQリソース用のJMS外部サーバーをホストするために、専用のJMSシステム・モジュールを構成します。そのモジュールを、WebLogic Serverインスタンス、または外部JNDI名をホストする必要のあるクラスタでターゲット指定します。次を参照:
『Oracle WebLogic Server JMSリソースの管理』のJMSモジュールの概要に関する項
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシステム・モジュールでの外部サーバーの作成に関する項
JMS外部サーバーの構成で、以下の内容を指定します。
oracle.jms.AQjmsInitialContextFactory
をJNDI初期コンテキスト・ファクトリとして指定します。
アプリケーション環境に必要なJDBCデータ・ソースを構成します。
次を参照:
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成に関する項
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名は、以下のいずれかになります。
表8-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つの接続ファクトリがあるとします。
表8-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名が必要です。
宛先がキューの場合、リモートJNDI名はQueues
/<queue name>
とする必要があります。
宛先がトピックの場合、リモートJNDI名はTopics
/<topic name>
とする必要があります。
接続ファクトリと同様、AQ JMSの宛先にも、JMSオブジェクト・タイプを識別するために接頭辞の付いたリモートJNDI名が必要です。宛先用には以下の2つの値が用意されています。
AQ JMS接続ファクトリのJNDI名とは異なり、宛先名の値はデータベースに定義されているAQ JMS宛先を表しています。第8章「JMSキューまたはトピックの作成」を参照してください。たとえば、AQ JMS外部サーバーに次の表に示すような2つの宛先が構成されているとします。
jms/myQueue
という場所をルックアップするWebLogicアプリケーションは、userQueue
で定義されているAQ JMSキューを参照します。AqTopic
という場所をルックアップすると、myTopic
で定義されているAQ JMSトピックが参照されます。
次を参照:
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部宛先の作成に関する項
以下の節では、高度な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 WebLogic ServerメッセージドリブンBeanの開発』を参照してください。
クラスタ化されたMDBでAQトピックをリスニングする場合は、One-Copy-Per-Applicationのメッセージング戦略を実装するために、共有サブスクリプションを使用します。
サブスクリプションを共有するサブスクライバは、次の要件を満たしている必要があります。
異なるVM上に存在する。
同じデータ・ソース(または同じデータベース・ユーザー名およびパスワードを使用するデータ・ソース)を使用している。
同じサブスクリプション名を使用している。
データベース・ユーザー名は、サブスクリプションのクライアントIDとして機能します。同じ名前のサブスクリプションに対するクライアントIDが同じ場合、そのサブスクリプションはAQで共有されます。共有サブスクリプションの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の高可用性のための高度なメッセージング機能に関する項を参照してください。
AQ JMS拡張APIがAQ JMSの特定のクラスでサポートされています。AQ JMS拡張は、標準のJMSオブジェクト(接続ファクトリや宛先など)を独自仕様のAQ JMSクラスにキャストすると、呼び出せるようになります。例:
. . .
import oracle.jms.AQjmsFactory;
. . .
ConnectionFactory myCF = (ConnectionFactory) jndiCtx.lookup("aqjms/testCF");
AQjmsFactory myCF = (AQjmsFactory) myCF;
myCF.someProprietaryAQJMSmethod(..);
. . .
AQ JMS接続ファクトリのリソース参照を使用する場合、WebLogic Serverでは基底のAQ JMS接続ファクトリがラッパー・オブジェクトでラップされます。このラッパー・オブジェクトはJMSの標準APIを実装していますが、AQ JMS拡張APIを提供するAQ JMSクラスにはそれをキャストできません。例:
. . .
// Implements wrapping and can't cast to AQ JMS
<resource-ref>
<res-ref-name>aqjms/testCF</res-ref-name>
<res-type>javax.jms. ConnectionFactory</res-type>
<res-auth>Application</res-auth>
</resource-ref>
. . .
ラップ処理を回避するには、リソース参照のリソース・タイプとして、デプロイメント記述子のjavax.jms.XXXConnectionFactory
のかわりにjava.lang.Object
を指定します。この制限事項はAQ JMSに固有のものです。リソース参照はJavaインタフェースを使用して公開される拡張のみをサポートするためです。例:
. . .
// Use for AQ JMS extensions
<resource-ref>
<res-ref-name>aqjms/testCF</res-ref-name>
<res-type>java.lang.Object</res-type>
<res-auth>Application</res-auth>
</resource-ref>
. . .
AQ JMSでは、その拡張用のJavaインタフェースは定義されません。AQ JMSでは、ラップ処理を回避しても、自動JTAトランザクションの登録は無効にならず、プーリングも妨げられません。AQ JMSは、WebLogicデータ・ソースの組み込みの使用を通して、これらの機能を暗黙的に取得するためです。
AdtMessage
は、特殊なタイプのAQ JMS拡張機能で、Oracle抽象データ型(ADT)をサポートします。ADTは、データ構造と、Oracleデータベースでデータを操作するサブプログラムで構成されます。
注意: メッセージ・ドリブンBean (MDB)ではサポートされません。 |
次を参照:
Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのOracle Java Message Service (OJMS)を使用したOracle Streamsアドバンスト・キューイングへのアクセスに関する項とオブジェクト・タイプのサポートに関する項
Oracle Database PL/SQL言語リファレンスのデータ抽象化に関する項
リソース参照を使用することを選択し、リソース・タイプが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 WebLogic Server JDBCデータ・ソースの管理』のOracle RACでのWebLogic Serverの使用に関する項を参照してください。
Oracle RACのフェイルオーバーは、このリリースではWebLogic AQ JMSスタンドアロン・クライアントの使用時にはサポートされません。
AQ JMSのトレースやデバッグの機能を使用するには、システム・プロパティoracle.jms.traceLevel
を設定する必要があります。
このプロパティの値は1 - 6までの整数で、6に設定した場合に詳細度が最大になります。トレースの結果は実行中のJVMの標準出力に出力されます。
Oracle RDBMS 11.2.0.2以前のリリースでは、キュー表についての統計がデフォルトでロックされているため、各デキュー処理ごとに全表スキャンが行われます。この問題を解決するには、キュー表のロックを解除して統計を収集します。例:
exec DBMS_STATS.UNLOCK_TABLE_STATS ('<schema>','<queue table>');
exec DBMS_STATS.gather_table_stats('<schema>','<queue table>');
exec DBMS_STATS.LOCK_TABLE_STATS ('<schema>','<queue table>');
以下の節では、WebLogic ServerアプリケーションとAQ JMSを相互運用する場合の高度な相互運用に関して説明します。
スタンドアロンのクライアントとサーバー側のアプリケーションでは、セキュリティのセマンティクスや構成が異なります。セキュリティについて知りたい場合は、この項をよくお読みください。また、WebLogicのロックダウンに関するドキュメントでも、WebLogic Serverやクラスタを保護する方法について説明しています(『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名には必要に応じてセキュリティ・ポリシーを構成することもできます。そのようにすると、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 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 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 WebLogic Server WebLogicメッセージング・ブリッジの管理』のメッセージング・ブリッジの理解に関する項を参照してください。
この項では、あるドメインで外部宛先として構成された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 WebLogic Server JMSアプリケーションの開発』のリモートJMSプロバイダ統合のFAQに関する項を参照してください。
『Oracle WebLogic Server JMSリソースの管理』
『Oracle WebLogic Serverスタンドアロン・クライアントの開発』