WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: AIX , HP-UX, i5/OS, Linux, Solaris, Windows, Windows Vista

             目次と検索結果のパーソナライズ化

プラグイン構成

プラグイン・インストール・ウィザードは、Web サーバー用のバイナリー・プラグイン・モジュールとプラグイン構成ファイルをインストールします。続いて、ウィザードは、 アプリケーション・サーバーのサポートされる Web サーバーを構成し、 アプリケーション・サーバーの構成に Web サーバー定義を作成します。 この概要では、ウィザードが使用するさまざまなプロセス・パスを示します。

このトピックは、プラグイン・インストール・ウィザードが、 プラグイン構成ファイルである plugin-cfg.xml ファイルを検索するように Web サーバーを構成する 3 つの方法について説明します。

Network Deployment 製品の構成フロー

プラグイン・インストール・ウィザードは、Web サーバーと WebSphere Application Server のすべての構成を、リモート・アプリケーション・サーバー、ローカル分散アプリケーション・サーバー、およびローカル・スタンドアロン・アプリケーション・サーバーの 3 つのシナリオに分けます。構成に適用されるシナリオを決定するときに実装されるロジックは、以下の図に示されています。


設計ロジックのプラグイン・フロー

凡例:
Web サーバー定義を使用したデフォルト・アプリケーション・サーバー?
デフォルト・プロファイルが既存の Web サーバー定義を持つアプリケーション・サーバーである場合、インストールは リモート・インストールとみなされます。スタンドアロン・アプリケーション・サーバーに複数の Web サーバー定義を持つことはできません。

既存の Web サーバー定義を使用するように新規 Web サーバーを構成するには、Web サーバーに対して同じ名前を使用します。

異なる Web サーバー名を使用して、統合されたアプリケーション・サーバー・プロファイルに新規 Web サーバー定義を作成するスクリプトを作成します。

デフォルト・プロファイル?
製品がインストールされているが、 プロファイル管理ツールがプロファイルを作成していない場合、 シナリオはリモート・インストールとみなされます。 複数のプロファイルが存在する場合は、 プラグイン・インストーラーはデフォルト・プロファイルのみを構成します。
デフォルトの profile_type?
プラグイン・インストール・ウィザードは、一度に 1 つのプロファイルのみを構成することができます。 このウィザードは、常にデフォルト・プロファイルで動作します。これらの 3 つのパスは、異なるタイプのプロファイルにより処理がどのように異なるかを示します。
統合?
アプリケーション・サーバー・ノードが統合されている場合、プラグイン・インストール・ウィザードは、管理対象ノードで Web サーバー定義を構成します。これには利点があります。Web サーバーと管理対象ノードが別のマシン上にあると仮定します。Web サーバー定義はノード構成の一部なので、 plugin-cfg.xml ファイルは、ノードを同期化するときに自動的にリモート・ノードに伝搬されます。
インストール・タイプ?
インストール・タイプはリモートまたはローカルです。
デフォルト以外の分散プロファイル?
デプロイメント・マネージャーが統合カスタム・ノード (カスタム・プロファイル) を持つ場合、プラグイン・インストール・ウィザードは、管理対象ノードで Web サーバー定義を構成します。これには利点があります。Web サーバーと管理対象ノードが別のマシン上にあると仮定します。Web サーバー定義はノード構成の一部なので、 plugin-cfg.xml ファイルは、ノードを同期化するときに自動的にリモート・ノードに伝搬されます。
統合されたカスタム・プロファイルが見つからない場合は、プラグイン・インストール・ウィザードは見つかった最初の統合されたアプリケーション・サーバー・ノード (アプリケーション・サーバー・プロファイル) を検索し、構成します。このため、ロジックは次のようになります。
  1. 統合された管理対象 (カスタム) プロファイルを検索し、見つかった最初のプロファイルを構成します。
  2. 統合された管理対象プロファイルが見つからない場合は、統合されたアプリケーション・サーバー・プロファイルを検索し、見つかった最初のプロファイルを構成します。

