サービスの構成

WebLogic Remote Consoleを使用して、WebLogic Serverドメイン内のサービスを管理します。

データソース

WebLogic Serverをデータベースに接続するには、JDBCデータ・ソースをドメインに追加します。 データ・ソースは、Java EEにおいてデータベース接続を構成するための標準的な手法です。

各WebLogicデータ・ソースは、データベース接続のプールを保有しています。 各アプリケーションは、JNDIツリー上またはローカル・アプリケーション・コンテキストでデータ・ソースをルックアップし、その接続プールにあるデータベース接続を使用します。 データ・ソースおよびその接続プールは、システムの効率的な稼働を維持するための接続管理プロセスを備えています。

WebLogic Remote Consoleから次のJDBCデータ・ソース・タイプを管理できます:

• JDBC汎用データ・ソース

• JDBC複数データ・ソース

• Active GridLinkマルチ・データ・ソース

• ユニバーサル接続プール(UCP)のデータ・ソース

データ・ソースをWebLogic Serverとともに使用する方法の詳細は、「Oracle WebLogic Serverの理解」の「JDBCデータ・ソースの理解」および「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「データベース接続の構成」を参照してください。

JDBCドライバ

データ・ソースでは、JDBCドライバを使用して様々なデータベースにアクセスする必要があります。 WebLogic Serverには、JDBCドライバのデフォルト・セットが付属していますが、サードパーティのJDBCドライバをインストールすることもできます。

WebLogic ServerでサポートされているJDBCドライバのタイプについては、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「JDBCドライバのタイプ」を参照してください。

WebLogic ServerにインストールされているJDBCドライバのリストは、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「WebLogic ServerとともにインストールされるJDBCドライバ」を参照してください。

サード・パーティのJDBCドライバをインストールする手順は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「WebLogic Serverでインストールされていないサード・パーティJDBCドライバの追加」を参照してください。

汎用データ・ソースの作成

汎用データ・ソースは、データベース・アクセスおよびデータベース接続管理を提供します。 汎用データ・ソースとその接続プールによって、効率的なシステム運用の維持を円滑にする接続管理プロセスが提供されます。

汎用データ・ソースの詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「JDBC汎用データ・ソースの使用」を参照してください。

WebLogic ServerでインストールされていないJDBCドライバが必要な場合は、データ・ソースを設定する前にインストールする必要があります。 「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「WebLogic Serverでインストールされていないサード・パーティJDBCドライバの追加」を参照してください。

1. 「編集ツリー」で、「サービス」、「データ・ソース」の順に移動します。

2. 「新規」をクリックします。

3. 新しいデータ・ソース名を入力します

   名前に次の文字を含めることはできません: @ # $。

4. 「JNDI名」フィールドに、このJDBCデータ・ソースがバインドされるロケーションへのJNDIパスを入力します。 アプリケーションは、接続を予約する際、この名前でJNDIツリー上のデータ・ソースをルックアップします。

5. データ・ソースをデプロイするサーバー・インスタンスまたはクラスタを選択します。

6. 「データソース・タイプ」ドロップダウン・リストから「一般データ・ソース」を選択します。

7. 「データベース・タイプ」ドロップダウン・リストから、接続先のデータベースのデータベース管理システム(DBMS)を選択します。

8. 「データベース・ドライバ」ドロップダウン・リストから、JDBCドライバを選択します。

9. 接続先のデータベースの接続詳細を入力します:

   • データベース名: 接続先のデータベースの名前を入力します。 データベース名要件の細部は、JDBCドライバおよびDBMSによって異なります。
   • ホスト名: データベースをホストするサーバーのDNS名またはIPアドレスを入力します。 これは、Oracle GridLinkサービスとインスタンスの接続を作成している場合、特定のマルチ・データ・ソースの各データ・ソースで同じ名前にする必要があります。
   • ポート: データベース・サーバーが接続リクエストをリスニングするポートを入力します。
   • データベース・ユーザー名: データ・ソース内の接続に使用するデータベース・ユーザー・アカウント名を入力します。
   • パスワード: データベース・ユーザー・アカウントのパスワードを入力します。

10. 「作成」をクリックします。

マルチ・データ・ソースの作成

マルチ・データ・ソースは、汎用データ・ソースのグループを抽象化したものです。 2つ以上のデータ・ソース間の接続リクエストのフェイルオーバーおよびロード・バランシングを提供します。

マルチ・データ・ソースの詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「JDBCマルチ・データ・ソースの使用」を参照してください。

マルチ・データ・ソースを作成する前に、マルチ・データ・ソースが管理する汎用データ・ソースを作成し、マルチ・データ・ソースのデプロイ先と同じターゲットにデプロイされるようにする必要があります。 「汎用データ・ソースの作成」を参照してください。

1. 「編集ツリー」で、「サービス」、「データ・ソース」の順に移動します。

2. 「新規」をクリックします。

3. 新しいデータ・ソース名を入力します

   名前に次の文字を含めることはできません: @ # $。

4. 「JNDI名」フィールドに、このJDBCデータ・ソースがバインドされるロケーションへのJNDIパスを入力します。 アプリケーションは、接続を予約する際、この名前でJNDIツリー上のデータ・ソースをルックアップします。

5. データ・ソースをデプロイするサーバー・インスタンスまたはクラスタを選択します。

   ノート

   マルチ・データ・ソースと汎用データ・ソースを同じターゲットにデプロイする必要があります。

6. 「データソース・タイプ」ドロップダウン・リストから「マルチ・データ・ソース」を選択します。

7. 「アルゴリズム・タイプ」ドロップダウン・リストから、マルチ・データ・ソースの接続リクエスト処理を決定するアルゴリズム・タイプを選択します。

   • フェイルオーバー: マルチ・データ・ソースは、接続リクエストをリストの最初のデータ・ソースにルーティングします。リクエストが失敗した場合、リクエストはリスト内の次のデータ・ソースに送信されます。
   • ロードバランシング: マルチ・データ・ソースは、接続リクエストをメンバー・データ・ソースに均等に分散します。

8. これがXA JDBCマルチ・データ・ソースか非XA JDBCマルチ・データ・ソースかを指定します。

   • 「XAドライバ」オプションが「有効」の場合、マルチ・データ・ソースは、データベース接続の作成にXA JDBCドライバを使用するデータ・ソースのみを使用します。
   • 「XAドライバ」オプションがdisabledの場合、マルチ・データ・ソースは非XA JDBCドライバを使用するデータ・ソースのみを使用してデータベース接続を作成します。このオプションを選択すると、後のステップでマルチ・データ・ソースの一部として選択できるデータ・ソースが制限されます。 JDBCドライバのタイプでデータ・ソースを制限することにより、WebLogic Serverのトランザクション・マネージャで、マルチ・データ・ソースのデータベース接続を使用するグローバル・トランザクションを適切に完了または回復することが可能になります。

9. 接続リクエストを満たすためにマルチ・データ・ソースで使用するデータ・ソースを選択します。

10. 「作成」をクリックします。

マルチ・データ・ソースのデータ・ソースの追加または削除

データ・ソースがデプロイされている間は、そのデータ・ソースをマルチ・データ・ソースに対して追加または削除(マルチ・データ・ソース内のデータ・ソース・リストの動的な変更)できます。

マルチ・データ・ソースに追加するデータ・ソースは、そのマルチ・データ・ソースをデプロイするのと同じターゲットにデプロイする必要があります。 別のサーバーまたはクラスタにデプロイされるマルチ・データ・ソースにデータ・ソースを追加することはできません。 「ターゲット・データソース」を参照してください。

1. 「編集ツリー」で、「サービス」、「データ・ソース」の順に移動します。

2. コンポーネントを編集するマルチ・データ・ソースを選択します。

3. 「データ・ソース」タブで、「データソース・リスト」フィールドを使用して、このマルチ・データ・ソースの対象となるデータ・ソースを変更します。

   • 新しいデータ・ソースを追加するには、データ・ソースの正確な名前を入力し、各データ・ソースをカンマで区切ります。
   • 既存のデータ・ソースを削除するには、データ・ソースの名前を削除します。

     ノート

     リスト内のデータ・ソースの順序によって、マルチ・データ・ソースが接続リクエストのルーティングに使用する順序が決まります。 アルゴリズムとしてフェイルオーバーを使用するマルチ・データ・ソースでは、リストの先頭のデータ・ソースがプライマリ・データ・ソースとみなされます。 以降、同様にセカンダリ、ターシャリとみなされます。

4. 「保存」をクリックします。

Active GridLinkデータ・ソースの作成

Active GridLinkデータ・ソースは、WebLogic ServerとOracleデータベース間の接続を提供します。

GridLinkデータ・ソースの詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「Active GridLinkデータ・ソースの使用」を参照してください。

WebLogic ServerでインストールされていないJDBCドライバが必要な場合は、データ・ソースを設定する前にインストールする必要があります。 「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「WebLogic Serverでインストールされていないサード・パーティJDBCドライバの追加」を参照してください。

1. 「編集ツリー」で、「サービス」、「データ・ソース」の順に移動します。

2. 「新規」をクリックします。

3. 新しいデータ・ソース名を入力します

   名前に次の文字を含めることはできません: @ # $。

4. 「JNDI名」フィールドに、このJDBCデータ・ソースがバインドされるロケーションへのJNDIパスを入力します。 アプリケーションは、接続を予約する際、この名前でJNDIツリー上のデータ・ソースをルックアップします。

5. データ・ソースをデプロイするサーバー・インスタンスまたはクラスタを選択します。

6. 「データソース・タイプ」ドロップダウン・リストから「GridLinkデータソース」を選択します。

7. 「データベース・ドライバ」ドロップダウン・リストから、「JDBCドライバ」を選択します。

   1. 非XAドライバを選択した場合は、「グローバル・トランザクション・プロトコル」を選択します。

      「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「JDBCデータ・ソース・トランザクション・オプション」を参照してください。

8. 接続先のデータベースの接続詳細を入力します:

   • リスナー: データベースをホストするサーバーのDNS名またはIPアドレスとポート番号(コロンで区切って)を入力します。 各リスナーを新しい行に入力します。
   • サービス名: 接続先のデータベースのサービス名を指定します。
   • データベース・ユーザー名: データ・ソースの各接続に使用するデータベース・ユーザー・アカウント名を入力します。
   • パスワード: データベース・ユーザー・アカウントのパスワードを入力します。
   • プロトコル: 必要に応じて、値をTCPからSDPに変更します。 ソケット・ダイレクト・プロトコル(SDP)を使用する場合は、インフィニバンドを使用するようにデータベース・ネットワークを構成する必要があります。

9. ご使用の環境に適用可能な追加の接続詳細を構成します。

10. 「作成」をクリックします。

UCPデータ・ソースの作成

ユニバーサル接続プール(UCP)データ・ソースは、Oracle Universal Connection Poolingを使用してOracleデータベースに接続するユーザーのためのオプションを提供します。 UCPは、Oracle WebLogic Server接続プーリングに対する代替接続プーリング・テクノロジを提供します。

UCPデータ・ソースの詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「ユニバーサル接続プールのデータ・ソースの使用」を参照してください。

WebLogic ServerでインストールされていないJDBCドライバが必要な場合は、データ・ソースを設定する前にインストールする必要があります。 「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「WebLogic Serverでインストールされていないサード・パーティJDBCドライバの追加」を参照してください。

1. 「編集ツリー」で、「サービス」、「データ・ソース」の順に移動します。

2. 「新規」をクリックします。

3. 新しいデータ・ソース名を入力します

   名前に次の文字を含めることはできません: @ # $。

4. 「JNDI名」フィールドに、このJDBCデータ・ソースがバインドされるロケーションへのJNDIパスを入力します。 アプリケーションは、接続を予約する際、この名前でJNDIツリー上のデータ・ソースをルックアップします。

5. データ・ソースをデプロイするサーバー・インスタンスまたはクラスタを選択します。

6. 「データソース・タイプ」ドロップダウン・リストから「UCPデータ・ソース」を選択します。

7. 「データベース・ドライバ」ドロップダウン・リストから、「JDBCドライバ」を選択します。

8. 接続先のデータベースの接続詳細を入力します:

   • URL: データベースのURLを入力します。
   • データベース・ユーザー名: データ・ソースの各接続に使用するデータベース・ユーザー・アカウント名を入力します。
   • パスワード: データベース・ユーザー・アカウントのパスワードを入力します。

9. ご使用の環境に適用可能な追加の接続詳細を構成します。

10. 「作成」をクリックします。

JDBCデータ・ソースの制御

JDBCデータ・ソースを作成した後、WebLogic Remote Consoleのデータ・ソースのインスタンスに対して管理タスクを実行できます。

1. 「モニタリング・ツリー」で、「サービス」、「データ・ソース」、「JDBCデータ・ソース・ランタイムMBeans」の順に移動します。
2. 管理するデータ・ソースを選択し、データ・ソースに対して実行する制御操作を選択します。

「表1」は、JDBCデータ・ソースに対して実行できる制御操作を示します。

表1. JDBCデータ・ソースの制御操作。 「JDBCデータ・ソースに対して実行できる制御操作について説明」。

操作	説明
起動	「起動」を使用して、データ・ソースの個々のインスタンスを起動します。 詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「データ・ソースの起動」を参照してください。
再開	「再開」を使用して、Suspended状態の個々のデータ・ソースを再開します。 詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「接続プールの再開」を参照してください。
中断	「一時停止」を使用して、データ・ソースの個々のインスタンスを一時停止します。 データ・ソースを中断すると、アプリケーションはそのデータ・ソースからデータベース接続を取得できなくなります。 アクティブな接続の処理方法を選択できます: 「グレイスフリィ」を選択すると、データ・ソースが無効としてマークされ、新しい接続リクエストがブロックされます。 予約されている接続がある場合、操作はInactiveTimeoutで指定された期間待機します。それ以外の場合、操作は60秒待機してからすべての接続を中断します。 成功した場合は、ヘルス状態がSuspendedに設定されます。 すべての接続が、データ・ソースの中断前の状態で保持されます。 データ・ソースを再開すると、データ・ソースが一時停止される前に接続を予約していたクライアントは、中断した場所を正確に続行できます。 「強制中断」を選択して、データ・ソースを無効としてマークします。 現在予約されている接続に対するトランザクションはロールバックされ、予約されているすべての接続は破棄されます。 その後アプリケーションがそれらの予約された接続を使用しようとすると失敗します。 成功した場合は、ヘルス状態がSuspendedに設定されます。 この時点で、データ・ソースは破棄された接続と同じ数の新しい接続を作成することで、接続プールの補充を試みます。 「再開」の場合、クライアントは新しい接続を予約して続行する必要があります。 詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「接続プールの一時停止」を参照してください。
停止	「停止」を使用して、データ・ソースの個々のインスタンスを停止します。 アクティブな接続の処理方法を選択できます: アクティブな接続がない場合は、「グレイスフリィ」を選択してデータ・ソースを停止します。 データ・ソースからの接続が現在使用中の場合、「停止」操作は失敗し、ヘルス状態はRunningのままになります。 「強制停止」を選択すると、データ・ソースが停止され、現在のすべての接続ユーザーが強制的に切断されます。 詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「データ・ソースの停止」を参照してください。
縮小	「縮小」を使用して、データ・ソースの個々のインスタンスのデータベース接続プールを最小容量または現在使用中の接続数(いずれか大きい方)に縮小します。 詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「接続プールの縮小」を参照してください。
リセット	「リセット」を使用して、JDBCデータ・ソース内のデータベース接続をリセットします。そのためには、データ・ソース内の接続プールで使用可能なすべてのデータベース接続を閉じてから再作成します。 詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「接続プールのリセット」を参照してください。
キャッシュのクリア	「キャッシュのクリア」を使用して、データ・ソースのインスタンス内のすべての接続の文キャッシュをクリアします。 データ・ソースの各接続で使用されるプリペアド文およびコール可能文をWebLogic Serverがキャッシュするには、データ・ソースに対して文キャッシュを有効にする必要があります。 各接続はそれぞれ固有のキャッシュを持ちますが、各接続のキャッシュは、1つのグループとして構成および管理されます。 詳細は、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「データ・ソースの文キャッシュの管理」および「文キャッシュを使用したパフォーマンスの向上」を参照してください。

JDBCデータ・ソースの統計のモニター

ドメイン内の各データ・ソース・インスタンスに関する様々な統計を監視できます。たとえば、接続プール内の現在のデータベース接続数、現在使用中の接続数、データベース接続の最長待機時間などを監視できます。

1. 「モニタリング・ツリー」で、「サービス」、「データ・ソース」、「JDBCデータ・ソース・ランタイムMBeans」の順に移動します。

   ノート

   マルチ・データ・ソースの場合は、「サービス」、「データ・ソース」、「JDBCマルチ・データ・ソース・ランタイムMBeans」の順に移動して、マルチ・データ・ソースとその関連サブ・データ・ソースを確認することもできます。

2. 統計を表示するデータ・ソースを選択します。

デフォルトでは、このデータ・ソース・ページには、選択したデータ・ソースで使用可能なすべての統計が表示されます。 情報を絞り込むには、関連する統計のみを表示するように表をカスタマイズします。 「表のカスタマイズ」を参照してください。

ターゲット・データソース

JDBCデータソースをターゲット指定すると、そのデータソースの新しいインスタンスがターゲット上に作成されます。 対象としてサーバーを選択した場合、データ・ソースのインスタンスはそのサーバー上に作成されます。 「星団」をターゲットとして選択すると、クラスタ内の「すべて」サーバーにデータ・ソースのインスタンスが作成されます。

データベース接続の作成に使用するJDBCドライバが、データ・ソースのデプロイ先となるすべてのサーバーにインストールされていることを確認します。 「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「WebLogic ServerでのJDBCドライバの使用」を参照してください。

1. 「編集ツリー」で、「サービス」、「データ・ソース」の順に移動します。

2. ターゲットを編集するデータ・ソースを選択します。