シナリオ 1. リモート・プラグイン構成

プラグイン・インストール・ウィザードは、リモート・マシンのデフォルトの分散プロファイル内に、Web サーバー定義を自動的に作成しません。その代わりに、 ウィザードは configureweb_server_name スクリプトを作成します。

プラグイン・インストール・ウィザードは、 Web サーバー・マシンの plugins_root/config/web_server_name ディレクトリーに維持される plugin-cfg.xml ファイルを使用するように Web サーバーを構成します。 このファイルは、定期的に伝搬する必要があります。伝搬する場合、 現在の plugin-cfg.xml ファイルをアプリケーション・サーバー・マシンからコピーして、 plugins_root/config/web_server_name/plugin-cfg.xml ファイルと置き換えます。

ローカル Web サーバー用のバイナリー・プラグインをインストールした後、アプリケーション・サーバーと Web サーバーを始動する前にスクリプトを実行する必要はありません。ただし、スクリプトを実行するまでは、アプリケーション・サーバー・ノードでの Web サーバー定義の利点は得ることができません。

リモート・アプリケーション・サーバーのシナリオには、4 つの構成が適しています。
プロファイル・タイプ 統合状況 Web サーバー定義の作成? Web サーバーがアプリケーション・サーバー構成にすでに定義されていますか?
プラグイン・インストール・ウィザードでリモート・インストール・タイプを選択する場合の任意の位置にある任意のプロファイル 該当なし スクリプトによる 該当なし
デフォルト・プロファイルは検出されませんでした 該当なし スクリプトによる 該当なし
既存の Web サーバー定義のある、デフォルトの統合されていないスタンドアロン・アプリケーション・サーバー・プロファイル 統合されていない スクリプトによる はい
管理対象ノードのないデフォルトのデプロイメント・マネージャー・プロファイル 該当なし スクリプトによる 該当なし

Web サーバー定義のないアプリケーション・サーバーのテスト: 以下の概説では、plugins_root/config/web_server_name/plugin-cfg.xml 一時ファイルを検証するための手順について説明します。

Web サーバーは、plugin-cfg.xml 一時ファイルを使用してリモート・アプリケーション・サーバーと通信します。

アプリケーション・サーバーが 9080 以外の HTTP トランスポート・ポート割り当てを持つ場合、テストは正常に行われません。次のセクションに進み、アプリケーション・サーバー上で Web サーバー定義を作成して、構成のテストを完了します。

  1. Web サーバーに対する適切な手順に従って、Web サーバーを始動します。
    たとえば、コマンド行から IBM HTTP Server を始動します。
    • [AIX] [HP-UX] [Linux] [Solaris] ./IHS_root/bin/apachectl start
    • [Windows] IHS_root¥bin¥apache
    • [i5/OS] ./IHS_root/bin/apachectl start
  2. リモート・マシンでアプリケーション・サーバーを始動します。
    ディレクトリー profile_root/bin に移動し、 startServer コマンドを実行します。
  3. ブラウザーで http://localhost:9080/snoop を参照して、 アプリケーション・サーバーによって提供される内部 HTTP トランスポートをテストします。 ブラウザーで http://Host_name_of_Web_server_machine/snoop を参照して、 Web サーバーのプラグインをテストします。
  4. 両方の Web アドレスで、「Snoop Servlet - Request/Client Information」ページが表示されることを検証します。