3. 「ターゲット」タブで、データ・ソースをデプロイする各サーバーまたはクラスタを選択し、「選択済」の下に移動します。 不要なサーバーまたはクラスタを「使用可能」の下に移動します。

4. 「保存」をクリックします。

JDBCデータ・ソースのテスト

データソースの個々のインスタンスは手動でテストできます。 データ・ソースのテストを実行すると、WebLogic Serverによりデータ・ソースの接続が予約され、標準のテスト用問合せまたは「テスト対象の表名」で指定された問合せを使用してその接続がテストされて、データベース接続が接続プールに戻されます。

データ・ソース内のデータベース接続が正常であり、アプリケーションの正常な実行を維持するために役立つことを定期的に確認することが重要です。 「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「データ・ソースおよびデータベース接続のテスト」を参照してください。

1. JDBCデータ・ソースのテスト・オプションを構成します。

   デフォルトのデータベース接続テスト・オプションを変更して、環境のニーズに合うようにすることもできます。

   1. 「編集ツリー」で、「サービス」、「データ・ソース」の順に移動します。

   2. 接続テスト・オプションを編集するデータ・ソースを選択します。

   3. 「接続プール」タブを選択し、次に「拡張」サブタブを選択します。

   4. ご使用の環境に応じて、次のオプションを変更します。

   5. 「テスト表名」フィールドに、データベース接続をテストする問合せで使用する小さい表の名前を入力します。 標準の問合せは、select 1 from table_nameです。 接続テストとは異なる問合せを使用する場合は、SQLを入力し、その後にスペースとデータベース接続のテストに使用するSQLコードを入力します。

   6. 「予約時の接続のテスト」オプションを有効にすると、アプリケーションがデータ・ソースからの接続をリクエストしたときに、データベース接続をアプリケーションに付与する前にデータベース接続をテストできます。

      このテストを行うと、クライアントがプールに接続をリクエストした場合、そのリクエストに応えるまでに短い遅延が生じますが、クライアントでは有効な接続を確実に受け取ることができます。

   7. 「テスト頻度」フィールドで、WebLogic Serverがバックグラウンド接続テストを実行する頻度(秒単位)を指定します。

   8. 「アイドル・プール接続を信頼する秒数」フィールドに、データベース接続が使用またはテストされている場合、WebLogic Serverは接続テストをスキップする間隔(秒)を入力します。 このオプションは、接続テストのオーバーヘッドを軽減してアプリケーションのパフォーマンスを向上させるのに役立ちます。

   9. 「保存」をクリックし、変更をコミットします。

2. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動し、テストするデータ・ソースがデプロイされているサーバーを選択します。

3. 「サービス」、「データ・ソース」、「JDBCデータ・ソース・ランタイムMBeans」の順に移動します。

4. テストするデータ・ソースを選択します。

5. 「テスト」タブをクリックします。

テストはすぐに行われます。 テスト結果は、「テスト」タブ・ページに表示されます。

RMI JDBCセキュリティの指定

管理者認証のチェックを使用して、データ・ソースとのRMI JDBC通信を保護できます。

RMIでのJDBCの使用の詳細は、「Oracle WebLogic Server用のJDBCアプリケーションの開発」の「WebLogic RMIドライバの使用(非推奨)」を参照してください。

1. Secureオプションを選択する場合は、最初にSSL/TLSリスニング・ポート・チャネルを構成する必要があります。 リスニング・ポートの指定に関する項を参照してください。

2. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。 「拡張フィールドの表示」をクリックします。

3. 「RMI JDBCセキュリティ」ドロップダウン・リストからオプションを選択します:

   • Secure: リモート・クライアントおよびサーバーによるRMI経由のすべての着信アプリケーションJDBCコールを拒否します。 RMI経由での内部サーバー間のJDBC呼出し操作は、「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」および「1フェーズ・コミット」グローバル・トランザクション・プロトコル・オプションで使用できます。 Secureオプションでは、すべてのサーバーがSSLリスニング・ポートで構成されている必要があります。 そうでない場合、すべての操作が例外で失敗します。
   • Compatibility: RMIを介したすべての着信JDBCアプリケーション・コールに対して、DataSourceオブジェクトへの制御されていないアクセスを許可します。 この設定は、強固なネットワーク・セキュリティが設置されているときにのみ使用します。
   • Disabled: ロギング・ラスト・リソースの内部RMI操作、Two-PhaseCommitおよび「1フェーズ・コミット・グローバル・トランザクション・プロトコル」オプションのエミュレートなど、RMIに対するすべてのJDBCコールを無効にします。 詳細は、「Oracle WebLogic Server用のJDBCアプリケーションの開発」の「WebLogic RMIドライバのセキュリティに関する考慮事項」を参照してください。

   WebLogic Server 14.1.2.0.0では、「RMI JDBCセキュリティ」のデフォルト値はSecureです。

4. 「保存」をクリックします。

JDBCデータ・ソースのグローバル・トランザクション・オプションの構成

JDBCデータ・ソースのトランザクション・プロトコルは、データ・ソースからの接続が、トランザクション処理中に、どのように扱われるかを決定します。

1. 「編集ツリー」で、「サービス」、「データ・ソース」の順に移動します。

2. ターゲットを編集するデータ・ソースを選択します。

3. 「トランザクション」タブで、「グローバル・トランザクション・プロトコル」ドロップダウン・リストからトランザクション処理のオプションを選択します。

   トランザクション・オプションの違いを理解するには、「Oracle WebLogic ServerのJDBCデータ・ソースの管理」の「JDBCデータ・ソース・トランザクション・オプション」を参照してください。

   ノート

   データベース接続の作成に、データソースがXA JDBCドライバを使用する場合、データソースからの接続では2フェーズ・コミット・トランザクション・プロトコルのみをサポートします。

4. 「保存」をクリックします。

メッセージング

WebLogic Serverは、Java Messaging Service (JMS)仕様を完全にサポートするエンタープライズ・クラスのメッセージング・システムを提供します。また、標準のJMS APIを超える多数の拡張機能も提供します。

WebLogic Serverプラットフォームに緊密に統合されているため、WebLogic Remote Consoleを介して簡単に監視および管理できる、非常にセキュアなJava EEアプリケーションを構築できます。 XAトランザクションの完全サポートに加え、WebLogic Serverのメッセージング機能では、クラスタリング機能およびサービス移行機能を通じた高可用性も実現できます。また、他のバージョンのWebLogic Serverやサードパーティ・メッセージング・ベンダー製品とのシームレスな相互運用性も可能です。

WebLogic Serverのメッセージング機能は次の領域から構成されます。

• JMSサーバー: JMSキューおよびターゲット指定されているJMSモジュール内のトピック宛先の管理コンテナとして機能します。 JMSサーバーの最も重要な役割は、JMSサーバーの宛先で受信されるすべての永続メッセージ用の永続ストアに関する情報を管理することと、宛先で作成される恒久サブスクライバの状態を管理することです。
• エージェントのストア・アンド・フォワード: WebLogic Serverサブシステム(特にWebLogic JMSおよびWebサービス・サブシステム)に分散されているアプリケーション間でメッセージを確実に配信するためのメカニズムを提供します。 高可用性SAFサービスを使用すると、アプリケーションは、ネットワークの問題またはシステム障害のために、メッセージの送信時に現在使用できないリモート・エンドポイントにメッセージを送信できます。
• JMSシステム・モジュール: グローバル構成JMSリソース(キュー、トピック、テンプレート、接続ファクトリ、JMSストア・アンド・フォワード(SAF)宛先など)が含まれ、weblogic-jmsmd.xsdスキーマに準拠するXMLドキュメントによって定義されます。 JMSシステム・モジュールはDOMAIN_HOME/config/jmsに格納され、モジュールへの参照がJMSSystemResource要素としてドメインの構成ファイルに追加されます。 システム・モジュールは、ドメインに構成されたサーバーおよびクラスタのターゲット指定に対して全面的に利用できます。つまり、同じターゲットにデプロイされているすべてのアプリケーションおよびクライアント・アプリケーションで利用できます。
• メッセージング・ブリッジ: JMS APIをサポートする2つのメッセージング製品間の転送メカニズムを提供します。 メッセージング・ブリッジを使用して、WebLogic JMSの異なる実装間、またはWebLogic JMSと別のメッセージング製品間で相互運用を行います。

関連コンテンツ

詳細については、以下を参照:

• 「Oracle WebLogic ServerのJMSリソースの管理」の「JMSリソース構成の理解」
• 「Oracle WebLogic Serverのストア・アンド・フォワード・サービスの管理」の「ストア・アンド・フォワード・サービスの理解」
• 『Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理』のメッセージング・ブリッジの理解に関する項
• 「WebLogic永続ストアの管理」の「WebLogic永続ストア」

JMSサーバーの作成

JMSサーバーは、サーバーをターゲット指定したJMSモジュール内のキューおよびトピック用の管理コンテナとして機能する、環境関連の構成エンティティです。

JMSサーバーの宛先の主な役割は、宛先に届く永続メッセージに対してどの永続ストアが使用されるかに関する情報を保持し、宛先に作成された永続サブスクライバの状態を維持することです。