Web サーバー定義の構成によるインストールの完了: 以下の概説は、構成を完了するための手順について説明します。 アプリケーション・サーバー・ノードの構成に Web サーバー定義が存在するようになるまで、構成は完了しません。Web サーバー定義は、 有効なプラグイン構成ファイル plugin-cfg.xml の再生成における中心要素です。
  1. デプロイメント・マネージャーまたは管理対象ノードを構成している場合、デプロイメント・マネージャーを始動します。
  2. ある時点でノードを統合することを計画している場合は、ここでリモート・アプリケーション・サーバー・ノードまたはカスタム・ノードを統合します。ノードを統合するときに Web サーバー定義が既に存在する場合、この定義は失われます。
  3. アプリケーション・サーバーに、Web サーバー定義を作成します。管理対象ノードの場合、2 つのオプションがあります。管理対象ノードなしにデプロイメント・マネージャー・ノードに対してスクリプト・オプションを使用します。
    • デプロイメント・マネージャーの管理コンソールを使用して、管理対象ノードの Web サーバー定義を作成します。「サーバー」>「Web サーバー」>「新規作成」 とクリックし、新規 Web サーバー・エントリーの作成ウィザードを使用して、Web サーバー定義を作成します。
    • スクリプトを実行して、アプリケーション・サーバー・ノードの構成内で Web サーバー定義を手動で作成します。
      1. スクリプトを plugins_root/bin ディレクトリーから app_server_root/bin リモート・ディレクトリーにコピーします。
      2. コマンド・ウィンドウを開き、スクリプトを実行します。
        • [AIX] [HP-UX] [Linux] [Solaris] ./configureweb_server_name.sh
        • [Windows] configureweb_server_name.bat
        • [i5/OS] ./configureweb_server_name
      注: スクリプト内の webserverNodeName 値は、Web サーバー用に選択したニックネームとサフィックス -node を連結したものです。これは、プラグインのインストール中に自動作成され、変更することはできません。例えば、プラグインのインストール中、ご使用の Web サーバーに myserver という名前を付けた場合、スクリプトの実行後に作成される関連する Web サーバー定義の値は myserver-node になります。

      セキュリティーを使用可能にしたか、デフォルトの Java Management Extensions (JMX) コネクター・タイプを変更した場合は、スクリプトを編集し、適切なパラメーターを組み込みます。

  4. ノードが統合される場合は、デプロイメント・マネージャーの管理コンソールを開きます。管理対象ノードでノード同期が行われるまで待ち、新規の Web サーバー定義を含む変更された構成を保管します。 リモート・ノードが統合されない場合、アプリケーション・サーバーの管理コンソールを開き、変更された構成を保管します。
  5. profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name ディレクトリーの現在のプラグイン構成ファイル plugin-cfg.xml をコピーします。 Web サーバー・マシンでファイルを貼り付け、 一時ファイル plugins_root/config/web_server_name/plugin-cfg.xml と置き換えます。 IBM HTTP Server は自動伝搬をサポートします。その他の Web サーバーは、手動で伝搬を行う必要があります。
  6. Web サーバーに対する適切な手順に従って、Web サーバーを始動します。
  7. ブラウザーで http://localhost:9080/snoop を参照して、 アプリケーション・サーバーによって提供される内部 HTTP トランスポートをテストします。 ブラウザーで http://Host_name_of_Web_server_machine/snoop を参照して、 Web サーバーのプラグインをテストします。
  8. 両方の Web アドレスで、「Snoop Servlet - Request/Client Information」ページが表示されることを検証します。

シナリオ 2. ローカル分散プラグイン構成

プラグイン・インストール・ウィザードは、統合されたアプリケーション・サーバー・プロファイル内に、Web サーバー定義を自動的に作成しません。その代わりに、 ウィザードは plugins_root/bin ディレクトリーに configureweb_server_name スクリプトを作成します。

プラグイン・インストール・ウィザードは、 スクリプトを実行するときにアプリケーション・サーバー・プロファイル内に作成される plugin-cfg.xml ファイルを使用するように Web サーバーを構成します。 デプロイメント・マネージャーは、plugin-cfg.xml ファイルを profile_root/config/cells/cell_name/nodes/node_name/servers/web_server_name ディレクトリーに再生成します。 管理対象ノード上のデプロイされたアプリケーションに影響するアプリケーション・サーバー構成で変更が行われるたびに、再生成が行われます。