また、JMSサーバーは宛先のメッセージ・ページングを管理し、オプションで、ターゲット宛先のメッセージおよびバイトしきい値、およびサーバー・レベルの割当てを管理できます。 また、ターゲット宛先のコンテナとして、JMSサーバーに対して加えられた構成の変更または実行時の変更を、ホストしているすべての宛先に対して有効にできます。

詳細は、「Oracle WebLogic ServerのJMSリソースの管理」の「JMSサーバーの概要」および「JMSサーバーおよび永続ストアの構成」を参照してください。

1. 「編集ツリー」で、「サービス」、「JMSサーバー」の順に移動します。

2. 「新規」をクリックします。

3. 新しいJMSサーバーの名前を入力し、「作成」をクリックします。

4. 「永続ストア」ドロップダウン・リストから、このJMSサーバーが永続メッセージを格納するストアを選択します。

   WebLogic Serverによって提供されるデフォルトの永続ストアを使用する場合は、「永続ストア」を「なし」に設定したままにします。

   カスタム永続ストアがまだ構成されていない場合は、「永続ストア」の横にある「その他」ボタンをクリックし、「新規ファイル・ストア」または「新規JDBCストア」を選択します。 次に、「ファイル・ストアの作成」または「JDBCストアの作成」の手順に従います。 「永続ストア」ドロップダウン・リストから、新しく作成したストアを選択します。

   ノート

   JMSサーバーのターゲットとして:

   • 移行可能なターゲットが指定されている場合、デフォルトのストアは使用できません。 カスタム・ストアを構成し、そのターゲットとして同じ移行可能なターゲットを指定する必要があります。

   • 動的クラスタが指定されている場合、同じ動的クラスタをターゲットとするカスタム永続ストアか、各動的クラスタ・メンバーで利用可能なデフォルトのストアを使用するカスタム永続ストアが必要です。

     「配布ポリシー」をSingletonに設定したカスタム・ストアを使用して、スタンドアロン(非分散)宛先をホストします。

     「配布ポリシー」をDistributedに設定したカスタム・ストアを使用して、分散宛先をホストします。

5. 追加のJMSサーバー属性を構成します。 すべてのオプションを表示するには、必ず「拡張フィールドの表示」をクリックしてください。

6. 「保存」をクリックします。

7. 「ターゲット」タブの「ターゲット」ドロップダウン・リストから、JMSサーバーをデプロイするサーバー・インスタンス、クラスタまたは移行可能ターゲットを選択します。

   JMSサーバーをスタンドアロンのWebLogic Serverインスタンス、クラスタまたは移行可能なターゲット・サーバーにターゲット指定できます。 移行可能な対象は、JMSサーバーなど、固定サービスをホストできる可能性のある、クラスタ内の一連のWebLogic Serverインスタンスを定義します。

   クラスタ化されたサーバー環境でJMSサーバーを使用している場合は、「Oracle WebLogic ServerのJMSリソースの管理」の「JMSサーバーおよび永続ストアの構成」にあるガイダンスを確認してください。

8. 「保存」をクリックします。

JMSサーバーのモニター

アクティブなJMSサーバーの実行時統計をモニターできます。 また、JMSサーバーの宛先、トランザクション、接続およびサーバー・セッション・プールの実行時情報にアクセスすることもできます。

詳細は、「Oracle WebLogic ServerのJMSリソースの管理」の「JMS統計のモニタリングおよびメッセージの管理」を参照してください。

1. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動し、JMSサーバーがデプロイされているサーバーを選択します。 次に、「サービス」、「メッセージング」、「JMSランタイム」、「JMSサーバー」に進みます。

   ドメイン内のすべてのJMSサーバーを比較する場合は、かわりに「サービス」、「メッセージング」、「JMSランタイム」、「JMSサーバー」の順に移動します。

2. 実行時情報を表示するJMSサーバーを選択します。

JMSシステム・モジュールの作成

JMSリソースは、標準のJava EEモジュールと同様のモジュールとして構成されて格納されます。 このようなリソースには、キュー、トピック、接続ファクトリ、テンプレート、宛先キー、割り当て、分散キュー、分散トピック、外部サーバー、およびJMSストア・アンド・フォワード(SAF)パラメータがあります。

システム・モジュールは、ドメインに構成されたサーバーおよびクラスタのターゲット指定に対して全面的に利用できます。つまり、同じターゲットにデプロイされているすべてのアプリケーションおよびクライアント・アプリケーションで利用できます。

JMS構成リソースは、Java EEアプリケーションをパッケージ・モジュールとしてデプロイ可能なアプリケーション・モジュールとして管理することもできます。パッケージ・モジュールは、包含アプリケーションでのみ使用できます。また、そのモジュールで定義されたリソースへのグローバル・アクセスを提供するスタンドアロン・モジュールとして管理することもできます。

詳細は、「Oracle WebLogic ServerのJMSリソースの管理」の「JMSモジュールの概要」を参照してください。

1. 「編集ツリー」で、「サービス」、「JMSモジュール」の順に移動します。

2. 「新規」をクリックします。

3. 新しいJMSシステム・モジュールの名前を入力し、「作成」をクリックします。

4. 「ターゲット」タブの「ターゲット」ドロップダウン・リストから、JMSシステム・モジュールをデプロイするサーバー・インスタンスまたはクラスタを選択します。

5. 「保存」をクリックします。

   JMSシステム・モジュールのナビゲーション・ツリーの「JMSモジュール」の下に、新しいノードが表示されます。

6. JMSシステム・モジュールの新しいノードを展開して、構成可能なJMSシステム・リソースの子を確認します。 「JMSシステム・モジュールのリソースの構成」を参照してください。

JMSシステム・モジュールのリソースの構成

JMSシステム・モジュールを作成した後には、スタンドアロンのキューおよびトピック、分散キューおよびトピック、接続ファクトリ、JMSテンプレート、宛先ソート・キー、宛先の割当て、外部サーバー、JMS SAF (ストア・アンド・フォワード)パラメータなどの、モジュールのリソースを作成できます。

詳細は、「Oracle WebLogic ServerのJMSリソースの管理」の「モジュールの構成可能なJMSリソース」を参照してください。

1. 「編集ツリー」で、「サービス」、「JMSモジュール」の順に移動します。

2. リソースを構成するJMSシステム・モジュールを選択します。

3. ナビゲーション・ツリーで、選択したJMSシステム・モジュールの子ノードとして、構成するリソースをクリックします。

   次のJMSシステム・リソースを使用できます:

   • 「割当」- 宛先で使用できるシステム・リソースの割当てを制御します。
   • 「テンプレート」- 類似した構成設定を持つ複数のキューおよびトピックを効率的に定義できます。
   • 「宛先キー」- 宛先に届くメッセージのソート順を定義します。
   • 「トピック」- パブリッシュ/サブスクライブ(pub/sub)宛先を定義することで、1つのアプリケーションから複数のアプリケーションに対してメッセージを送信できます。
   • 「キュー」- ポイント・ツー・ポイント(PTP)宛先を定義することで、1つのアプリケーションから別の1つのアプリケーションにメッセージを送信できます。
   • 「接続ファクトリ」- JMSクライアントでJMS接続を作成できる、一連の接続構成パラメータを定義します。
   • 「分散トピック」- 単一の論理的なトピックとして、クライアントからアクセス可能なJMSトピックの1つの単位です。 分散トピックのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各トピック・メンバーは個々のJMSサーバーに属しています。
   • 「分散キュー」- 単一の論理的なキューとして、クライアントからアクセス可能なJMSキューの1つの単位です。 この分散キューのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各キュー・メンバーは個々のJMSサーバーに属しています。
   • 「外部サーバー」- 外部のWebLogicサーバーであるサードパーティのJMSプロバイダを表します。 外部サーバーには、ローカル・サーバー・インスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。これにより、1つのJNDIディレクトリに対して複数の外部接続ファクトリと宛先のオブジェクトを定義できます。
   • 「SAFインポート済み宛先」- リモートのサーバー・インスタンスまたはクラスタにおけるJMS宛先を表す、インポート済みSAF (ストア・アンド・フォワード)キューまたはトピックのコレクションを定義します。
   • 「リモートSAFコンテキスト」- SAFインポート済みキューまたはトピックがリモート宛先への接続に使用する、SAFログイン・コンテキストを指定します。
   • 「SAFエラー処理」- SAFサービスがリモートの宛先へのメッセージ転送に失敗した場合に行うアクションを指定します。 JMSモジュールの構成方法の詳細は、「Oracle WebLogic ServerのJMSリソースの管理」の「基本的なJMSシステム・リソースの構成」を参照してください。

4. 選択したリソースに必要な情報を入力します。

   特定のリソースでは、適切なサブデプロイメントを構成することをお薦めします。 サブデプロイメントとは、ターゲット可能なJMSモジュール・リソース(キュー、トピック、接続ファクトリなど)をグループ化し、サーバー・リソース(JMSサーバー、サーバー・インスタンス、クラスタなど)にターゲット指定するメカニズムです。

   ほとんどのJMSリソースには、作成後に変更できる追加パラメータがあります。 たとえば、デフォルトのメッセージのしきい値を変更したり、キュー、トピック、およびテンプレートに対してメッセージのロギングを有効化したりすることが可能です。

5. 「作成」をクリックします。

ストア・アンド・フォワード・エージェントの作成

ストア・アンド・フォワード(SAF)サービスを使用すると、WebLogic Serverでは、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信することができます。

ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存されて、リモートの宛先が使用可能になった時点で転送されます。

SAFエージェントは、ローカル送信エンドポイントとリモート受信エンドポイントの間でメッセージのストア・アンド・フォワードを行います。 SAFエージェントは、送信機能または受信機能のみを持つように構成することも、両方の機能を持つように構成することもできます。 JMS SAFでは、JMSメッセージの送信側に送信エージェントのみが必要になります。 Web Services Reliable Messaging (WSRM) SAFには、送信エージェントと受信エージェントの両方が必要です。

詳細は、「Oracle WebLogic Serverのストア・アンド・フォワード・サービスの管理」の「SAFサービス・エージェント」を参照してください。

1. 「編集ツリー」で、「サービス」、「SAFエージェント」の順に移動します。

2. 「新規」をクリックします。

3. 新しいSAFエージェントの名前を入力し、「作成」をクリックします。

4. 「永続ストア」ドロップダウン・リストから、このSAFエージェントが永続メッセージを格納するストアを選択します。

   WebLogic Serverによって提供されるデフォルトの永続ストアを使用する場合は、「永続ストア」をNoneに設定したままにします。

   カスタム永続ストアがまだ構成されていない場合は、「永続ストア」の横にある「その他」ボタンをクリックし、「新規ファイル・ストア」または「新規JDBCストア」のいずれかをクリックします。 次に、「ファイル・ストアの作成」または「JDBCストアの作成」の手順に従います。

   • SAFエージェントがクラスタにターゲット指定されている場合、SAFエージェントは、「配布ポリシー」がDistributedに設定されたカスタム・ストアを使用し、同じクラスタにターゲット指定されている必要があります。

   • SAFエージェントは、構成された(非動的)クラスタにターゲット指定されている場合にのみデフォルトのストアを使用できます。

   • SAFエージェントを移行可能ターゲットにターゲット指定する場合は、同じ移行可能ターゲットにターゲット指定されたカスタム・ストアを構成する必要があります。

5. 「エージェント・タイプ」ドロップダウン・リストから、次のいずれかのオプションを選択します:

   • 両方: 送信エージェントと受信エージェントの機能を備えたエージェントを構成します。
   • Sending-only: 永続ストレージにメッセージを格納し、受信側にメッセージを転送し、確認応答が間に合わずにメッセージを再送信するエージェントを構成します。
   • 受信専用: 受信エージェントから送信されたメッセージの検出と重複排除、および最終的な宛先へのメッセージの配信を行うエージェントを構成します。 JMS SAFユーザーは、構成済の受信エージェントを必要としないため、Sending-onlyを選択する必要があります。

6. 追加のSAFエージェント属性を構成します。 すべてのオプションを表示するには、必ず「拡張フィールドの表示」をクリックしてください。

7. 「保存」をクリックします。

8. 「ターゲット」タブの「ターゲット」ドロップダウン・リストから、SAFエージェントをデプロイするサーバー・インスタンス、クラスタまたは移行可能なターゲットを選択します。

   クラスタをターゲット指定する場合、SAFエージェントは、「配布ポリシー」がDistributedに設定されたカスタム・ストアを使用し、同じクラスタをターゲット指定する必要があります。

   SAFエージェントを移行可能ターゲットにターゲット指定する場合は、SAFエージェントをクラスタ全体または他のサーバー・ターゲットにターゲット指定することはできません。

9. 「保存」をクリックします。

SAFエージェントのモニター

アクティブなSAFエージェントの実行時情報を表示できます。

詳細は、「Oracle WebLogic Serverのストア・アンド・フォワード・サービスの管理」の「SAFエージェントのモニタリング」を参照してください。

1. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動し、SAFエージェントがデプロイされているサーバーを選択します。 次に、「サービス」、「メッセージング」、「SAFランタイム」、「エージェント」に進みます。

   ドメイン内のすべてのSAFエージェントを表示する場合は、かわりに「サービス」、「メッセージング」、「SAFランタイム」、「エージェント」の順に移動します。

2. 実行時情報を表示するSAFエージェントを選択します。

JMSブリッジ宛先の作成

JMSブリッジ宛先インスタンスは、ブリッジ・インスタンスの実際のソースおよびターゲットのJMSブリッジ宛先を定義します。

メッセージング・ブリッジ・インスタンスにマップされる各ソースおよび各ターゲット宛先のJMSブリッジ宛先インスタンスを構成する必要があります。 したがって、ソースJMSブリッジ宛先の属性の定義が終了したら、次のステップを繰り返してターゲットJMSブリッジ宛先を構成します。

1. 「編集ツリー」で、「サービス」、「JMSブリッジ宛先」の順に移動します。

2. 「新規」をクリックします。

3. 新しいJMSブリッジ宛先の名前を入力し、「作成」をクリックします。

4. 「アダプタJNDI名」フィールドで、ブリッジ宛先との通信に使用されるアダプタのJNDI名を指定します。

   入力するアダプタ名の詳細は、「Oracle WebLogic ServerのWebLogicメッセージング・ブリッジの管理」の「リソース・アダプタ」を参照してください。

5. 「接続URL」フィールドで、このJMSブリッジ宛先の接続URLを指定します。

6. 「接続ファクトリのJNDI名」フィールドで、このJMSブリッジ宛先の接続ファクトリのJNDI名を指定します。

7. 「宛先JNDI名」フィールドで、このJMSブリッジ宛先の宛先JNDI名を指定します。

8. 環境に適用可能な追加属性を構成します。

9. 「保存」をクリックします。

10. 一致するJMSブリッジ宛先を作成するには、これらのステップを繰り返します。

    最初に「ソース」 JMSブリッジ宛先を作成した場合は、ここで「ターゲット」宛先を作成する必要があります。

    最初に「ターゲット」 JMSブリッジ宛先を作成した場合は、ここで「ソース」宛先を作成する必要があります。

メッセージング・ブリッジ・インスタンスの作成

WebLogicメッセージング・ブリッジを使用して、2つのメッセージング製品間の転送メカニズムを構成できます。 メッセージング・ブリッジを使用して、メッセージング・アプリケーションを統合できます。 メッセージング・ブリッジ・インスタンスは、構成済のソース・ブリッジ宛先およびターゲット・ブリッジ宛先と通信します。

ソース宛先をターゲット宛先にマッピングするたびに、メッセージング・ブリッジ・インスタンスを構成する必要があります。これは、宛先が別のWebLogic JMS実装でも、サード・パーティのJMSプロバイダでも同様です。

マッピングするソース宛先とターゲット宛先、メッセージ・フィルタリング・セレクタ、サービスの品質(quality of service: QOS)、トランザクション・セマンティクス、再接続パラメータなどを各インスタンスで定義します。

詳細は、「Oracle WebLogic ServerのWebLogicメッセージング・ブリッジの管理」の「メッセージング・ブリッジの理解」を参照してください。

1. まだ作成していない場合は、「JMSブリッジ宛先の作成」の説明に従って、ソースJMSブリッジ宛先とターゲットJMSブリッジ宛先を作成および構成します。

2. 「編集ツリー」で、「サービス」、「メッセージング・ブリッジ」の順に移動します。

3. 「新規」をクリックします。

4. 新しいメッセージング・ブリッジ・インスタンスの名前を入力し、「作成」をクリックします。

5. 「ソース・ブリッジ宛先」ドロップダウン・リストから、ソース宛先を選択します。

6. 「ターゲット・ブリッジ宛先」ドロップダウン・リストから、ターゲットの宛先を選択します。

7. 環境に適用可能な追加属性を構成します。

8. 「保存」をクリックします。

メッセージング・ブリッジを使用して、異なるリリースのWebLogic ServerまたはリモートのWebLogicドメインの宛先にアクセスする場合は、「Oracle WebLogic ServerのWebLogicメッセージング・ブリッジの管理」の「異なるWebLogic Serverリリースまたは外部プロバイダとの相互運用」で説明されている相互運用性ガイドラインのいくつかを手動で実装する必要があります。

ファイル・ストアの作成

ファイル・ストアは、永続JMSメッセージや恒久サブスクライバ情報などのサブシステム・データを格納するためのファイルベースのリポジトリです。

永続ストアは、永続性を必要とするWebLogic Serverサブシステムおよびサービス用の組込みの高パフォーマンス・ストレージ・ソリューションを提供します。 たとえば、永続ストアは、永続JMSメッセージや恒久サブスクライバ情報を格納したり、ストア・アンド・フォワード機能を使用して、使用不能な宛先へのメッセージを一時的に格納したりできます。

永続ストアでは、JDBC対応データベース(JDBCストア)への永続性もサポートされます。 かわりに、「JDBCストアの作成」を参照してください。

1. ファイル・ストア用のディレクトリをファイル・システムに作成します。

   ディレクトリは、すべての候補サーバー・メンバーからアクセスできる必要があります。 信頼性を最大限に高めるには、それ自体が高可用性である共有ストレージ・ソリューションを使用します。 たとえば、ストレージ・エリア・ネットワーク(SAN)やデュアル・ポートSCSIディスクなどです。