ローカル Web サーバー用のバイナリー・プラグインをインストールした後、Web サーバーを始動する前にスクリプトを実行する必要があります。Web サーバーは、 アプリケーション・サーバー構成の plugin-cfg.xml ファイルを使用するようにすでに構成されています。 そのファイルは、configureweb_server_name スクリプトを実行するまで存在しません。

ローカル分散アプリケーション・サーバーのシナリオには、4 つの構成が適しています。
プロファイル・タイプ 統合状況 Web サーバー定義の作成? Web サーバーがアプリケーション・サーバー構成にすでに定義されていますか?
デフォルト・アプリケーション・サーバー・プロファイル 統合 スクリプトによる 該当なし
デフォルトのカスタム・プロファイル 統合されていない スクリプトによる 該当なし
デフォルトのカスタム・プロファイル 統合 スクリプトによる 該当なし
管理対象ノードのあるデフォルトのデプロイメント・マネージャー・プロファイル (デフォルト以外の分散プロファイル) 該当なし スクリプトによる 該当なし

以下の概説では、構成を完了し、Web サーバー構成を検証するための手順について説明します。

  1. デプロイメント・マネージャーを開始します。
  2. アプリケーション・サーバー・ノードのデプロイメント・マネージャー・セルへの追加を計画していて、 まだ実行していない場合は、プラグインをインストールする前にノードを統合します。 ノードを統合するときに Web サーバー定義が既に存在する場合は、統合するときに Web サーバー定義が失われます。
  3. アプリケーション・サーバーに、Web サーバー定義を作成します。以下の 2 つのオプションがあります。
    • デプロイメント・マネージャーの管理コンソールを使用して、管理対象ノードの Web サーバー定義を作成します。「サーバー」>「Web サーバー」>「新規作成」 とクリックし、 新規 Web サーバー・エントリーの作成ウィザードを使用して、Web サーバー定義を作成します。
    • スクリプトを実行して、デプロイメント・マネージャーの構成内で Web サーバー定義を手動で作成します。plugins_root/bin ディレクトリーからスクリプトを実行します。 スクリプトは、同じマシン上のデプロイメント・マネージャーにアドレス指定することができます。
      コマンド・ウィンドウを開き、適切なスクリプトを実行します。
      • [AIX] [HP-UX] [Linux] [Solaris] ./configureweb_server_name.sh
      • [Windows] configureweb_server_name.bat
      • [i5/OS] ./configureweb_server_name
      注: スクリプト内の webserverNodeName 値は、 Web サーバー用に選択したニックネームとサフィックス -node を連結したものです。これは、プラグインのインストール中に自動作成され、変更することはできません。例えば、プラグインのインストール中、ご使用の Web サーバーに myserver という名前を付けた場合、スクリプトの実行後に作成される関連する Web サーバー定義の値は myserver-node になります。

      セキュリティーを使用可能にした場合、またはデフォルトの JMX コネクター・タイプを変更した場合は、 そのスクリプトを編集し、適切なパラメーターを組み込みます。

  4. Web サーバーに対する適切な手順に従って、Web サーバーを始動します。
    たとえば、コマンド行から IBM HTTP Server を始動します。
    • [AIX] [HP-UX] [Linux] [Solaris] ./IHS_root/bin/apachectl start
    • [Windows] IHS_root¥bin¥apache
    • [i5/OS] ./IHS_root/bin/apachectl start
  5. アプリケーション・サーバーを始動します。
    ディレクトリー profile_root/bin に移動し、 startServer コマンドを実行します。
  6. デプロイメント・マネージャーの管理コンソールを開きます。 ノード同期が行われるまで待ち、新規の Web サーバー定義を含む変更された構成を保管します。
  7. ブラウザーで http://localhost:9080/snoop を参照して、 アプリケーション・サーバーによって提供される内部 HTTP トランスポートをテストします。 ブラウザーで http://Host_name_of_Web_server_machine/snoop を参照して、 Web サーバーのプラグインをテストします。
  8. 両方の Web アドレスで、「Snoop Servlet - Request/Client Information」ページが表示されることを検証します。