2. 「編集ツリー」で、「サービス」、「ファイル・ストア」の順に移動します。

3. 「新規」をクリックします。

4. 新しいファイル・ストアの名前を入力し、「作成」をクリックします。

5. 「ディレクトリ」フィールドに、ファイル・ストアが保持されるファイル・システム上のディレクトリへのパスを入力します。

6. 環境に適用可能な追加設定を変更します。

7. 「保存」をクリックします。

8. 「ターゲット」タブの「ターゲット」ドロップダウン・リストから、ファイル・ストアをデプロイするサーバー・インスタンス、動的クラスタまたは移行可能なターゲットを選択します。

   動的クラスタを選択する場合、JMSサーバーと同じ動的クラスタを指定する必要があります。

   移行可能なターゲットを選択する場合、移行可能なJMSサーバーまたはSAFエージェントと同じ移行可能なターゲットを共有する必要があります。

9. 「保存」をクリックします。

JDBCストアの作成

JDBCストアは、永続JMSメッセージや恒久サブスクライバ情報などのサブシステム・データを格納するためのJDBCでアクセス可能なデータベースです。

永続ストアは、永続性を必要とするWebLogic Serverサブシステムおよびサービス用の組込みの高パフォーマンス・ストレージ・ソリューションを提供します。 たとえば、永続ストアは、永続JMSメッセージや恒久サブスクライバ情報を格納したり、ストア・アンド・フォワード機能を使用して、使用不能な宛先へのメッセージを一時的に格納したりできます。

永続ストアでは、ファイルベースのストア(ファイル・ストア)への永続性もサポートされます。 かわりに、「ファイル・ストアの作成」を参照してください。

1. まだ作成していない場合は、JDBCデータ・ソースを作成します。 データソースを参照してください。

   JDBCストアでは、非XA JDBCドライバを使用し、「グローバル・トランザクションのサポート」が無効になっているJDBCデータ・ソースを使用する必要があります。 この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。 たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。

   すべての候補サーバーがデータ・ソースにアクセスできることを確認します。

2. 「編集ツリー」で、「サービス」、「JDBCストア」の順に移動します。

3. 「新規」をクリックします。

4. 新しいJDBCストアの名前を入力します。

5. 「プレフィクス名」フィールドで、複数のインスタンスで使用するために、このJDBCストアの表名の先頭に追加するプレフィクス名を指定します。

6. 「データ・ソース」ドロップダウン・リストから、データ・ソースを選択します。

7. 「ターゲット」ドロップダウン・リストから、ファイル・ストアをデプロイするサーバー・インスタンス、動的クラスタまたは移行可能ターゲットを選択します。

   動的クラスタを選択する場合、JMSサーバーと同じ動的クラスタを指定する必要があります。 移行可能なターゲットを選択する場合、移行可能なJMSサーバーまたはSAFエージェントと同じ移行可能なターゲットを共有する必要があります。

8. 必要に応じて、残りの設定を変更します。

9. 「保存」をクリックします。

パス・サービスの作成

パス・サービスは、メッセージのグループのメッセージ・リソースへのマッピング(分散宛先のメンバーやストア・アンド・フォワード・エージェントなど)を格納するために使用できる永続マップです。

パス・サービスは、メッセージをホストするクラスタ・サーブレット、分散キュー・メンバーまたはストア・アンド・フォワード・エージェントのメンバーに固定することによって、メッセージの順序付けを強制する方法を提供します。

詳細は、「Oracle WebLogic ServerのJMSリソースの管理」の「WebLogicパス・サービスの使用」を参照してください。

1. まだ作成していない場合は、次のそれぞれについて少なくとも1つを作成して構成: クラスタ、カスタム永続ストアおよびストア・アンド・フォワード(SAF)エージェント。 JMSシステム・モジュールを構成することもできます。

   参照:

   • クラスタの構成

   • 「ファイル・ストアの作成」または「JDBCストアの作成」

   • ストア・アンド・フォワード・エージェントの作成

   • JMSシステム・モジュールの作成

2. 「編集ツリー」で、「サービス」、「パス・サービス」の順に移動します。

3. 「新規」をクリックします。

4. 新しいパス・サービスの名前を入力し、「作成」をクリックします。

5. 「永続ストア」ドロップダウン・リストから、このパス・サービスが永続メッセージを格納するストアを選択します。

   ノート

   パス・サービスを移行可能なターゲットにターゲット指定する場合は、カスタム・ストアを使用する必要があります。 パス・サービスをクラスタにターゲット指定する場合は、同じターゲットを持つカスタム・ストア、「移行ポリシー」をAlwaysに設定し、「配布ポリシー」をSingletonに設定する必要があります。

   WebLogic Serverによって提供されるデフォルトの永続ストアを使用する場合は、「永続ストア」をNoneに設定したままにします。 ただし、デフォルト・ストアのかわりにカスタム・ストアを使用することをお薦めします。

6. 「保存」をクリックします。

7. 「ターゲット」タブの「ターゲット」ドロップダウン・リストから、パス・サービスをデプロイするクラスタ、クラスタ・メンバーまたは移行可能なターゲットを選択します。

8. 「保存」をクリックします。

JMSメッセージの管理

モニターしているスタンドアロン・キュー、分散キューまたは永続トピック・サブスクライバで使用可能なJMSメッセージを管理できます。

1. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動し、移動するメッセージをホストするサーバーを選択します。
2. 選択したサーバーで、「サービス」、「メッセージング」、「JMSランタイム」、「JMSサーバー」、myJMSServer、「宛先」の順に移動し、移動するメッセージを現在ホストしているJMS宛先を選択します。
3. 「メッセージ」タブで、アクションを実行するメッセージをすべて選択し、アクションのボタンをクリックします。 「表2」を参照してください。

表2. JMSメッセージ・アクション。 JMSメッセージに対して実行できるアクション。

Action	説明
削除	選択したJMSメッセージを現在のキューから削除します。 「Oracle WebLogic ServerのJMSリソースの管理」の「メッセージの削除」を参照してください。
エクスポート	現在のキューから選択したメッセージをエクスポートします。これにより、JMSメッセージがXMLまたは直列化された形式に変換されます。 「Oracle WebLogic ServerのJMSリソースの管理」の「メッセージのエクスポート」を参照してください。
インポート	選択したメッセージをXML形式でインポートします。これにより、現在のキューでメッセージが作成または置換されます。 「Oracle WebLogic ServerのJMSリソースの管理」の「メッセージのインポート」を参照してください。
移動	選択したJMSメッセージを現在のキューから別の宛先(別のJMSサーバー上の宛先を含む)に転送します。 メッセージを移動しても、メッセージの識別子は変更されません。 移動したメッセージがすでにターゲット宛先に存在する場合は、同じ識別子の重複メッセージが宛先に追加されます。 「Oracle WebLogic ServerのJMSリソースの管理」の「メッセージの移動」を参照してください。

JNDI表内のオブジェクトの表示

WebLogic Remote Consoleを使用して、Java Naming and Directory Interface (JNDI)表のオブジェクトを表示できます。

WebLogic Serverは、エンタープライズ内の複数のネーミング・サービスおよびディレクトリ・サービスに標準の統合インタフェースを提供する手段として、Java EEプラットフォームのJNDIを実装します。 「Oracle WebLogic ServerのJNDIアプリケーションの開発」の「WebLogic JNDIの理解」を参照してください。

WebLogic Server Java EEサービスおよびコンポーネント(RMI、JMS、EJB、JDBCデータ・ソースなど)をJNDI表にロードできます。 通常、これらのオブジェクトは、「JNDI名」属性を構成してサーバーにデプロイするときにJNDI表にバインドされます。

1. 「モニタリング・ツリー」で、「環境」、「サーバー」、myServerの順に移動します。

2. JNDIタブをクリックして、JNDIオブジェクトを表示します。

   ノート

   「The JNDI」タブは、管理サーバーによって実行され、アクセス可能なサーバーでのみ表示されます。

外部JNDIプロバイダの作成

外部JNDIプロバイダは、WebLogic Server環境の外部にあるJNDIツリーを表します。 これは、別のサーバー環境内にあるJNDIツリーでも、外部Javaプログラム内のJNDIツリーでもあり得ます。

外部JNDIプロバイダを設定することで、WebLogic Serverインスタンスでバインドされたオブジェクトを使用するのと同じように、リモート・オブジェクトを簡単にルックアップして使用できます。 つまり、単一のWebLogic Server接続を使用して、ローカル・オブジェクトにもリモート・オブジェクトにもアクセスできます。

1. 「編集ツリー」で、「サービス」、「外部JNDIプロバイダ」の順に移動します。

2. 「新規」をクリックします。

3. 新しい外部JNDIプロバイダの名前を入力し、「作成」をクリックします。

4. 「初期コンテキスト・ファクトリ」フィールドに、JNDIプロバイダにアクセスするためにインスタンス化する必要があるクラスの名前を入力します。 このクラス名は、JNDIプロバイダと、使用されているベンダーによって決まります。 この値は標準のJNDIプロパティjava.naming.factory.initialに対応します。

5. 「プロバイダURL」フィールドに、WebLogic ServerがJNDIプロバイダへの接続に使用するURLを入力します。 この値は標準のJNDIプロパティjava.naming.provider.urlに対応します。

6. 「ユーザー」フィールドに、外部JNDIへのアクセスを許可されたユーザーの名前を入力し、「パスワード」にユーザー・アカウントのパスワードを入力します。

7. 「ターゲット」タブをクリックし、この外部JNDIプロバイダをデプロイするサーバーまたはクラスタを選択します。

8. JNDIプロバイダに追加のプロパティを指定する場合は、「プロパティ」タブをクリックします。

   これらのプロパティは直接JNDIプロバイダのInitialContextクラスのコンストラクタに渡されます。

   1. 「プロパティ」表で、+をクリックして新しい行を追加します。

   2. 「プロパティ名」の下のセルをダブルクリックし、プロパティの名前を入力します。

   3. 「プロパティ値」の下のセルをダブルクリックし、プロパティの値を入力します。

   4. 「保存」をクリックします。

9. 次に、ローカルJNDI表の名前と外部(リモート)表内のオブジェクト間の関係を設定する外部JNDIオブジェクト・リンクを作成する必要があります。

10. 作成した外部JNDIプロバイダのナビゲーション・ツリーでノードを展開し、「外部JNDIリンク」子ノードを開きます。

11. 「新規」をクリックします。

12. 外部JNDIリンクの名前を入力します。

13. 「ローカルJNDI名」フィールドで、リモートJNDIオブジェクトがローカル・サーバーのJNDIツリーでバインドされ、ローカル・サーバー上のオブジェクトのルックアップに使用される名前を指定します。

14. 「リモートJNDI名」フィールドで、外部JNDIディレクトリ内で検索されるリモート・オブジェクトの名前を指定します。

15. 「作成」をクリックします。

XMLリソース

WebLogic Serverには、2つの異なるタイプのXMLリソースを構成できます。

• XMLレジストリ。XMLドキュメントの解析および変換時に使用するWebLogic Serverの代替サーバー全体のXMLパーサーおよびトランスフォーマを指定できます。 XMLレジストリを使用して、外部エンティティのローカル・コピーおよびこれらのエンティティのキャッシュ手順を指定することもできます。 XMLレジストリの作成を参照してください。
• XMLエンティティ・キャッシュ。WebLogic Serverが外部エンティティのキャッシュに使用するキャッシュを構成するために使用できます。 XMLエンティティ・キャッシュの作成を参照してください。

XMLレジストリおよびエンティティ・キャッシュは必要な数だけ作成できます。 ただし、WebLogic Serverの特定のサーバー・インスタンスには、各タイプの1つのみを関連付けることができます。

WebLogic ServerでのXMLリソースの使用方法の詳細は、「Oracle WebLogic Server用XMLアプリケーションの開発」を参照してください。

XMLレジストリの作成

XMLレジストリは、WebLogic ServerのXMLリソースを構成および管理するための機能です。 XMLリソースには、デフォルトのパーサー、トランスフォーマ・ファクトリおよび外部エンティティ解決が含まれます。

特に、XMLレジストリを使用して次のものを指定します:

• デフォルトでインストールされるパーサーではなく、XML文書の解析時にデフォルトで使用される、サーバー全体の代替XMLパーサー。 サーバー全体の代替XMLパーサーを使用するには、javax.xml.parsers.DocumentBuilderFactoryインタフェースを実装するクラス(DOMモードの解析に使用)の名前、およびjavax.xml.parsers.SaxParserFactoryインタフェースを実装するクラス(SAXモードの解析に使用)の名前を指定します。
• 特定のドキュメントのタイプを解析する場合に使用される特定のXMLパーサー。
• デフォルトのトランスフォーマのかわりとなる、サーバー全体の代替トランスフォーマ。 サーバー全体の代替トランスフォーマを使用するには、XMLドキュメントの変換に使用されるjavax.xml.transform.TransformerFactoryインタフェースを実装するクラスの名前を指定します。
• エンティティのローカル・コピーで解決される外部エンティティ。 これらのエンティティを指定すると、管理サーバーはそれらのローカル・コピーをファイル・システムに格納し、解析時に自動的にサーバーのパーサーに配布します。 この機能を使用すれば、SAX EntityResolversの作成と設定が不要になります。
• Webからの取得後にWebLogic Serverによってキャッシュされる外部エンティティ。 WebLogic Serverがエンティティを再取得するまでにこれらの外部エンティティをキャッシュする時間、およびWebLogicが最初にエンティティを取得するタイミング(アプリケーションの実行時に、またはWebLogic Serverの起動時)を指定します。

XMLレジストリはいくつでも作成できますが、特定のWebLogic Serverのインスタンスに関連付けられるXMLレジストリは1つのみです。

WebLogic ServerのインスタンスにXMLレジストリが関連付けられていない場合、ドキュメントの解析や変換にはデフォルトのパーサーおよびトランスフォーマが使用されます。 デフォルトのパーサーおよびトランスフォーマは、JDKに付属しています。

WebLogic ServerのインスタンスにXMLレジストリが関連付けられると、XML構成の全オプションが、そのサーバーを使用するXMLアプリケーションで使用可能となります。

1. 「編集ツリー」で、「サービス」、「XML登録」の順に移動します。

2. 「新規」をクリックします。

3. XMLレジストリの名前を入力し、「作成」をクリックします。

4. デフォルトのパーサーおよびトランスフォーマを使用する予定がない場合は、代替設定を指定する必要があります。

   1. 「文書ビルダー・ファクトリ」フィールドに、javax.xml.parsers.DocumentBuilderFactoryインタフェースを実装するクラスの完全修飾名を入力します。

   2. 「SAXパーサー・ファクトリ」フィールドに、javax.xml.parsers.SaxParserFactoryインタフェースを実装するクラスの完全修飾名を入力します。

   3. 「変圧器ファクトリ」フィールドに、javax.xml.transform.TransformerFactoryインタフェースを実装するクラスの完全修飾名を入力します。

   4. 「保存」をクリックします。

次に、XMLレジストリをWebLogic Serverインスタンスに関連付ける必要があります。 「XMLレジストリのサーバーへのターゲット指定」を参照してください。

XMLレジストリのサーバーへのターゲット指定

WebLogic Serverには、1つのXMLレジストリのみを関連付けることができます。 ただし、同じXMLレジストリを複数のWebLogic Serverインスタンスにターゲット指定できます。

1. まだ作成していない場合は、XMLレジストリを作成します。 XMLレジストリの作成を参照してください。

2. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。

3. XMLレジストリの対象となるサーバーを選択します。

4. 「拡張フィールドの表示」を有効にし、「XMLレジストリ」ドロップダウン・リストから、このサーバーにターゲット指定するXMLレジストリを選択します。

5. 「保存」をクリックします。

XMLエンティティ・キャッシュの作成

WebLogic Serverが、サーバー起動時またはエンティティが最初に参照されるときに、EARアーカイブのメイン・ディレクトリに対する相対的なURLまたはパス名で参照される外部エンティティをキャッシュするように指定できます。 これを指定するには、最初にXMLエンティティ・キャッシュを作成し、次に特定のエンティティに対してキャッシュするタイミングを指定します。

外部エンティティをキャッシュすると、リモート・アクセス時間が節約され、ネットワークまたは管理サーバーのダウンによりXMLドキュメントの解析中に管理サーバーにアクセスできなくなった場合には、ローカル・バックアップを利用できます。

1. 「編集ツリー」で、「サービス」、「XMLエンティティ・キャッシュ」の順に移動します。

2. 「新規」をクリックします。

3. XMLエンティティ・キャッシュの名前を入力し、「作成」をクリックします。

4. 必要に応じて、新しいXMLエンティティ・キャッシュの構成オプションを更新します。

5. 「保存」をクリックします。

次に、XMLエンティティ・キャッシュをWebLogic Serverインスタンスに関連付ける必要があります。 「サーバーへのXMLエンティティ・キャッシュのターゲット指定」を参照してください。

サーバーへのXMLエンティティ・キャッシュのターゲット指定

WebLogic Serverインスタンスには、1つのXMLエンティティ・キャッシュのみを関連付けることができます。

1. まだ作成していない場合は、XMLエンティティ・キャッシュを作成します。 XMLエンティティ・キャッシュの作成を参照してください。

2. 「編集ツリー」で、「環境」、「サーバー」の順に移動します。

3. XMLエンティティ・キャッシュ先のサーバーを選択します。

4. 「拡張フィールドの表示」を有効にし、「XMLエンティティ・キャッシュ」ドロップダウン・リストから、このサーバーにターゲット指定するXMLエンティティ・キャッシュを選択します。

5. 「保存」をクリックします。

JavaMailへのアクセスの構成

メール・サーバーを構成したり、既存のメール・サーバーのユーザー資格証明を確立できます。 メール・セッションおよびJavaMail APIは、メール・サーバー機能を提供しません。 これらは、アプリケーションが既存のメール・サーバーからデータを送受信できるようにするだけです。