シナリオ 3. ローカル・スタンドアロン・プラグイン構成

プラグイン・インストール・ウィザードは、アプリケーション・サーバー・プロファイル内で Web サーバー定義を作成します。

プラグイン・インストール・ウィザードは、 アプリケーション・サーバー・プロファイル内にある plugin-cfg.xml ファイルを使用するように Web サーバーを構成します。 デプロイされたアプリケーションに影響するアプリケーション・サーバー構成で変更が行われるたびに、 スタンドアロン・アプリケーション・サーバーは、 profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name/plugin-cfg.xml ファイルを再生成します。

ローカル Web サーバー用のバイナリー・プラグインをインストールした後、インストール直後にアプリケーション・サーバーと Web サーバーを始動することができます。

スタンドアロン・アプリケーション・サーバーで Web サーバー定義を作成してから、ノードを統合すると仮定します。Web サーバー定義がスタンドアロン・アプリケーション・サーバーの別のノードとして定義されるため、Web サーバー定義はセルに統合されません。管理対象ノードで、Web サーバー定義を再作成する必要があります。シナリオ 2 を参照してください。

ローカル・スタンドアロン・アプリケーション・サーバーのシナリオには、1 つの構成のみが適しています。
プロファイル・タイプ 統合状況 Web サーバー定義の自動作成? Web サーバーがアプリケーション・サーバー構成にすでに定義されていますか?
アプリケーション・サーバー 統合されていない はい いいえ

シナリオ 1 へのリダイレクト

既存の Web サーバー定義を持つ統合されていないデフォルトのスタンドアロン・アプリケーション・サーバーは、リモート・プラグイン構成として処理されます。

スタンドアロン・アプリケーション・サーバーに Web サーバー定義が既に存在しているため、プラグイン・インストール・ウィザードは、リモート・インストール・パスに従います。1 つのスタンドアロン・アプリケーション・サーバーは 1 つの Web サーバー定義のみを持つことができます。新規 Web サーバーを構成する場合は、Web サーバーに対して同じニックネームを指定します。

アプリケーション・サーバーの構成の Web サーバー定義内にある plugin-cfg.xml ファイルを使用することができます。 プラグイン・インストール・ウィザードの該当パネルの「参照」を単にクリックして、ファイ ルを選択します。 このファイルが存在している必要があります。存在しない場合、プラグイン・インストール・ウィザードは警告を表示し、既存のファイルを選択するまで先に進むことができません。 Web サーバーは、この既存の plugin-cfg.xml ファイルを使用するように構成されます。

このタイプのノードの説明については、シナリオ 1 を参照してください。

シナリオ 2 へのリダイレクト

統合されたデフォルトのスタンドアロンのアプリケーション・サーバーは、ローカル分散プラグイン構成として処理されます。このタイプのノードの説明については、シナリオ 2 を参照してください。

検証手順の概説

以下の概説では、バイナリー・プラグイン・モジュールをインストールした後、Web サーバー構成を検証するための手順について説明します。

  1. Web サーバーに対する適切な手順に従って、Web サーバーを始動します。
    たとえば、コマンド行から IBM HTTP Server を始動します。
    • [AIX] [HP-UX] [Linux] [Solaris] ./IHS_root/bin/apachectl start
    • [Windows] IHS_root¥bin¥apache
    • [i5/OS] ./IHS_root/bin/apachectl start
  2. アプリケーション・サーバーを始動します。
    ディレクトリー profile_root/bin に移動し、 startServer コマンドを実行します。 管理コンソールを開き、 変更済みの構成を保管します。
  3. ブラウザーで http://localhost:9080/snoop を参照して、 アプリケーション・サーバーによって提供される内部 HTTP トランスポートをテストします。 ブラウザーで http://Host_name_of_Web_server_machine/snoop を参照して、 Web サーバーのプラグインをテストします。
  4. 両方の Web アドレスで、「Snoop Servlet - Request/Client Information」ページが表示されることを検証します。

要約