JavaMail APIは、アプリケーションおよび他のJava EEモジュールに、ネットワークまたはインターネット上のInternet Message Access Protocol (IMAP)およびSimple Mail Transfer Protocol (SMTP)対応のメール・サーバーへのアクセスを提供します。

JavaMailの参照実装では、メール・サーバーへの接続用に、メール・ホスト、トランスポートおよび格納プロトコル、デフォルトのメール・ユーザーを指定するjavax.mail.Sessionオブジェクトをアプリケーションでインスタンス化する必要があります。 WebLogic Remote Consoleを使用して、javax.mail.Sessionオブジェクトを構成し、WebLogic Server JNDI表に登録するメール・セッションを作成できます。 アプリケーションでは、独自のjavax.mail.Sessionオブジェクトをインスタンス化するかわりに、JNDIを通してメール・セッションにアクセスします。

1. 「編集ツリー」で、「サービス」、「メール・セッション」の順に移動します。

2. 「新規」をクリックします。

3. メール・セッションの「名前」および「JNDI名」を入力します。

   アプリケーションでは、JNDI名を使用してメール・セッションをルックアップします。 たとえば、JNDI名としてmyMailSessionと入力した場合、アプリケーションは次のルックアップを実行します:

   InitialContext ic = new InitialContext();
   Session session = (Session) ic.lookup("myMailSession");
   

4. 「作成」をクリックします。

5. 「セッション・ユーザー名」フィールドで、認証されたJavaMailセッションの作成に使用するユーザー・アカウントを指定します。 次に、「セッション・パスワード」フィールドに、ユーザー・アカウントのパスワードを入力します。

   ユーザー・アカウントを指定しない場合、セッションは認証されないとみなされます。

6. 「ターゲット」タブで、このメール・セッションのターゲットとするサーバーまたはクラスタを「選択済」に移動します。

   メール・セッションは、ターゲットとなるWebLogic ServerインスタンスのJNDI表にのみ登録されます。

   クラスタのすべてまたは一部をターゲット指定すると、WebLogic Remote Consoleによって2フェーズ・デプロイメントが開始されます。 一般に、このようなデプロイメントでは、1つのアクティブなサーバーのデプロイメントが失敗すると、すべてのアクティブなサーバーのデプロイメントが失敗します。

7. 「保存」をクリックします。

8. 既存のメール・サーバーに接続するための追加のプロパティを指定できます。

   ノート

   デフォルト値をオーバーライドする場合のみ、プロパティを指定します。 プロパティを指定しない場合、メール・セッションではJavaMailのデフォルト・プロパティ値が使用されます。

   1. 「Javaメールのプロパティ」タブの「Javaメールのプロパティ」表で、+をクリックして新しい行を追加します。

   2. 「プロパティ名」の下のセルをダブルクリックし、プロパティの名前を入力します。

   3. 「プロパティ値」の下のセルをダブルクリックし、プロパティの値を入力します。

   4. 「保存」をクリックします。

   「表3」は、JavaMail API設計仕様から導出された有効なプロパティおよびデフォルト値を示します。

表3./span> Javaメール・プロパティ JavaMail API設計仕様から導出された有効なプロパティおよびデフォルト値。

プロパティ	説明	デフォルト
mail.store.protocol	電子メールを取得するためのプロトコル。 たとえば、mail.store.protocol=imapです。	imap
mail.transport.protocol	電子メールを送信するためのプロトコル。 たとえば、mail.transport.protocol=smtp	smtp
mail.host	メール・ホスト・マシンの名前。 たとえば、mail.host=mailserverです。	ローカル・マシン
mail.user	電子メール取得用のデフォルト・ユーザーの名前。 たとえば、mail.user=postmasterです。	user.name Javaシステム・プロパティの値。
mail.protocol.host	特定のプロトコルのメール・ホスト。 mail.SMTP.hostおよびmail.IMAP.hostは、異なるマシン名に設定できます。 たとえば、mail.smtp.host=mail.mydom.com mail.imap.host=localhost	mail.hostプロパティの値。
mail.protocol.user	メール・サーバーへのロギング用の、プロトコル固有のデフォルト・ユーザー名。 たとえば、mail.smtp.user=weblogic mail.imap.user=appuserです。	mail.userプロパティの値。
mail.protocol.user	デフォルトの戻信用アドレス。 たとえば、mail.from=master@mydom.com	username@host
mail.debug	JavaMailのデバッグ出力を有効にするには、Trueに設定します。	False

ドメインJTAオプションの構成

WebLogic Serverでは、ドメイン内のすべてのサーバーに適用されるように、ドメイン・レベルでトランザクション処理に影響する多数のオプションを設定できます。

1. 「編集ツリー」で、「サービス」、JTAの順に移動します。

2. 使用可能なオプションのいずれかまたはすべてに新しい値を指定します。 「拡張フィールドの表示」をクリックして、すべてのオプションを表示します。

3. 「保存」をクリックします。

トランザクション統計の表示

トランザクションおよびトランザクション統計をモニターできます。

詳細は、「Oracle WebLogic Server用のJTAアプリケーションの開発」の「トランザクションのモニタリング」を参照してください。

1. 「モニタリング・ツリー」で、「サービス」、「トランザクション」、「JTAランタイム」の順に移動して、サーバーによって調整されたすべてのトランザクションの統計を確認します。

2. 1つのサーバーのトランザクション統計のみを表示する場合は、表内のサーバー行をクリックします。

3. 「JTAランタイム」の下の子ノードを展開して、トランザクションの詳細をトランザクション名またはリソース別、現在のトランザクションの詳細、またはサーバーによって実行されるトランザクション・リカバリの詳細別に表示することもできます。

現在のトランザクションの表示

選択したサーバーによって調整された進行中のトランザクションを表示できます。

1. 「モニタリング・ツリー」で、「環境」、「サーバー」の順に移動し、トランザクションを表示するサーバーを選択します。

2. サーバー・ノードで、「サービス」、「トランザクション」、「JTAランタイム」の順に移動します。

3. 「トランザクション」タブをクリックして、選択したサーバーの現在のトランザクションを表示します。

JTA通信のローカル・ドメイン・セキュリティの有効化

JTAのローカル・ドメイン・セキュリティは、セキュアな通信チャネル間でグローバル・トランザクションが発生するように、ドメイン内のサーバー間のトラストを確立します。

1. 「編集ツリー」で、「サービス」、JTAの順に移動します。

2. 「拡張コントロールの表示」をクリックします。

3. 「ローカル・ドメイン・セキュリティ有効」オプションをオンにします。

   パフォーマンスへの影響を減らすために、WebLogic Serverは認証済サブジェクトをキャッシュします。 環境のキャッシュ設定を変更する場合は、次の設定を変更します:

   • キャッシュを無効にするには、「ローカル・ドメインのセキュリティ・キャッシュ有効」をオフにします。
   • キャッシュがクリアされる頻度を変更するには、「ローカル・ドメイン・セキュリティ・キャッシュTTL」値を(秒単位で)更新します。

4. 「保存」をクリックし、変更をコミットします。

5. ローカル・ドメイン・セキュリティのユーザーを作成し、CrossDomainConnectorsグループに割り当てます。 「ユーザーの作成」を参照してください。

   このユーザーは、ドメイン内のサーバー間ですべてのJTA通信を実行する権限を持ちます。

6. ローカル・ドメイン・セキュリティ・ユーザーのローカル・ドメイン・セキュリティ資格証明マッピングを構成します。 デフォルトの資格証明マッピング・プロバイダを使用するか、独自の資格証明マッピング・プロバイダを構成する場合は、「資格証明マッピング・プロバイダの構成」を参照してください。

   1. 「セキュリティ・データ・ツリー」で、「レルム」、myRealm、「資格証明マッパー」、「リモート・リソース」の順に移動します。

   2. 「新規」をクリックします。

   3. 「クロスドメイン・プロトコルを使用」オプションをオンにします。

   4. 「リモート・ドメイン」フィールドに、「ローカル」ドメインの名前を入力します。

   5. 「リモート・ユーザー」フィールドに、ステップ5で構成したユーザーのユーザー名を入力します。 次に、「リモート・パスワード」フィールドにパスワードを入力します。

   6. 「作成」をクリックします。

ローカル・ドメイン・セキュリティがJTA通信に対して有効になりました。

JTAセキュリティ相互運用モードの指定

セキュリティの相互運用性(相互運用性)モードによって、サーバー間のJTA通信のセキュリティ対象が決まります。

1. 「編集ツリー」で、「サービス」、JTAの順に移動します。

2. 「拡張コントロールの表示」をクリックします。

3. 「セキュリティ相互運用モード」ドロップダウン・リストから、モードを選択します:

   • デフォルト: メッセージは、カーネル・アイデンティティもしを使用して転送され、管理者チャネルも構成されます。 それ以外の場合は、performanceモードのように動作します。 「ドメイン全体の管理ポートの構成」を参照してください。
   • パフォーマンス: メッセージは匿名ユーザーを使用して転送されます。

4. 「保存」をクリックします。