WebSphere Application Server の Web サーバー・プラグインに対して、3 つのシナリオがあります。各シナリオは、 プラグイン構成ファイル plugin-cfg.xml の固有のロケーションを中心に展開されています。アプリケーション・サーバーは、プラグイン構成ファイルを生成します。 ファイルの目的は、Web サーバーと関連するすべてのアプリケーション・サーバー・エレメントのロケーションを公開することです。このようなエレメントには、アプリケーション、アプリケーションを提供する仮想ホスト、クラスター、およびクラスター・メンバーなどが含まれます。

Web サーバーがアプリケーション・サーバー・マシン上のファイルにアクセスできない場合には、そのファイルを Web サーバーにコピーする必要があります。そのプロセスは、伝搬と呼ばれます。伝搬は、リモート・プラグイン構成シナリオ (このトピックのシナリオ 1) のために予約済みです。

それぞれのローカル・シナリオでは、 Web サーバーは、plugin-cfg.xml ファイルと同じマシン上にあるため、このファイルにアクセスすることができます。 ローカルの plugin-cfg.xml ファイルには 2 つの異なるロケーションがあるため、2 つのローカル・シナリオがあります。

バージョン 6 の WebSphere Application Server の構成スキームでは、Web サーバー・ノードまたは管理対象ノードにある Web サーバー定義に、プラグイン構成ファイルが収められます。ノードのタイプが、このトピックのシナリオ 2 とシナリオ 3 における差異です。すべてのシナリオ 2 構成では、Web サーバー定義が管理対象のアプリケーション・サーバー・ノード内にある必要があります。すべてのシナリオ 3 構成では、それ自身の Web サーバー・ノード内に Web サーバー定義があります。

限定管理オプションでは、スタンドアロン・アプリケーション・サーバーの管理コンソールに 1 つの Web サーバー定義を作成したり、削除することができません。スタンドアロン・アプリケーション・サーバーは Web サーバー定義を作成できないため、 WebSphere Application Server 向けの Web サーバー・プラグインにより構成スクリプトが作成されます。 スクリプトを使用しない場合には、スタンドアロン・アプリケーション・サーバー・ノード上で Web サーバー定義を簡単に作成することができません。

このトピックに説明されている各構成の plugin-cfg.xml ファイルのロケーションは、 以下の表に示されています。
表 1. プラグイン構成ファイルのロケーション
シナリオ プロファイル・タイプ plugin-cfg.xml ファイルのロケーション
Plugins_ install_ root profiles_ root: 管理対象ノード内 profiles_ root: Web サーバー・ノード内
1 プラグイン・インストール・ウィザードでリモート・インストール・タイプを選択する場合の任意の位置にある任意のプロファイル X    
デフォルト・プロファイルは検出されませんでした X    
既存の Web サーバー定義のあるデフォルトの統合されていない (スタンドアロン) アプリケーション・サーバー・プロファイル X    
管理対象ノードのないデフォルトのデプロイメント・マネージャー・プロファイル X    
2 デフォルト・アプリケーション・サーバー・プロファイル   X  
デフォルトのカスタム・プロファイル   X  
管理対象ノードのあるデフォルトのデプロイメント・マネージャー・プロファイル (デフォルト以外の分散プロファイル)   X  
3 デフォルト・アプリケーション・サーバー・プロファイル     X
凡例:
plugins_root
plugins_root
/config/
web_server_name/plugin-cfg.xml
profiles_ root: 管理対象ノード内
profile_root
/config/cells/cell_name/nodes/
node_name_of_AppServer/servers/
web_server_name/plugin-cfg.xml
profiles_ root: Web サーバー・ノード内
profile_root
/config/cells/cell_name/nodes/
web_server_name_node/servers/
web_server_name/plugin-cfg.xml



関連概念
Web サーバーの構成
関連タスク
[AIX HP-UX Linux Solaris Windows] Web サーバー・プラグインのインストール [i5/OS] i5/OS での Web サーバー・プラグインのインストール
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/cins_webplugins.html