Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方

11g リリース1(10.3.5)

B61008-03(原本部品番号:E14395-05)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- このリリースでの新機能と変更点

2 Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方

- プラグインとは

- Oracle WebLogic Server付属のプラグイン

- プラグイン・バージョン

- Oracle HTTP Serverプラグインのサポート

- プラグイン双方向SSLサポート

- WebLogic ServerにおけるWebLogicプラグイン有効化制御の設定

3 Apache HTTP Serverプラグインのインストールと構成

- Apache HTTP Serverプラグインの概要

- Apacheバージョン2.0でのキープアライブ接続

- リクエストのプロキシ

- Apache 2.2

- 動作確認

- Apache HTTP Serverプラグインのインストール

- Apache HTTP Serverプラグインの動的共有オブジェクトとしてのインストール

- Apache 2.0におけるサイズの大きなファイルのサポート

- Apache HTTP Serverプラグインの構成

- httpd.confファイルの編集

- WebLogicプロパティをLocationまたはVirtualHostブロック内に置く

- httpd.confファイルへのweblogic.confファイルのインクルード

- weblogic.confファイルの作成

- weblogic.conf構成ファイルのサンプル

- Apache HTTP Server httpd.confファイルのテンプレート

- 境界認証の設定

- ApacheプラグインでのSSLの使用

- Apache HTTP ServerプラグインとWebLogic Server間のSSLの構成

- SSL-Apache構成に関する問題

- 接続エラーとクラスタリング・フェイルオーバー

- 接続失敗の考えられる原因

- Connection_Refusedエラーを減らすためのチューニング

- クラスタリングされていない単一のWebLogic Serverでのフェイルオーバー

- 動的サーバー・リスト

- フェイルオーバー、CookieおよびHTTPセッション

4 Microsoft IISプラグインのインストールと構成

- Microsoft Internet Information Serverプラグインの概要

- 接続プールとキープアライブ

- リクエストのプロキシ

- 動作確認

- ワイルドカード・アプリケーション・マッピングを使用したパスによるプロキシ

- ワイルドカード・アプリケーション・マッピングのインストール(IIS 6.0)

- IIS 7.0用のワイルドカード・スクリプト・マップの追加

- Microsoft Internet Information Serverプラグインのインストールと構成

- Microsoft Internet Information Server IIs 7.0プラグインのインストールと構成

- 複数の仮想WebサイトからのWebLogic Serverへのリクエストのプロキシ

- iisproxy.iniファイルのサンプル

- IISを経由するACLの作成

- 境界認証の設定

- Microsoft Internet Information ServerプラグインでのSSLの使用

- IISからWebLogic Serverへのサーブレットのプロキシ

- インストールのテスト

- 接続エラーとクラスタリング・フェイルオーバー

- 接続失敗の考えられる原因

- クラスタリングされていない単一のWebLogic Serverでのフェイルオーバー

- 動的サーバー・リスト

- フェイルオーバー、CookieおよびHTTPセッション

5 Sun Java System Web Serverプラグインのインストールと構成

- Sun Java System Web Serverプラグインの概要

- 接続プールとキープアライブ

- リクエストのプロキシ

- Sun Java System Web Serverプラグインのインストールと構成

- obj.confファイル修正のガイドライン

- obj.confファイルのサンプル(WebLogicクラスタを使用しない場合)

- obj.confファイルのサンプル(WebLogicクラスタを使用する場合)

- 境界認証の設定

- Sun Java System Web ServerプラグインでのSSLの使用

- 接続エラーとクラスタリング・フェイルオーバー

- 接続失敗の考えられる原因

- クラスタリングされていない単一のWebLogic Serverでのフェイルオーバー

- 動的サーバー・リスト

- フェイルオーバー、CookieおよびHTTPセッション

- ファイアウォールとロード・ディレクタを使用する場合のフェイルオーバーの動作

6 別のWebサーバーへのリクエストのプロキシ

- 別のWebサーバーへのリクエストのプロキシの概要

- セカンダリWebサーバーへのプロキシの設定

- プロキシ・サーブレットのデプロイメント記述子のサンプル

7 Webサーバー・プラグインのパラメータ

- Webサーバー・プラグインの構成ファイルでのパラメータの入力

- Webサーバー・プラグインの一般的なパラメータ

- POSTデータ・ファイルの場所

- Webサーバー・プラグインのSSLパラメータ

Oracle® Fusion Middleware

Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方

11g リリース1(10.3.5)

B61008-03(原本部品番号:E14395-05)

2011年4月

このドキュメントでは、サード・パーティ製管理サーバーへのリクエストをプロキシするためのプラグインの使用について説明します。このドキュメントは、WebLogic Serverアプリケーション・プラットフォームおよびそのサブシステムを管理するシステム管理者を主な対象としています。

Oracle Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方, 11g リリース1(10.3.5)

B61008-03

Copyright © 2007, 2011, Oracle and/or its affiliates.All rights reserved.

原本著者: Oracle Corporation

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、Oracleまでご連絡ください。

このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアを危険が伴うアプリケーションで使用する際、このソフトウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

はじめに

ここでは、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方』で使用されるドキュメントのアクセシビリティ機能と表記規則について説明します。

ドキュメントのアクセシビリティについて

オラクル社は、障害のあるお客様を含めたすべてのお客様に、オラクル社の製品、サービスおよびサポート・ドキュメントをご利用いただけることを目標としています。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じカッコだけを行に記述する必要があります。しかし一部のスクリーン・リーダーはカッコだけの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細については、http://www.oracle.com/support/contact.htmlにアクセスしてください。障害のあるお客様は、http://www.oracle.com/accessibility/support.htmlにアクセスしてください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この項では、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方』の内容と構成について説明します。

ドキュメントのスコープと対象読者

このドキュメントでは、サード・パーティ管理サーバーへのリクエストのプロキシ送信のために提供されるプラグインの使用について説明します。このドキュメントは、Oracle WebLogic Serverアプリケーションおよびその複数のサブシステムを管理するシステム管理者を対象にしています。

このドキュメントの手引き

この章では、このガイドの構成について説明します。このガイドは次のように構成されています。

- 第2章「Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方」では、WebLogic Serverで使用するためにOracleが提供するプラグインについて説明します。

- 第3章「Apache HTTP Serverプラグインのインストールと構成」では、Apache HTTP Serverプラグインのインストール方法および構成方法について説明します。

- 第4章「Microsoft IISプラグインのインストールと構成」では、Microsoft Internet Information Serverプラグインをインストールおよび構成する方法について説明します。

- 第5章「Sun Java System Web Serverプラグインのインストールと構成」では、Sun Java System Web Serverプロキシ・プラグインをインストールおよび構成する方法について説明します。

- 第6章「別のWebサーバーへのリクエストのプロキシ」では、別のWebサーバーにHTTPリクエストをプロキシする方法について説明します。
第7章「Webサーバー・プラグインのパラメータ」では、ApacheおよびMicrosoft IISのWebサーバー・プラグインを構成するために使用するパラメータについて説明します。

関連ドキュメント

このドキュメントでは、Webサーバー・プラグインの使用方法について説明します。プロキシ・プラグインの使用方法は、『Oracle WebLogic Serverクラスタの使い方』を参照してください。

このリリースでの新機能と変更点

このリリースで導入されたOracle WebLogic Serverの総合的な新機能リストは、「Oracle WebLogic Serverの新機能」を参照してください。

2 Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方

次の項では、WebLogic Serverで使用するためにOracleが提供するプラグインについて説明します。

- プラグインとは

- Oracle WebLogic Server付属のプラグイン

- プラグイン・バージョン

- Oracle HTTP Serverプラグインのサポート

- プラグイン双方向SSLサポート

- WebLogic ServerにおけるWebLogicプラグイン有効化制御の設定

プラグインとは

プラグインは、WebLogic Server実装を拡張するために使用する小さなソフトウェア・プログラムです。プラグインを使用すると、Oracle HTTP Server、Apache HTTP Server、Sun Java System Web ServerまたはMicrosoft Internet Information Server上にデプロイされているアプリケーションとWebLogic Server間の通信が実現できます。通常は、動的な機能を必要とするアプリケーション・リクエスト(動的なHTMLページやJSP(Java Server Page)で処理するのが最適なリクエスト)がWebLogic Serverで処理されます。

Oracle WebLogic Server付属のプラグイン

WebLogic Serverには、次のWebサーバー用のプラグインがあります。

- Apache HTTP Server

- Microsoft Internet Information Server

- Sun Java System Web Server

プラグイン・バージョン

『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方』では、次のプラグインについて説明します。

- Apache HTTP Server、バージョン1.0.1211636

- Microsoft Internet Information Server、バージョン1.0.1211636

- Sun Java System Web Server、バージョン1.0.1211636

Oracle HTTP Serverプラグインのサポート

プラグイン・サポートは、Oracle HTTP Serverにも使用可能です。これらのプラグインはOracle HTTP Serverの配布にパッケージされています。『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

プラグイン双方向SSLサポート

WebLogic Serverプラグインでは双方向SSLはサポートされていません。ただし、クライアント証明書をリクエストしてそれをWebLogic Serverに渡すように、プラグインを設定することはできます。例:

apache ssl
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire

WebLogic ServerにおけるWebLogicプラグイン有効化制御の設定

WebLogic ServerでWebLogicプラグインの有効化制御を設定します。

WebLogicプラグインの有効化制御は、WebLogic Serverが独自のWL-Proxy-Client-IPヘッダーを使用するかどうかを指定します。これは、サーバー・インスタンスがプロキシ・プラグインからリクエストを受信する場合にお薦めできます。

3 Apache HTTP Serverプラグインのインストールと構成

次の項では、Apache HTTP Serverプラグインをインストールして構成する方法を説明します。

- Apache HTTP Serverプラグインの概要

- Apache HTTP Serverプラグインのインストール

- Apache HTTP Serverプラグインの構成

- 境界認証の設定

- ApacheプラグインでのSSLの使用

- 接続エラーとクラスタリング・フェイルオーバー

Apache HTTP Serverプラグインの概要

Apache HTTP Serverプラグインを使用すると、Apache HTTP ServerからWebLogic Serverにリクエストをプロキシできます。このプラグインは、WebLogic Serverの動的な機能を必要とするリクエストをWebLogic Serverが処理できるようにすることによってApacheを拡張します。

このプラグインは、Apacheサーバーが静的ページを提供している環境で使用されることを想定しています。ドキュメント・ツリーの他の部分(HTTPサーブレットやJavaServer Pagesによって最も適切な状態で生成される動的ページ)は、(おそらくは別のホストの)別のプロセスで動作しているWebLogic Serverに委任されます。それでも、エンド・ユーザー(ブラウザ)には、WebLogic Serverに委任されるHTTPリクエストは同じソースから送られているものと認識されます。

HTTPトンネリング(企業のファイアウォールを経由したHTTPリクエストおよびレスポンスのアクセスを可能にする技術)もこのプラグインを介して動作するため、非ブラウザ・クライアントにWebLogic Serverサービスへのアクセスを提供できます。

Apache HTTP Serverプラグインは、Apache HTTP Server内でApacheモジュールとして機能します。Apacheモジュールは起動時にApacheサーバーによってロードされ、その後特定のHTTPリクエストがモジュールに委任されます。Apacheモジュールは、HTTPサーブレットと似ていますが、プラットフォームにネイティブなコードで記述されている点で異なります。

Apache HTTP Serverプラグインがサポートされる構成の詳細は、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlを参照してください。

注意:
Apache 2.0プラグインは、WebLogic Server 10.0のリリースで非推奨になりました。

Apacheバージョン2.0でのキープアライブ接続

Apache HTTP Serverプラグインのバージョン2.0は、WebLogic Serverとの接続の再利用可能なプールを使用してパフォーマンスを向上させます。このプラグインは、同じクライアントからの後続リクエストにプール内の同じ接続を再利用することで、WebLogic Serverとの間でHTTP 1.1キープアライブ接続を実装します。接続が20秒(またはユーザー定義の時間)を超えて非アクティブな場合、その接続は閉じられてプールから削除されます。この機能は、必要に応じて無効にできます。詳細は、表7-1の「KeepAliveEnabled」を参照してください。

リクエストのプロキシ

プラグインは、ユーザーが指定する構成に基づいてリクエストをWebLogic Serverにプロキシします。リクエストは、リクエストのURL(またはURLの一部)に基づいてプロキシできます。これを、パスによるプロキシと呼びます。リクエスト対象のファイルのMIMEタイプに基づいてリクエストをプロキシすることもできます。または、これらの2つの方法を組み合せて使用することも可能です。リクエストが両方の基準に一致する場合、そのリクエストはパスによってプロキシされます。リクエストの種類ごとに、プラグインの追加の動作を定義する追加パラメータを指定することもできます。詳細は、「Apache HTTP Serverプラグインの構成」を参照してください。

Apache 2.2

このドキュメントではApache 2.0について言及していますが、同じ手順を適用して、表3-2に示すライブラリでApache 2.2を使用することができます。

動作保証

Apache HTTP Serverプラグインは、Linux、Solaris、Windows、およびHPUX11の各プラットフォームでサポートされています。Apacheの特定のバージョンのサポートについては、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlを参照してください。

Apache HTTP Serverプラグインのインストール

Apache HTTP Serverプラグインには、WL_HOME/server/pluginディレクトリの下にWebLogic Serverが含まれます。

Apache HTTP Serverプラグインは、インストールされているApache HTTP ServerのApacheモジュールとしてインストールし、動的共有オブジェクト(DSO)としてリンクできます。

DSOは、実行時にサーバーに動的にロードされるライブラリとしてコンパイルされるので、Apacheを再コンパイルしなくてもインストールできます。

Apache HTTP Serverプラグインの動的共有オブジェクトとしてのインストール

Apacheプラグインは、Solaris、Linux、AIX、Windows、およびHPUX11プラットフォーム用の共有オブジェクト(.so)として配布されます。

注意:
WebLogic Serverバージョン10.3インストールにはApache HTTP Serverプラグインは含まれていません。Apache HTTP Serverプラグインは、Oracleダウンロードおよびサポート・サイトから、別個のzipファイルで入手できます。これらのプラグインには、次の場所に記述されているセキュリティ・アドバイザリに対応する修正が含まれています。
http://www.oracle.com/technology/deploy/security/alerts/alert_cve2008-3257.html

zipファイルをダウンロードしたら、ディスク上の任意のディレクトリに展開します。

表3-1は、各種プラットフォームの共有オブジェクト・ファイルを格納するディレクトリを示します。

表3-2には、各バージョンのApache HTTP Serverと暗号化強度に対応するWebLogic Server Apacheプラグイン・モジュールを示します。

表3-1 プラグインの共有オブジェクト・ファイルの場所

オペレーティング・システム

WL_HOME/server/pluginの下の共有オブジェクトの場所

AIX

aix/ppc

Solaris

solaris/sparc

solaris/sparc/largefile脚注 1

solaris/x86

solaris/x86/largefile脚注 2

Linux

linux/i686

linux/i686/largefile脚注 3

linux/ia64

linux/x86_64

Windows (Apache 2.0および2.2 (32ビット))

win\32

HPUX11

hpux11/IPF64

hpux11/PA_RISC

注意: HP-UX11上でApache 2.0.xサーバーを実行している場合、Apacheサーバーをビルドする前に次の環境変数を設定します。ビルド前に環境変数としてロード順序を事前に設定しておかないと、HP-UX上でリンク・ライブラリがロードされる順番に関する問題のため、コア・ダンプが生成される場合があります。Apacheの構成、作成、およびインストール手順(http://httpd.apache.org/docs-2.1/install.html#configureにあるApache HTTP Serverのドキュメントを参照)の前に、次の環境変数を設定します。

export EXTRA_LDFLAGS="-lstd -lstream -lCsup -lm -lcl -ldld -lpthread"

脚注 1 「Apache 2.0におけるサイズの大きなファイルのサポート」を参照

脚注 2  「Apache 2.0におけるサイズの大きなファイルのサポート」を参照

脚注 3  「Apache 2.0におけるサイズの大きなファイルのサポート」を参照

次の表から適切なバージョンのプラグイン共有オブジェクトを選択します。

表3-2 Apacheプラグイン共有オブジェクト・ファイルのバージョン

Apacheのバージョン

通常強度の暗号化

128ビットの暗号化

標準のApacheバージョン2.0.x

mod_wl_20.so

mod_wl128_20.so

標準のApacheバージョン2.2.x

mod_wl_22.so

mod_wl128_22.so

Apache HTTP Serverプラグインを動的共有オブジェクトとしてインストールするには:

1. 表3-1を参照して、プラットフォームの共有オブジェクトのディレクトリを検索します。

注意:
ディレクトリの選択を行う前に、「Apache 2.0におけるサイズの大きなファイルのサポート」を参照してください。

2. 表3-2で、使用するバージョンのApacheに対応したプラグイン共有オブジェクト・ファイルを確認します。

3. WebLogic Server Apache HTTP Serverプラグインの mod_so.c モジュールが有効になっていることを確認します。
Apache HTTP Serverプラグインは、動的共有オブジェクト(DSO)としてApache HTTP Serverにインストールされます。ApacheのDSOサポートは、mod_wl_20.soをロードする前に有効にする必要のあるmod_so.cというモジュールに基づいています。Apacheで提供されるスクリプトを使用してApache HTTP Serverをインストールした場合、mod_so.cはすでに有効になっています。次のコマンドを実行して、mod_so.cが有効であることを確認します。

APACHE_HOME\bin\apachectl -l

(APACHE_HOMEは、Apache HTTP Serverをインストールしたディレクトリです。)

このコマンドでは、有効なすべてのモジュールのリストが表示されます。mod_so.cがリストにない場合は、次のオプションが構成されるように、Apache HTTP Serverを再構築する必要があります。

...
--enable-module=so
--enable-rule=SHARED_CORE
...

http://httpd.apache.org/docs/2.0/dso.htmlのApache 2.0共有オブジェクト(DSO)のサポートを参照してください。

4. Apache 2.0.xのApache HTTP Serverプラグイン・モジュールをインストールするには、mod_wl_20.soファイルをAPACHE_HOME\modulesディレクトリにコピーし、APACHE_HOME conf/httpd.confファイルに次の行を手作業で追加します。

LoadModule weblogic_module     modules/mod_wl_20.so

5. Apache HTTP Serverプラグインの追加パラメータを定義します。
Apache HTTP Serverプラグインは、「Webサーバー・プラグインの一般的なパラメータ」にリストされているパラメータを認識します。Apache HTTP Serverプラグインの動作を修正するには、次のパラメータを定義します。

- Locationブロック(パスによるプロキシに適用されるパラメータの場合)、または

- IfModuleブロック(MIMEタイプによるプロキシに適用されるパラメータの場合)。

6. 次のコマンドで、APACHE_HOME\conf\httpd.confファイルの構文を検証します。

APACHE_HOME\bin\apachectl -t

このコマンドの出力では、httpd.confファイルのエラーが示されるか、次が戻されます。

Syntax OK

7. Weblogic Serverを再起動します。

8. Apache HTTP Serverを起動(構成を変更した場合は再起動)します。

9. プラグインをテストするには、ブラウザを開いて、URLにApacheサーバーのURLに加えて「/weblogic/」を設定します。このURLは、WebLogicサーバー上のデフォルトWebアプリケーションに定義されたデフォルトのWebLogic Server HTMLページ、welcomeファイル、またはデフォルト・サーブレットを表示する必要があります。例:

http://myApacheserver.com/weblogic/

Apache 2.0におけるサイズの大きなファイルのサポート

SolarisやLinuxの一部のバージョンなど、オペレーティング・システムによっては、付属のApache 2.0が次のフラグを指定してコンパイルされている場合があります。

-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64

これらのコンパイル・フラグにより、2GB以上のファイルのサポートが可能になります。このようなApache 2.0 Webサーバー上でWebLogic Webサーバー・プラグインを使用する場合は、同じコンパイル・フラグを指定してコンパイルされたプラグインを使用する必要があります。このようなプラグインは、使用しているオペレーティング・システムのlargefileサブディレクトリにあります。例:

C:\WL_HOME\server\plugin\solaris\sparc\largefile

注意:
Apache 2.2では、2GB以上のサイズのファイルをサポートするのに特別なコンパイル・フラグは必要ありません。したがって、Apache 2.2を実行している場合は、特別にコンパイルされたWebサーバー・プラグインを使う必要はありません。

Apache HTTP Serverプラグインの構成

Apache HTTP Serverにプラグインをインストールしたら、WebLogic Server Apacheプラグインの構成と、プラグインを使用するためのサーバーの構成を行います。この項では、Apacheのhttpd.confファイルを編集して、プラグイン用のWebLogic ServerライブラリをApacheモジュールとしてロードするようにApacheサーバーに通知し、そのモジュールで処理するアプリケーション・リクエストを指定する方法を説明します。

httpd.confファイルの編集

Apache HTTP Serverインストールのhttpd.confファイルを編集し、Apache HTTP Serverプラグインを構成します。

この項では、httpd.confファイルの検索と編集、WebLogic Server Apacheプラグインを使用するためのサーバーの構成、パスまたはMIMEタイプによるリクエストのプロキシ、HTTPトンネリングの有効化、その他のWebLogic Serverプラグインのパラメータを使用する方法について説明します。

1. httpd.confファイルを開きます。
このファイルは、APACHE_HOME\conf\httpd.conf (APACHE_HOMEはApache HTTP Serverをインストールした場所のルート・ディレクトリ)にあります。「境界認証の設定」のサンプルのhttpd.confファイルを参照してください。

2. Apache 2.0.xのWebLogic Serverモジュールが含まれていることを確認し、httpd.confファイルに次の行を手動で追加します。

LoadModule weblogic_module   modules\mod_wl_20.so

3. 次のいずれかを定義するIfModuleブロックを追加します。

- クラスタリングされていないWebLogic Serverの場合: WebLogicHostおよびWebLogicPortパラメータ

- WebLogic Serverのクラスタの場合: WebLogicClusterパラメータ

例:

<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7001
</IfModule>

4. MIMEタイプによってリクエストをプロキシするには、MatchExpression行をIfModuleブロックに追加します。MIMEタイプおよびパスによるプロキシの両方を有効にした場合、パスによるプロキシがMIMEタイプによるプロキシに優先することに注意してください。
たとえば、クラスタリングされていないWebLogic Serverに対する次のIfModuleブロックでは、MIMEタイプが.jspであるすべてのファイルがプロキシされます。

<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7001
MatchExpression *.jsp
</IfModule>

次のように、複数のMatchExpressionsを使用することもできます。

<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7001
MatchExpression *.jsp
MatchExpression *.xyz
</IfModule>

MIMEタイプによってWebLogic Serverのクラスタにリクエストをプロキシする場合は、WebLogicHostおよびWebLogicPortパラメータのかわりにWebLogicClusterパラメータを使用します。例:

<IfModule mod_weblogic.c>
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
MatchExpression *.jsp
MatchExpression *.xyz
</IfModule>

5. パスによってリクエストをプロキシするには、LocationブロックおよびSetHandler文を使用します。SetHandlerは、Apache HTTP Serverプラグイン・モジュールのハンドラを指定します。たとえば、次のLocationブロックでは、URLに/weblogicが含まれるすべてのリクエストがプロキシされます。

<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
</Location>

PathTrimパラメータには、WebLogic Serverインスタンスにリクエストを渡す前にURLの先頭から切り取る文字列を指定します(「Webサーバー・プラグインの一般的なパラメータ」を参照)。

6. 必要に応じて、t3またはIIOPのHTTPトンネリングを有効にします。

1. t3プロトコルおよびweblogic.jarを使用する場合にHTTPトンネリングを有効にするには、次のLocationブロックをhttpd.confファイルに追加します。

<Location /bea_wls_internal/HTTPClnt>
SetHandler weblogic-handler
</Location>

2. IIOP (WebLogic Serverシン・クライアントのwlclient.jarで使用される唯一のプロトコル)を使用する場合にHTTPトンネリングを有効にするには、次のLocationブロックをhttpd.confファイルに追加します。

<Location /bea_wls_internal/iiop>
SetHandler weblogic-handler
</Location>

7. Apache HTTP Serverプラグインの追加パラメータを定義します。
Apache HTTP Serverプラグインは、「Webサーバー・プラグインの一般的なパラメータ」にリストされているパラメータを認識します。Apache HTTP Serverプラグインの動作を変更するには、次のいずれかでパラメータを定義します。

- Locationブロック(パスによるプロキシに適用されるパラメータの場合)、または

- IfModuleブロック(MIMEタイプによるプロキシに適用されるパラメータの場合)。

LocationまたはVirtualHostブロック内へのWebLogicプロパティの配置

IfModuleを使用しない場合は、LocationまたはVirtualHostブロック内にWebLogicプロパティを直接配置できます。次にLocationおよびVirtualHostブロックの例を示します。

<Location /weblogic>
SetHandler weblogic-handler
WebLogicHost myweblogic.server.com
WebLogicPort 7001
</Location>

<Location /weblogic>
SetHandler weblogic-handler
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
</Location>

<VirtualHost apachehost:80>
SetHandler weblogic-handler
WebLogicServer weblogic.server.com
WebLogicPort 7001
</VirtualHost>

httpd.confファイルへのweblogic.confファイルのインクルード

別個の構成ファイルを複数用意する場合は、httpd.confファイルのIfModuleブロックのApache Includeディレクティブを使用して、weblogic.confという独立した構成ファイルでパラメータを定義できます。

<IfModule mod_weblogic.c>
# Config file for WebLogic Server that defines the parameters
Include conf/weblogic.conf
</IfModule>

weblogic.confファイルの構文は、httpd.confファイルの構文と同じです。

この項では、weblogic.confファイルの作成方法を説明し、サンプルのweblogic.confファイルが含まれています。

weblogic.confファイルの作成

weblogic.confファイルを作成する際には、次の点に注意してください。

- パラメータはそれぞれ独立した行に入力します。パラメータとその値の間に'='を挿入しないでください。例:

PARAM_1 value1
PARAM_2 value2
PARAM_3 value3

- IfModuleブロックのMatchExpressionで指定されたMIMEタイプとLocationブロックで指定されたパスの両方にリクエストが一致する場合は、Locationブロックで指定された動作が優先されます。

- Apache HTTP Serverの<VirtualHost>ブロックを使用する場合は、<VirtualHost>ブロック(http://httpd.apache.org/docs/vhosts/のApache仮想ホスト・ドキュメントを参照)内の仮想ホストのすべての構成パラメータ(たとえば、MatchExpression)を含める必要があります。

- 環境内に構成されているすべての仮想ホストのログ・ファイルを1つのみにしたい場合は、グローバル・プロパティを使用すれば実現できます。各仮想ホストでDebug、WLLogFileおよびWLTempDirプロパティを指定するかわりに、<IfModule>タグで一度に指定できます。

- httpd.confファイルのサンプル:

<IfModule mod_weblogic.c>
WebLogicCluster johndoe02:8005,johndoe:8006
Debug ON
WLLogFile             c:/tmp/global_proxy.log
WLTempDir             "c:/myTemp"
DebugConfigInfo       On
KeepAliveEnabled ON
KeepAliveSecs  15
</IfModule>

<Location /jurl>
SetHandler weblogic-handler
WebLogicCluster agarwalp01:7001
</Location>

<Location /web>
SetHandler weblogic-handler
PathTrim/web
Debug OFF
WLLogFile c:/tmp/web_log.log
</Location>

<Location /foo>
SetHandler weblogic-handler
PathTrim/foo
Debug ERR
WLLogFile c:/tmp/foo_proxy.log
</Location>

- /jurl/*に一致するすべてのリクエストではDebug LevelがALLに設定され、ログ・メッセージがc:/tmp/global_proxy.logファイルに記録されます。/web/*に一致するすべてのリクエストではDebug LevelがOFFに設定され、ログ・メッセージは記録されなくなります。/foo/*に一致するすべてのリクエストではDebug LevelがERRに設定され、ログ・メッセージはc:/tmp/foo_proxy.logファイルに記録されます。

- <Files>ブロックではなくMatchExpression文を使用することをお薦めします。

weblogic.conf構成ファイルのサンプル

次のweblogic.confファイルの例をテンプレートとして使用して、ユーザーの環境およびサーバーに合うように変更できます。#で始まる行はコメントです。

例3-1 Weblogicクラスタを使用した例

# These parameters are common for all URLs which are
# directed to the current module. If you want to override
# these parameters for each URL, you can set them again in
# the <Location> or <Files> blocks. (Except WebLogicHost,
# WebLogicPort, WebLogicCluster, and CookieName.)

<IfModule mod_weblogic.c>
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
ErrorPage http://myerrorpage.mydomain.com
MatchExpression *.jsp
</IfModule>
####################################################

例3-2で、ファイル名のパターン、HTTPリクエストのトランスポート先となるWebLogic Serverホストおよびその他のパラメータを表すMatchExpressionパラメータの構文は次のとおりです。

MatchExpression [filename pattern] [WebLogicHost=host] | [paramName=value]

最初のMatchExpressionパラメータではファイル名パターン*.jspを指定してから、1つのWebLogicHost名を指定しています。パイプ記号の後に続くparamName=valueの組合せでWebLogic Serverが接続リクエストをリスニングするポートを指定し、さらにデバッグ・オプションを有効にするよう指定しています。2番目のMatchExpressionでは、ファイル名パターン*.httpを指定し、WebLogicClusterホストおよびそのポートを特定しています。パイプ記号の後に続くparamName=valueの組合せでは、クラスタのエラー・ページを指定しています。

例3-2 複数のWebLogicクラスタを使用した例

# These parameters are common for all URLs which are
# directed to the current module. If you want to override
# these parameters for each URL, you can set them again in
# the <Location> or <Files> blocks (Except WebLogicHost,
# WebLogicPort, WebLogicCluster, and CookieName.)

<IfModule mod_weblogic.c>
MatchExpression *.jsp WebLogicHost=myHost|WebLogicPort=7001|Debug=ON
MatchExpression *.html WebLogicCluster=myHost1:7282,myHost2:7283|ErrorPage=
http://www.xyz.com/error.html
</IfModule>

例3-3に、WebLogicクラスタを使用しない例を示します。

例3-3 WebLogicクラスタを使用しない例

# These parameters are common for all URLs which are
# directed to the current module. If you want to override
# these parameters for each URL, you can set them again in
# the <Location> or <Files> blocks (Except WebLogicHost,
# WebLogicPort, WebLogicCluster, and CookieName.)
<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7001
MatchExpression *.jsp
</IfModule>

例3-4に、複数の名前ベースの仮想ホストを構成する例を示します。

例3-4 複数の名前ベースの仮想ホストを構成する例

# VirtualHost1 = localhost:80
<VirtualHost 127.0.0.1:80>
DocumentRoot "C:/test/VirtualHost1"
ServerName localhost:80
<IfModule mod_weblogic.c>
#... WLS parameter ...
WebLogicCluster localhost:7101,localhost:7201
# Example: MatchExpression *.jsp <some additional parameter>
MatchExpression *.jsp PathPrepend=/test2
</IfModule>
</VirtualHost>

# VirtualHost2 = 127.0.0.2:80
<VirtualHost 127.0.0.2:80>
DocumentRoot "C:/test/VirtualHost1"
ServerName 127.0.0.2:80
<IfModule mod_weblogic.c>
#... WLS parameter ...
WebLogicCluster localhost:7101,localhost:7201
# Example: MatchExpression *.jsp <some additional parameter>
MatchExpression *.jsp PathPrepend=/test2
#... WLS parameter ...
</IfModule>
</VirtualHost>

ServerNameには一意の値を定義する必要があります。一意でない場合、一部のプラグイン・パラメータが意図したとおりに機能しません。

Apache HTTP Server httpd.confファイルのテンプレート

この項には、Apache 2.0のhttpd.confファイルのサンプルが含まれています。このサンプルをテンプレートとして使用し、ユーザーの環境およびサーバーに合うように変更できます。#で始まる行はコメントです。

Apache HTTP Serverでは大文字と小文字は区別されません。

例3-5 Apache 2.0のhttpd.confファイルのサンプル

####################################################
APACHE-HOME/conf/httpd.conf file
####################################################
LoadModule weblogic_module   libexec/mod_wl_20.so

<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
ErrorPage http://myerrorpage1.mydomain.com
</Location>

<Location /servletimages>
SetHandler weblogic-handler
PathTrim /something
ErrorPage http://myerrorpage1.mydomain.com
</Location>

<IfModule mod_weblogic.c>
MatchExpression *.jsp
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001
ErrorPage http://myerrorpage.mydomain.com
</IfModule>

境界認証の設定

Apacheプラグインを介してアクセスされるWebLogic Serverアプリケーションを保護するには、境界認証を使用します。

WebLogic IDアサーション・プロバイダは、WebLogic Serverアプリケーションにアクセスする外部システム(Apache HTTP Serverプラグインを介してWebLogic Serverアプリケーションにアクセスするユーザーを含む)のトークンを認証します。プラグインを保護するIDアサーション・プロバイダを次のように作成します。

1. WebLogic ServerアプリケーションにカスタムIDアサーション・プロバイダを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムIDアサーション・プロバイダの開発方法に関する項を参照してください。

2. Certトークン・タイプをサポートするようにカスタムIDアサーション・プロバイダを構成し、Certをアクティブなトークン・タイプにします。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項を参照してください。

3. Webアプリケーションのweb.xmlデプロイメント記述子ファイルで、clientCertProxyをTrueに設定します。(クラスタを使用する場合、必要に応じて、管理コンソールの「クラスタ」--「構成」--「一般」タブで、クラスタ全体に対して「クライアント証明書プロキシの有効化」属性をtrueに設定します。clientCertProxy属性は、サード・パーティ製のプロキシ・サーバー(ロード・バランサ、SSLアクセラレータなど)で双方向のSSL認証を有効にするために使用できます。clientCertProxy属性の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のcontext-paramに関する項を参照してください。

4. clientCertProxyを設定したら、接続フィルタを使用して、Apacheプラグインが動作しているマシンからの接続のみをWebLogic Serverが受け入れるようにします。『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使用方法に関する項を参照してください。

5. プラグインとWebLogic Serverの間でSSLを使用するには、Webサーバー・プラグインで信頼性のある認証局ファイルが必要になります。Sunのkeytoolユーティリティを使用して、WL_HOME/server/libにあるDemoTrust.jksキーストア・ファイルから信頼性のある認証局ファイルをエクスポートします。

1. たとえば、wlsdemocaファイルを抽出するには次のようなコマンドを使用します。

keytool -export -file trustedcafile.der -keystore DemoTrust.jks -alias wlsdemoca

キーストアから別の信頼性のあるCAファイルを取得するには、別名を変更します。

キーストアの信頼されたCAファイルをすべて表示するには、次を使用します。

keytool -list -keystore DemoTrust.jks

パスワードを要求されたら「Enter」を押します。

2. 認証局ファイルをpem形式に変換するには、コマンドjava utils.der2pem trustedcafile.derを使用します。

『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。

ApacheプラグインでのSSLの使用

Secure Sockets Layer (SSL)プロトコルを使用すると、Apache HTTP ServerプラグインとWebLogic Serverの間の接続を保護できます。SSLプロトコルによって、Apache HTTP ServerプラグインとWebLogic Serverの間でやり取りされるデータに機密性と整合性がもたらされます。

Apache HTTP Serverプラグインは、Apache HTTP ServerプラグインとWebLogic Serverの間の接続の保護にSSLプロトコルが使用されるかどうかを決定する際に、(通常はブラウザによって)HTTPリクエストに指定されるトランスポート・プロトコル(httpまたはhttps)を使用しません。

HTTPクライアントとApache HTTP Server間では相互SSLを使用できますが、Apache HTTP ServerとWebLogic Server間では一方向のSSLが使用されます。

Apache HTTP ServerプラグインとWebLogic Server間のSSLの構成

Apache HTTP ServerプラグインとWebLogic Serverの間でSSLプロトコルを使用するには:

1. SSL向けにWebLogic Serverを構成します。詳細は、「SSLの構成」を参照してください。

2. WebLogic ServerのSSLリスニング・ポートを構成します。詳細は、「SSLの構成」を参照してください。

3. Apacheサーバーで、httpd.confファイルのWebLogicPortパラメータに、ステップ2で構成したWebLogic ServerのSSLリスニング・ポートを設定します。

4. Apacheサーバーで、httpd.confファイルのSecureProxyパラメータをONに設定します。

5. SSL接続の情報を定義する追加パラメータをhttpd.confファイルで設定します。プラグインに構成可能なSSLパラメータのリストについては、「Webサーバー・プラグインのSSLパラメータ」を参照してください。

SSL-Apache構成に関する問題

SSLを使用するためにApacheプラグインを構成する際に、次の既知の問題が発生します:

- プラグイン構成を準備するには、Internet Explorerを使用してロックをクリックして証明書のパスに移動します。

- ルートCA(最上部)を選択します。

- それを表示します。

- 詳細を表示し、「Base 64 X509」オプションを使用してこの証明書を(エクスポート・ウィザードを使用して)ファイルにコピーします。

- ファイルを保存します。たとえば、 MyWeblogicCAToTrust.cer(PEMファイルでもあります)に保存します。

- PathTrimパラメータ(「Webサーバー・プラグインのSSLパラメータ」を参照)を<Location>タグ内に構成する必要があります。
次の構成は正しくありません:

<Location /weblogic>
SetHandler weblogic-handler
</Location>

<IfModule mod_weblogic.c>
WebLogicHost localhost
WebLogicPort 7001
PathTrim /weblogic
</IfModule>

次の構成は正しい設定です。

<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
</Location>

- WebLogic Server Apacheプラグインの現在の実装では、Apache SSLに関して複数の証明書ファイルの使用はサポートされていません。

接続エラーとクラスタリング・フェイルオーバー

Apache HTTP Serverプラグインは、WebLogic Serverに接続しようとする際に、複数の構成パラメータを使用してWebLogic Serverホストへの接続の待機時間と、接続確立後のレスポンスの待機時間を決定します。接続できないか、またはレスポンスがない場合、プラグインはクラスタ内の別のWebLogic Serverインスタンスに接続してリクエストを送信しようとします。接続が失敗するか、またはクラスタ内のいずれのWebLogic Serverからもレスポンスがない場合は、エラー・メッセージが送信されます。

図3-1は、プラグインがどのようにフェイルオーバーを処理するかを示しています。

接続失敗の考えられる原因

WebLogic Serverホストが接続リクエストに対するレスポンスに失敗した場合、次の問題が考えられます。

- ホスト・マシンの物理的な問題

- ネットワークの問題

- その他のサーバーの障害

すべてのWebLogic Serverインスタンスがレスポンスに失敗した場合、次の問題が考えられます。

- WebLogic Serverが実行中でないか、使用不可になっている

- サーバーのハング

- データベースの問題

- アプリケーション固有の障害

Connection_Refusedエラーを減らすためのチューニング

負荷がかかっていると、ApacheプラグインはバックエンドのWebLogic ServerインスタンスからCONNECTION_REFUSEDエラーを受け取ることがあります。CONNECTION_REFUSEDエラーを減らすには、チューニングに関する次のヒントに従ってください。

- WebLogic Serverドメインの構成のAcceptBackLog設定を増やします。

- Apache 2.0.xで、httpd.confファイルのKeepAliveディレクティブをOnに設定します。例:

# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

http://httpd.apache.org/docs-project/のApache HTTP Server 2.0ドキュメントを参照してください。

- 待機時間を短くします。この設定は、使用するオペレーティング・システムによって異なります。例:

- Windows NTでは、プロキシおよびWebLogic ServerのTcpTimedWaitDelayをより小さな値に設定します。HKEY_LOCAL_MACHINE配下のレジストリ・キーを編集して、Windows NTでのTIME_WAIT間隔を設定します。

SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay

このキーが存在しない場合、DWORD値として作成します。数値は待機する秒数で、30と240の間の任意の値を設定できます。設定しない場合、Windows NTでは、デフォルトで240秒がTIME_WAITに設定されます。

- Windows 2000では、HKEY_LOCAL_MACHINE配下のレジストリ・キーを編集してTcpTimedWaitDelayの値を小さくします。

SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

- Solarisでは、(可能であれば、WebLogic ServerマシンとApacheマシンの両方で)tcp_time_wait_intervalの設定を1秒に減らします。

$ndd /dev/tcp
param name to set - tcp_time_wait_interval
value=1000

- マシン上でオープン・ファイル記述子の制限値を増加します。この制限はオペレーティング・システムによって異なります。limit (.csh)またはulimit (.sh)ディレクティブを使用して、制限値を増やすスクリプトを作成できます。例:

#!/bin/sh
ulimit -S -n 100
exec httpd

- Solarisでは、WebLogic Serverマシンの次のチューニング可能項目の値を増やします。

tcp_conn_req_max_q tcp_conn_req_max_q0

クラスタリングされていない単一のWebLogic Serverでのフェイルオーバー

WebLogic Serverインスタンスを1つだけ実行している場合、プラグインはWebLogicHostパラメータで定義されているサーバーに接続しようとします。その試行が失敗すると、HTTP 503エラー・メッセージが戻されます。プラグインは、ConnectTimeoutSecsとConnectRetrySecsの比によって規定される最大再試行回数に従って、WebLogic Serverインスタンスへの接続を試行します。

動的サーバー・リスト

クラスタリングされたバックエンド・サーバーのリストにプロキシするため、またはクラスタリングされていない管理対象サーバー・インスタンスのロード・バランシングを実行するため、WebLogicClusterパラメータが必要です。

クラスタリングされた管理対象サーバーにプロキシする場合、httpd.confまたはweblogic.confファイルでWebLogicClusterパラメータを使用してWebLogic Serverのリストを指定すると、プラグインはクラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つに転送された後に、クラスタ内のサーバーの更新されたリストを格納する動的サーバー・リストが戻されます。更新されたリストでは、クラスタ内の新しいサーバーが追加され、クラスタを離脱したサーバーやリクエストに応答できなかったサーバーは削除されます。このリストは、クラスタ内で変化が発生したときにHTTPレスポンスによって自動的に更新されます。

フェイルオーバー、CookieおよびHTTPセッション

リクエストが、CookieやPOSTデータに格納されているかURLにエンコードされたセッション情報を含む場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼びます)への参照が含まれています。Cookieを含むリクエストは、プライマリ・サーバーに接続しようとします。その試行が失敗すると、プラグインはラウンド・ロビン方式でリストの次の使用可能なサーバーに接続しようとします。そのサーバーは元のセカンダリ・サーバーからセッションを取得し、その同じセッションのプライマリ・サーバーになります。詳細は、図3-1を参照してください。

注意:
POSTデータが64Kを超える場合、プラグインは、セッションIDを取得するためのPOSTデータの解析を行いません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリまたはセカンダリ・サーバーにルーティングできないので、セッション・データが失われるおそれがあります。

図3-1 接続のフェイルオーバー

「図3-1 接続フェイルオーバー」の説明」

この図において、赤いループで許容される最大再試行回数は、ConnectTimeoutSecs/ConnectRetrySecsの値に相当します。

4 Microsoft IISプラグインのインストールと構成

次の項では、Microsoft Internet Information Serverプラグインをインストールして構成する方法を説明します。

- Microsoft Internet Information Serverプラグインの概要

- 動作確認

- ワイルドカード・アプリケーション・マッピングを使用したパスによるプロキシ

- Microsoft Internet Information Serverプラグインのインストールと構成

- Microsoft Internet Information Server IIs 7.0プラグインのインストールと構成

- 複数の仮想WebサイトからのWebLogic Serverへのリクエストのプロキシ

- IISを経由するACLの作成

- 境界認証の設定

- Microsoft Internet Information ServerプラグインでのSSLの使用

- IISからWebLogic Serverへのサーブレットのプロキシ

- インストールのテスト

- 接続エラーとクラスタリング・フェイルオーバー

Microsoft Internet Information Serverプラグインの概要

Microsoft Internet Information Serverプラグインを使用すると、Microsoft Internet Information Server (IIS)からWebLogic Serverにリクエストをプロキシできます。このプラグインは、WebLogic Serverの動的な機能を必要とするリクエストをWebLogic Serverが処理できるようにすることによってIISを拡張します。

Microsoft Internet Information Serverプラグインは、Internet Information Server (IIS)がHTMLページなどの静的ページを提供し、WebLogic ServerがHTTPサーブレットまたはJavaServer Pagesなどの動的ページを提供する環境で使用します。WebLogic Serverは、(場合によっては別のホストの)別のプロセスで動作している場合もあります。それでも、エンド・ユーザー(ブラウザ)には、WebLogic Serverに委任されるHTTPリクエストはIISから送られているように見えます。WebLogicクライアント/サーバー・プロトコルのHTTPトンネリング機能もこのプラグインを介して動作し、すべてのWebLogic Serverサービスへのアクセスを提供します。

接続プールとキープアライブ

Microsoft Internet Information Serverプラグインでは、プラグインからWebLogic Serverへの接続のプールを使用してパフォーマンスを向上させます。このプラグインは、同じクライアントからの後続リクエストに同じ接続を再利用することで、WebLogic Serverとの間でHTTP 1.1キープアライブ接続を実装します。接続が30秒(またはユーザー定義の時間)を超えて非アクティブな場合、その接続は閉じられます。クライアントとの接続は、それがタイムアウトになっていなければ、後で同じクライアントと接続するときに再利用できます。この機能は、必要に応じて無効にできます。詳細は、表7-1のKeepAliveEnabledを参照してください。

リクエストのプロキシ

プラグインは、ユーザーが指定する構成に基づいてリクエストをWebLogic Serverにプロキシします。リクエストのURLまたはURLの一部に基づいてリクエストをプロキシできます。これを、パスによるプロキシと呼びます。

リクエスト対象のファイルのMIMEタイプに基づいてリクエストをプロキシすることもできます(ファイル拡張子によるプロキシと呼びます)。

両方の方法を有効にすることもできます。両方の方法を有効にし、リクエストが両方の基準に一致する場合、そのリクエストはパスによってプロキシされます。

これらのリクエストの種類ごとに、プラグインの追加の動作を定義する追加パラメータを指定することもできます。詳細は、「ワイルドカード・アプリケーション・マッピングを使用したパスによるプロキシ」および「Microsoft Internet Information Serverプラグインのインストールと構成」を参照してください。

動作保証

Microsoft Internet Information Serverプラグインと互換性のあるオペレーティング・システムおよびIISバージョンの最新情報は、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlを参照してください。

ワイルドカード・アプリケーション・マッピングを使用したパスによるプロキシ

「Installing Wildcard Application Mappings (IIS 6.0)」(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5c5ae5e0-f4f9-44b0-a743-f4c3a5ff68ec.mspx?mfr=true)およびIIS 7.0用の「Add a Wildcard Script Map」(http://technet.microsoft.com/en-us/library/cc754606(WS.10).aspx)に記述されているように、リクエスト対象のファイルの拡張子にかかわらず、Webサイトまたは仮想ディレクトリへの各リクエストの開始部分でInternet Server API (ISAPI)を実行するようにWebサイトまたは仮想ディレクトリを構成することができます。この機能を使用して、iisproxy.dllにマッピングを挿入し、リクエストをWebLogic Serverへとパスによってプロキシできます。

ワイルドカード・アプリケーション・マッピングのインストール(IIS 6.0)

次の手順は、「Installing Wildcard Application Mappings (IIS 6.0)」(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5c5ae5e0-f4f9-44b0-a743-f4c3a5ff68ec.mspx?mfr=true)にある、ワイルドカード・アプリケーション・マッピングをIIS 6.0のWebサーバーまたはWebサイトに追加するための指示を要約したものです。

1. IISマネージャでローカル・コンピュータとWebサイト・フォルダを拡張し、使用するWebサイトまたは仮想ディレクトリを右クリックし、「プロパティ」をクリックします。

2. ホーム・ディレクトリタブ、仮想ディレクトリタブまたはディレクトリタブの適切なタブをクリックします。

3. アプリケーション設定で「構成」をクリックし、「マッピング」タブをクリックします。

4. ワイルドカード・アプリケーション・マップをインストールするには、次を行います。

1. 「マッピング」タブで「挿入」をクリックします。

2. 実行ファイルテキスト・ボックスでiisproxy.dll DLLへのパスを入力するか、「参照」をクリックして移動します。

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

IIS 7.0用のワイルドカード・スクリプト・マップの追加

次の手順は、IS 7.0用の「Add a Wildcard Script Map」(http://technet.microsoft.com/en-us/library/cc754606(WS.10).aspx)にある、ワイルドカード・スクリプト・マップを追加して、IIS 7.0でISAPIを使用してパスによるプロキシを行うための指示を要約したものです。

1. IISマネージャを開き、操作するレベルに移動します。IISマネージャを開く操作についての情報は、http://technet.microsoft.com/en-us/library/cc770472(WS.10).aspxにある「IISマネージャを開く」を参照してください。UI内の場所への移動については、http://technet.microsoft.com/en-us/library/cc732920(WS.10).aspxにある「IISマネージャでのナビゲーション」を参照してください。

2. サーバー、サイトまたはアプリケーション・ホームページの機能ビューでハンドラのマッピングをダブルクリックします。

3. 「ハンドラ・マッピング」ページの「アクション」ペインで、ワイルドカード・スクリプト・マップをクリックします。

4. 「実行ファイル」ボックスに完全なパスを入力するか、リクエストを処理するiisproxy.dllを参照します。たとえば、systemroot\system32\inetsrv\iisproxy.dllを入力します。

5. 「名前」ボックスにハンドラ・マッピングのわかりやすい名前を入力します。

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

7. オプションで、ハンドラ・マッピングページで、そのページをロックまたはロック解除するためにハンドラを選択します。ハンドラ・マッピングをロックすると、構成のより下位レベルでオーバーライドされません。リストからハンドラ・マッピングを選択し、「アクション」ペインの「ロックまたはロック解除」をクリックします。

8. ワイルドカード・スクリプト・マップの追加後、実行ファイルをISAPIおよびCGI権限リストに追加して実行可能にする必要があります。ISAPIおよびCGI権限の詳細は、http://technet.microsoft.com/en-us/library/cc730912(WS.10).aspxの「Configuring ISAPI and CGI Restrictions in IIS 7」を参照してください。

Microsoft Internet Information Serverプラグインのインストールと構成

Microsoft Internet Information Serverプラグインをインストールするには:

1. WebLogic ServerをインストールしたWL_HOME/server/plugin/win/32またはWL_HOME/server/plugin/win/64ディレクトリからiisproxy.dllファイルをコピーします(WL_HOMEはWebLogic PlatformおよびWebLogic Serverの最上位ディレクトリを表し、IISにアクセスできる便利なディレクトリにWebLogic Serverのインストール・ファイルが格納されています)。このディレクトリには、ステップ4で作成するiisproxy.iniファイルも格納する必要があります。iisproxy.dllファイル用のユーザーの権限を設定し、IISを実行するユーザーの名前を含めます。たとえば、iisproxy.dllファイル上で右クリックして権限を選択し、IISを実行する人のユーザー名を追加するという方法で行えます。

2. ファイル拡張子(MIMEタイプ)によるプロキシを構成する場合は、次の手順を実行します。(MIMEタイプによるプロキシに加えて、またはそのかわりに、パスによるプロキシも構成できます。ステップ3を参照してください。)

1. 「スタート」メニューから Internet Information Serviceマネージャを選択して、起動します。

2. 「サービス・マネージャ」の左側のパネルでWebサイトを選択します(デフォルトは「デフォルトWebサイト」です)。

図4-1 サービス・マネージャでのWebサイトの選択

「図4-1 サービス・マネージャでのWebサイトの選択」の説明

3. ツール・バーの再生ボタンをクリックして起動します。

4. 左側のパネルにあるWebサイトの選択を右クリックしプロパティを選択して、Webサイトのプロパティを開きます。

図4-2 選択されたWebサイトのプロパティの選択

「図4-2 選択されたWebサイトのプロパティの選択」の説明

5. 「プロパティ」パネルで、「ホーム・ディレクトリ」タブを選択し、「アプリケーションの設定」セクションの「構成」ボタンをクリックします。

図4-3 プロパティ・パネルのホーム・ディレクトリのタブ

「図4-3 プロパティ・パネルのホーム・ディレクトリのタブ」の説明

6. マッピングタブの「追加」ボタンをクリックして、ファイル・タイプを追加し、それらがWebLogic Serverにプロキシされるように構成します。

図4-4 追加ボタンをクリックしてファイル・タイプを追加する

「図4-4 追加ボタンをクリックしてファイル・タイプを追加する」の説明

7. 「追加」ダイアログ・ボックスを参照してiisproxy.dllファイルを探します。

8. 拡張子を、WebLogic Serverにプロキシするファイルのタイプに設定します。

9. IIS 6.0以降の構成の場合、ファイルの存在を確認するチェック・ボックスをオフにします。この確認の動作は以前のバージョンのIISから変更されています。以前は、iisproxy.dllファイルの存在を確認していましたが、プロキシからリクエストされたファイルがWebサーバーのルート・ディレクトリに存在するかどうかを確認するようになりました。この確認でファイルが見つからなかった場合、iisproxy.dllファイルはWebLogic Serverにリクエストをプロキシできません。

10. 「ディレクトリ・セキュリティ」タブで、セキュアなインストールを作成するために、必要に応じて「メソッド除外」を設定します。

11. 完了したら、「OK」ボタンをクリックして構成を保存します。この手順を、WebLogicにプロキシするファイル・タイプごとに繰り返します。

12. ファイル・タイプの構成が完了したら、「OK」ボタンをクリックして「プロパティ」パネルを閉じます。

注意:
URLのサーバーとポートの後ろに追加されたパス情報は、WebLogic Serverにそのまま渡されます。たとえば、次のURLでIISにファイルをリクエストした場合:
http://myiis.com/jspfiles/myfile.jsp

http://mywebLogic:7001/jspfiles/myfile.jspのようなURLでWebLogic Serverにプロキシされます。

注意:
アウト・オブ・プロセス・エラーを避けるため、「すべての不明なISAPI拡張」チェック・ボックスをオフにしないでください。

3. パスによるプロキシを構成する場合は、次の手順を実行します。(ファイル・タイプによるプロキシのほか、iisproxy.iniファイルに追加パラメータを指定することで、パスに基づいてファイルを提供するようにMicrosoft Internet Information Serverプラグインを構成できます。)パスによるプロキシは、MIMEタイプによるプロキシに優先します。
また、パスによってIISで定義されている複数のWebサイトをプロキシすることもできます。詳細は、「複数の仮想WebサイトからWebLogic Serverへのリクエストのプロキシ」を参照してください。

パスによるプロキシを構成するには:

1. 「スタート」メニューから Internet Information Serviceマネージャを選択して、起動します。

2. iisforward.dllファイルをiisproxy.dllファイルと同じディレクトリに置き、iisforward.dllファイルをフィルタ・サービスとしてIISに追加します(Webサイト・プロパティ->ISAPIフィルタタブ->iisforward dllの追加)。iisforward.dllファイル用のユーザー権限を設定し、IISを実行するユーザーの名前を含めます。これを行う方法の1つとして、iisproxy.dllファイル上で右クリックして権限を選択し、IISを実行する人のユーザー名を追加するやり方があります。

3. IISにおいてiisproxy.dllで処理される特殊なファイル・タイプとして.wlforwardを登録します。

4. iisproxy.iniでWlForwardPathプロパティを定義します。WlForwardPathでは、たとえば次のように、WebLogic Serverにプロキシするパスを定義します。 WlForwardPath=/weblogic

5. PathTrimパラメータを設定して、必要に応じてWlForwardPathを削除します。たとえば、次を使用して:

WlForwardPath=/weblogic
PathTrim=/weblogic

IISからWebLogic Serverへのリクエストの開始部分を削除します。したがって、/weblogic/sessionが/sessionに変更されます。

6. パス情報が含まれていない(ホスト名しか含まれていない)リクエストが必要な場合は、DefaultFileNameパラメータを、リクエストがプロキシされるWebアプリケーションのウェルカム・ページの名前に設定します。このパラメータの値は、URLに追加されます。

7. アプリケーションをデバッグする必要がある場合は、iisproxy.iniでDebug=ONパラメータを設定します。デバッグに利用できるプラグインのアクティビティのログを記録したc:\tmp\iisforward.logが生成されます。

4. WebLogic Serverで、iisproxy.iniファイルを作成します。
iisproxy.iniファイルには、プラグインの構成パラメータを定義する名前=値ペアが格納されます。パラメータのリストは、表7-1を参照してください。

iisproxy.iniファイルのテンプレートとしてSample iisproxy.iniファイル内のiisproxy.iniファイルのサンプルを使用します。

注意:
「IIS Admin Service」(コントロール・パネルの「サービス」にあります)を再起動するまで、パラメータの変更は有効になりません。

iisproxy.iniファイルをiisproxy.dllファイルと同じディレクトリに配置することをお薦めします。他の場所を使用することもできます。他のディレクトリに配置した場合、次のディレクトリにおいて次の順序でiisproxy.iniが検索されます。

1. isproxy.dllが配置されているディレクトリ。

2. Windowsレジストリで参照されている最新バージョンのWebLogic Serverのホーム・ディレクトリ。(ホーム・ディレクトリでiisproxy.iniファイルが見つからない場合、WebLogic Serverは、WindowsレジストリでWebLogic Serverの旧バージョンを調べ、古いインストール環境のホーム・ディレクトリでiisproxy.iniファイルを探します。)

3. c:\weblogicディレクトリ(存在する場合)。

5. Microsoft Internet Information ServerプラグインがリクエストをプロキシするWebLogic Serverのホストとポート番号を定義します。構成によって、次の2通りの方法でホストとポートを定義できます。

- 1つのWebLogic Serverにリクエストをプロキシする場合は、iisproxy.iniファイルでWebLogicHostパラメータとWebLogicPortパラメータを定義します。例:

WebLogicHost=localhost
WebLogicPort=7001

- WebLogic Serverのクラスタにリクエストをプロキシする場合は、iisproxy.iniファイルでWebLogicClusterパラメータを定義します。例:

WebLogicCluster=myweblogic.com:7001,yourweblogic.com:7001

myweblogic.comとyourweblogic.comは、クラスタ内で動作するWebLogic Serverのインスタンスです。

6. 必要であれば、パスによるプロキシの手順に従ってHTTPトンネリングを有効にし(「ワイルドカード・アプリケーション・マッピングを使用したパスによるプロキシ」を参照)、HTTPトンネリング・リクエストを処理させるWebLogic Serverホスト名とWebLogic Serverポート番号、またはWebLogicクラスタの名前を置き換えてください。

7. iisproxy.iniファイルに追加パラメータを設定します。パラメータの詳細なリストは、付録「Webサーバー・プラグインの一般的なパラメータ」で参照できます。

8. IISからWebLogic Serverにサーブレットをプロキシする際に、パスによるプロキシを行わない場合は、「IISからWebLogic Serverへのサーブレットのプロキシ」を参照してください。

9. 初期設定でインストールされているバージョンのIISでは、iisproxy.dllは許可されていません。IISマネージャ・コンソールを使用して、プラグインを有効にしてください。

1. IISマネージャ・コンソールを起動します。

2. 「Webサービス拡張」を選択します。

3. 「すべての不明なISAPI拡張」を「許可」に設定します。

Microsoft Internet Information Server IIs 7.0プラグインのインストールと構成

この項では、Microsoft Internet Information Server IIs 7.0プラグインの設定方法の差異について説明します。

Microsoft Internet Information Server IIs 7.0プラグインを設定するには、次のステップに従います。

1. 「Webサイト」->「Webサイトの追加」を右クリックしてIISマネージャにWebアプリケーションを作成します。
「Webサイトの名前」にWebアプリケーションに付ける名前(たとえば、MyApp)を入力します。Webサイト・アプリケーション・ポート(現在使用されていない有効なポート番号)の物理パスを選択します。

「OK」をクリックして、Webアプリケーションを作成します。

「Webサイト」の下にアプリケーションの名前が表示されていれば、アプリケーションが作成され、実行が開始されたことを意味します。MyAppアプリケーションに関するすべての設定(変更可能)を参照するには、「Webサイト」の下のMyAppノードをクリックします(図4-5を参照)。

図4-5 アプリケーションのホーム・ページ

「図4-5 アプリケーションのホーム・ページ」の説明

2. 「ハンドラ・マッピング」をクリックして、特定のMIMEタイプのハンドラのマッピングを設定します。

図4-6 ハンドラ・マッピングの設定

「図4-6 ハンドラ・マッピングの設定」の説明

3. 「StaticFile」をクリックし、リクエスト・パスを*から*.*に変更します。「OK」をクリックします。

図4-7 モジュールのリクエスト・パスの編集

「図4-7 モジュールのリクエスト・パスの編集」の説明

4. MyAppをクリックして、右側のメニュー・オプションのスクリプト・マップの追加をクリックします。リクエスト・パスに*を入力します。
iisproxy.dllファイルを参照し、実行ファイルとして追加します。proxyという名前を付けます。

図4-8 スクリプトのリクエスト・パスの編集

「図4-8 スクリプトのリクエスト・パスの編集」の説明

5. 「リクエストの制限」ボタンをクリックし、「リクエストが指定した項目にマップされている場合のみハンドラを呼び出す」ボックスの選択を解除してください。

図4-9 リクエスト制限の編集

「図4-9 リクエスト制限の編集」の説明

6. このハンドラ・マッピングを追加するには、「OK」をクリックします。スクリプト・マップの追加ダイアログ・ボックスの「はい」をクリックします。

図4-10 スクリプト・マップの追加

「図4-10 スクリプト・マップの追加」の説明

7. パスによるプロキシを構成するには、スクリプト・マップの追加をクリックします。リクエスト・パスを*.wlforwardとして指定して、実行可能ファイルをiisproxy.dllとして選択します。
「リクエストの制限」ボタンをクリックし、「リクエストが指定した項目にマップされている場合のみハンドラを呼び出す」ボックスの選択を解除してください。

このハンドラ・マッピングを追加するには、「OK」をクリックします。スクリプト・マップの追加ダイアログ・ボックスの「はい」をクリックします。

図4-11 パスによるプロキシのためのスクリプト・マップの追加

「図4-11 パスによるプロキシのためのスクリプト・マップの追加」の説明

8. 左側のMyAppアプリケーションをクリックし、ISAPIフィルタをクリックします。「追加」をクリックして、ISAPIフィルタを追加します。
フィルタ名としてforwardと入力し、実行可能ファイルとしてiisforward.dllを選択します。「OK」をクリックします。

図4-12 ISAPIフィルタの編集

「図4-12 ISAPIフィルタの編集」の説明

9. IISマネージャ・ツリーのルート・ノードをクリックし、ISAPIとCGIの制限をクリックします。未指定のISAPIモジュールを許可チェック・ボックスを選択します。

図4-13 ISAPIおよびCGIの制限の編集

「図4-13 ISAPIおよびCGIの制限の編集」の説明

10. 次の内容のiisproxy.iniというファイルを作成し、プラグインのあるディレクトリに置きます。

WebLogicHost= @hostname@
WebLogicPort= @port@
ConnectRetrySecs=5
ConnectTimeoutSecs=25
Debug=ALL
DebugConfigInfo=ON
KeepAliveEnabled=true

WlForwardPath=/weblogic
PathTrim=/weblogic

WLLogFile=@Log file name@
SecureProxy=OFF

11. Internet Explorerブラウザを開き、http://<hostname>:<port>を入力します。Weblogic ServerでMedrecサンプル・アプリケーションが表示されます。
SSLモードでプラグインを実行する場合、WeblogicPortの値をアプリケーションのSSLポートに変更し、SecureProxyの値をONに変更します。

図4-14 Medrecサンプル・アプリケーション

「図4-14 Medrecサンプル・アプリケーション」の説明

複数の仮想WebサイトからWebLogic Serverへのリクエストのプロキシ

複数のWebサイト(IISで仮想ディレクトリとして定義)からWebLogic Serverへリクエストをプロキシするには:

1. 仮想ディレクトリ用に新しいディレクトリを作成します。このディレクトリには、プロキシの定義に使用されるdllおよびiniファイルが格納されます。

2. ステップ1で作成したディレクトリにiisforward.dllをコピーします。

3. 各Webサイトのiisforward.dllをIISに登録します。

4. iisforward.iniというファイルを作成します。このファイルはiisforward.dllと同じディレクトリに配置します。このファイルには、IISに定義されている仮想Webサイトごとに次のエントリを格納する必要があります。

vhostN=websiteName:port
websiteName:port=dll_directory/iisproxy.ini

説明:

- N は、仮想Webサイトを表す整数です。最初に定義する仮想Webサイトには整数1を使用し、以降のWebサイトには順に1ずつ増やします。

- websiteNameは、IISに登録した仮想Webサイトの名前です。

- portは、IISがHTTPリクエストをリスニングしているポート番号です。

- dll_directoryは、ステップ1で作成したディレクトリへのパスです。

例:

vhost1=strawberry.com:7001
strawberry.com:7001=c:\strawberry\iisproxy.ini
vhost2=blueberry.com:7001
blueberry.com:7001=c:\blueberry\iisproxy.ini
...

5. 「プロキシ・リクエスト」のステップ4の説明に従って、仮想Webサイトのiisproxy.iniファイルを作成します。このiispoxy.iniファイルをステップ1で作成したディレクトリにコピーします。

6. ステップ1で作成したディレクトリにiisproxy.dllをコピーします。

7. IIS 5.0で、「アプリケーション保護」オプションの値を「高(分離プロセス)」に設定します。「アプリケーション保護」オプションを「中(プール)」に設定すると、最初のWebサイトとして登録されたiisproxy.dllが常に呼び出されます。この場合、すべてのリクエストは、最初のWebサイトのiisproxy.iniで定義された同じWebLogic Serverインスタンスにプロキシされます。
IIS 6.0以降の場合、各仮想ディレクトリに対して個別のアプリケーション・プールを作成します。

「アプリケーション・プールの作成(IIS 6.)」(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/93275ef2-2f85-4eb1-8b92-a67545be11b4.mspx?mfr=true)で説明されているように、異なるWebアプリケーションまたはWebサイトをプール内に分離できます。これらのプールはアプリケーション・プールと呼ばれます。アプリケーション・プールでは、プロセス境界が各ワーカー・プロセスをほかのワーカー・プロセスから分離することにより、アプリケーションが1つのアプリケーション・プールにルーティングされるときに別のアプリケーション・プールのアプリケーションがそのアプリケーションに影響を及ぼさないようにします。

iisproxy.iniファイルのサンプル

次に、クラスタ化されていない1つのWebLogic Serverで使用するサンプルiisproxy.iniファイルを示します。先頭に「#」が付いた行はコメントです。

# This file contains initialization name/value pairs
# for the IIS/WebLogic plug-in.
WebLogicHost=localhost
WebLogicPort=7001
ConnectTimeoutSecs=20
ConnectRetrySecs=2

次に、クラスタ化されたWebLogic Serverで使用するサンプルiisproxy.iniファイルを示します。先頭に「#」が付いた行はコメントです。

# This file contains initialization name/value pairs
# for the IIS/WebLogic plug-in.
WebLogicCluster=myweblogic.com:7001,yourweblogic.com:7001
ConnectTimeoutSecs=20
ConnectRetrySecs=2

注意:
プラグインとWebLogic Serverの間でSSLを使用する場合は、SSLリスニング・ポートとしてポート番号を定義する必要があります。

IISを経由するACLの作成

ACLは、IISからAuthorizationヘッダーが渡されない場合はMicrosoft Internet Information Serverプラグインでは機能しません。次の情報を参考にして、AuthorizationヘッダーがIISによって渡されることを確認してください。

基本認証を使用する場合、ユーザーはローカルのログオン権限でログオンします。基本認証の使用を有効にするには、IISサーバーで各ユーザー・アカウントに「ローカル・ログオン」ユーザー権限を付与します。基本認証のローカル・ログオンを使用する場合、2つの問題が発生する可能性があります。

- ユーザーにローカル・ログオン権限がない場合、FrontPage、IIS、およびWindows NTが正しく構成されているように見えても、基本認証は機能しません。

- ローカル・ログオン権限があり、IISを実行しているホスト・コンピュータへの物理的なアクセスを取得できるユーザーは、コンソールでの対話セッションの開始を許可されます。

基本認証を有効にするには、コンソールの「ディレクトリ・セキュリティ」タブで、「匿名を許可」がオン、それ以外のオプションがすべてオフになっていることを確認してください。

境界認証の設定

Microsoft Internet Information Serverプラグインを介してアクセスされるWebLogic Serverアプリケーションを保護するには、境界認証を使用します。

WebLogic IDアサーション・プロバイダは、WebLogic Serverアプリケーションにアクセスする外部システム(Microsoft Internet Information Serverプラグインを介してWebLogic Serverアプリケーションにアクセスするユーザーを含む)のトークンを認証します。プラグインを保護するIDアサーション・プロバイダを、次のように作成します。

1. WebLogic ServerアプリケーションにカスタムIDアサーション・プロバイダを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムIDアサーション・プロバイダの開発方法に関する項を参照してください。

2. Certトークン・タイプをサポートするようにカスタムIDアサーション・プロバイダを構成し、これをアクティブなトークン・タイプにします。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項を参照してください。

3. Webアプリケーションのweb.xmlデプロイメント記述子ファイルでclientCertProxy属性を「True」に設定します。(クラスタを使用する場合、必要に応じて、管理コンソールの「クラスタ」--「構成」--「一般」タブで、クラスタ全体に対して「クライアント証明書プロキシの有効化」属性を「true」に設定します。)『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のcontext-paramを参照してください。

4. clientCertProxyを設定したら、Microsoft Internet Information Serverプラグインが動作しているマシンからの接続のみをWebLogic Serverが受け入れるようにします。『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使用方法に関する項を参照してください。

5. プラグインとWebLogic Serverの間でSSLを使用するには、Webサーバー・プラグインで信頼性のある認証局ファイルが必要になります。Sunのkeytoolユーティリティを使用して、WL_HOME/server/libにあるDemoTrust.jksキーストア・ファイルから信頼性のある認証局ファイルをエクスポートします。

1. たとえば、wlsdemocaファイルを抽出するには次のコマンドを使用します。

keytool -export -file trustedcafile.der -keystore DemoTrust.jks -alias wlsdemoca

キーストアから別の信頼性のあるCAファイルを取得するには、別名を変更します。

キーストアの信頼されたCAファイルをすべて表示するには、次を使用します。 keytool -list -keystore DemoTrust.jks

パスワードを要求されたら「Enter」を押します。

2. 認証局ファイルをpem形式に変換するには、java utils.der2pem trustedcafile.derを使用します。

IDアサーション・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。

Microsoft Internet Information ServerプラグインでのSSLの使用

Secure Sockets Layer (SSL)プロトコルを使用すると、WebLogic ServerとMicrosoft Internet Information Serverプラグインの間の接続を保護できます。SSLプロトコルによって、Microsoft Internet Information ServerプラグインとWebLogic Serverの間でやり取りされるデータに機密性と整合性がもたらされます。

Microsoft Internet Information Serverプラグインは、プロキシ・プラグインとMicrosoft Internet Information Serverの間の接続が保護にSSLプロトコルが使用されるかどうかを決定する際に、トランスポート・プロトコル(httpまたはhttps)を使用しません。Microsoft Internet Information ServerプラグインでSSLプロトコルを使用するには、プロキシされるリクエストを受け取るWebLogic Serverインスタンスを、SSLプロトコルを使用するように構成します。Microsoft Internet Information Serverプラグインは、セキュアなSSL通信を使用するように構成されたWebLogic Server上のポートを使用してMicrosoft Internet Information Serverと通信します。

Microsoft Internet Information ServerプラグインとWebLogic Serverの間でSSLプロトコルを使用するには:

1. SSL向けにWebLogic Serverを構成します。詳細は、「SSLの構成」を参照してください。

2. WebLogic ServerのSSLリスニング・ポートを構成します。詳細は、「SSLの構成」を参照してください。

3. iisproxy.iniファイルのWebLogicPortパラメータを、ステップ2で構成したリスニング・ポートに設定します。

4. iisproxy.iniファイルのSecureProxyパラメータをONに設定します。

5. SSL接続の情報を定義する追加パラメータをiisproxy.iniファイルに設定します。パラメータの詳細なリストは、「Webサーバー・プラグインのSSLパラメータ」を参照してください。

例:

WebLogicHost=myweblogic.com
WebLogicPort=7002
SecureProxy=ON

IISからWebLogic Serverへのサーブレットのプロキシ

iisforward.dllがフィルタとして登録されている場合は、サーブレットをパスによってプロキシできます。その場合は、次のようなURLでサーブレットを呼び出します。

http://IISserver/weblogic/myServlet

iisforward.dllがフィルタとして登録されていない場合にサーブレットをプロキシするには、ファイル・タイプによるサーブレットのプロキシを構成する必要があります。ファイル・タイプによってサーブレットをプロキシするには:

1. WebLogic ServerにリクエストをプロキシできるようにIISに任意のファイル・タイプ(拡張子)を登録します。詳細は、「Microsoft Internet Information Serverプラグインのインストールと構成」のステップ2を参照してください。

2. 適切なWebアプリケーションにサーブレットを登録します。サーブレットの登録の詳細は、「サーブレットの作成と構成」を参照してください。

3. このパターンに従った形式のURLでサーブレットを呼び出します。

http://www.myserver.com/virtualName/anyfile.ext

virtualNameは、このサーブレットのWebアプリケーション・デプロイメント記述子(web.xml)の<servlet-mapping>要素で定義されたURLパターン、extはWebLogic ServerにプロキシするためにIISに登録されたファイル・タイプ(拡張子)です。URLのanyfileの部分は、このコンテキストでは無視されます。

注意:
サーブレットから呼び出される画像リンクがWebアプリケーションの一部である場合は、IISに適切なファイル・タイプ(.gifや.jpgなど)を登録して画像に対するリクエストもWebLogic Serverにプロキシする必要があります。ただし、それらの画像はIISから直接提供されるようにすることもできます。
プロキシ対象のサーブレットに他のサーブレットを呼び出すリンクがある場合は、そのリンクもステップ3のパターンに従ってWebLogic Serverにプロキシする必要があります。

インストールのテスト

Microsoft Internet Information Serverプラグインをインストールして構成した後は、次の手順に従ってデプロイメントとテストを行います。

1. WebLogic ServerとIISが動作していることを確認します。

2. JSPファイルをデフォルトWebアプリケーションのドキュメント・ルートに保存します。

3. 次の例で示されているように、ブラウザを開き、IIS plusファイル名の後に.jspを付けてURLに設定します。

http://myii.server.com/filename.jsp

filename.jspがブラウザに表示されば、プラグインは正常に機能しています。

接続エラーとクラスタリング・フェイルオーバー

Microsoft Internet Information Serverプラグインは、WebLogic Serverに接続しようとする際に、複数の構成パラメータを使用してWebLogic Serverホストへの接続の待機時間と、接続確立後のレスポンスの待機時間を決定します。接続できないか、またはレスポンスがない場合、プラグインはクラスタ内の別のWebLogic Serverに接続してリクエストを送信しようとします。接続が失敗するか、またはクラスタ内のいずれのWebLogic Serverインスタンスからもレスポンスがない場合は、エラー・メッセージが送信されます。

図4-15は、プラグインがどのようにフェイルオーバーを処理するのかを示しています。

図4-15 接続のフェイルオーバー

「図4-15 接続フェイルオーバー」の説明

接続失敗の考えられる原因

WebLogic Serverホストが接続リクエストに応答できない場合は、ホスト・マシンやネットワークに問題があるか、またはサーバーに障害があることが考えられます。

クラスタ内のいずれかのWebLogic Serverインスタンスが応答できない場合は、WebLogic Serverが動作していないか利用できない、またはサーバーのハングやデータベースの問題、アプリケーションに障害があるなどの原因が考えられます。

クラスタリングされていない単一のWebLogic Serverでのフェイルオーバー

WebLogic Serverが1つのみ動作している場合、プラグインはWebLogicHostパラメータで定義されているサーバーのみに接続しようとします。その試行が失敗すると、HTTP 503エラー・メッセージが戻されます。プラグインは、ConnectTimeoutSecsおよびConnectRetrySecsパラメータによって規定されたとおりに、WebLogic Serverインスタンスへの接続を試行し続けます。

動的サーバー・リスト

クラスタリングされたバックエンド・サーバーのリストにプロキシするため、またはクラスタリングされていない管理対象サーバー・インスタンスのロード・バランシングを実行するため、WebLogicClusterパラメータが必要です。

クラスタリングされた管理対象サーバーにプロキシする場合、httpd.confまたはweblogic.confファイルでWebLogicClusterパラメータを使用してWebLogic Serverのリストを指定すると、プラグインはクラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つに転送された後に、クラスタ内のサーバーの更新されたリストを格納する動的サーバー・リストが戻されます。更新されたリストでは、クラスタ内の新しいサーバーが追加され、クラスタを離脱したサーバーやリクエストに応答できなかったサーバーは削除されます。このリストは、クラスタ内で変化が発生したときにHTTPレスポンスによって自動的に更新されます。

フェイルオーバー、CookieおよびHTTPセッション

リクエストが、CookieやPOSTデータに格納されているかURLにエンコードされたセッション情報を含む場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼びます)への参照が含まれています。Cookieを含むリクエストは、プライマリ・サーバーに接続しようとします。その試行が失敗すると、プラグインはラウンド・ロビン方式でリストの次の使用可能なサーバーに接続しようとします。そのサーバーは元のセカンダリ・サーバーからセッションを取得し、その同じセッションのプライマリ・サーバーになります。詳細は、図4-15を参照してください。

注意:
POSTデータが64Kを超える場合、プラグインは、セッションIDを取得するためのPOSTデータの解析を行いません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリまたはセカンダリ・サーバーにルーティングできないので、セッション・データが失われるおそれがあります。

5 Sun Java System Web Serverプラグインのインストールと構成

この章では、Sun Java System Web Serverプラグインをインストールおよび構成する方法について説明します。

WebLogic Serverの以前のリリースでは、このプラグインはNetscape Enterprise Serverプラグインと呼ばれていました。この章のファイル仕様書への参照では、Netscape Enterprise Serverの名称を使用し続けています。

次の項では、Sun Java System Web Serverプロキシ・プラグインをインストールおよび構成する方法を説明します。

- Sun Java System Web Serverプラグインの概要

- Sun Java System Web Serverプラグインのインストールと構成

- 境界認証の設定

- Sun Java System Web ServerプラグインでのSSLの使用

- 接続エラーとクラスタリング・フェイルオーバー

Sun Java System Web Serverプラグインの概要

プラグインを使用すると、Sun Java System Web ServerからWebLogic Serverにリクエストをプロキシできます。このプラグインは、WebLogic Serverの動的な機能を必要とするリクエストをWebLogic Serverが処理できるようにすることによってSun Java System Web Serverのインストールを拡張します。

Sun Java System Web ServerプラグインはSun Java System Web Serverが静的ページを提供し、(おそらく別のマシンの別のプロセスで動作している) Weblogic ServerのインスタンスがJSPやHTTPサーブレットで生成されたページなどの動的ページを提供するように委任された環境で使用するためのものです。WebLogic ServerとSun Java System Web Serverプラグインは、クリア・テキストまたはSecure Sockets Layer (SSL)を使用して接続されます。エンド・ユーザー、つまりブラウザには、WebLogic Serverに委任されたHTTPリクエストが静的ページと同じ場所から送信されてきたように見えます。また、WebLogic ServerのHTTPトンネリング機能もSun Java System Web Serverプラグインを介して動作すると、動的ページのみでなく、すべてのWebLogic Serverサービスへのアクセスを提供できます。

Sun Java System Web Serverプラグインは、Sun Java System Web Serverでモジュールとして動作します。モジュールは起動時にロードされ、その後特定のHTTPリクエストがモジュールに委任されます。このモジュールはHTTP(Java)サーブレットと似ていますが、モジュールはプラットフォームにネイティブなコードで記述されている点で異なります。

Sun Java System Web Serverのサポート対象のバージョンの詳細は、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlを参照してください。

接続プールとキープアライブ

WebLogic Server Sun Java System Web Serverプラグインは、プラグインからWebLogic Serverへの再利用可能なプールの接続を使用して効率的なパフォーマンスを提供します。プラグインは、プラグインとWebLogic Server間の「キープアライブ」接続を自動的に実装します。接続が30秒またはユーザー定義の時間を超えて非アクティブな状態の場合、その接続は閉じられます。この機能は、必要に応じて無効にすることができます。詳細は、表7-1のKeepAliveEnabledを参照してください。

リクエストのプロキシ

プラグインは、ユーザーが指定する構成に基づいてリクエストをWebLogic Serverにプロキシします。リクエストは、リクエストのURL(またはURLの一部)に基づいてプロキシできます。これを、パスによるプロキシと呼びます。リクエスト対象のファイルのMIMEタイプに基づいてリクエストをプロキシすることもできます。また、これらの2つの方法を組み合せて使用することも可能です。リクエストが両方の基準に一致する場合、そのリクエストはパスによりプロキシされます。これらのリクエストの種類ごとに、プラグインの追加の動作を定義する追加パラメータを指定することもできます。詳細は、『Sun Java System Web Serverプラグインのインストールと構成』を参照してください。

注意:
Sun Java System Web Server 7.0アップデート2リリースでは、リクエストの処理方法が変更されました。詳細は、http://wikis.sun.com/display/WebServerdocs/Release+Notesの問題ID6747123を参照してください。

Sun Java System Web Serverプラグインのインストールと構成

Sun Java System Web Serverプラグインをインストールして構成するには:

1. ライブラリをコピーします。
WebLogic Sun Java System Web Serverプラグイン・モジュールは、UNIXプラットフォームでは共有オブジェクト(.so)として、Windowsではダイナミック・リンク・ライブラリ(.dll)として配布されます。これらのファイルは、WebLogic Server配布のWL_HOME/server/plugin/OperatingSystem/Architectureディレクトリに配置されています。WL_HOMEは、WebLogicプラットフォームの最上位ディレクトリを表しています。serverディレクトリには、WebLogic Serverのインストール・ファイルが格納されます。OperatingSystemは、UNIX、Windowsなどのオペレーティング・システムを表します。

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlに基づいて使用している環境に適合するライブラリ・ファイルを選択し、Sun Java System Web Serverが配置されているファイル・システムにコピーします。

Sun Java System Web Server 7.0はxxx_61というプラグインが使用可能です。たとえば、libproxy128_61.soおよびlibproxy_61.soが使用可能です。

2. 「obj.confファイル修正のガイドライン」をお読みのうえ、次の手順に従ってobj.confファイルを修正します。obj.confファイルでは、WebLogic Serverにプロキシされるリクエストや他の構成情報を定義します。

3. obj.confを検索して開きます。
使用しているインスタンスのobj.confファイルは次の場所にあります。

NETSCAPE_HOME/https-INSTANCE_NAME/config/obj.conf

NETSCAPE_HOMEは、インストールのルート・ディレクトリで、INSTANCE_NAMEは特定の「インスタンス」、または使用しているサーバー構成です。たとえば、myunixmachineというUNIXマシンでは、obj.confファイルは次の場所で見つかります。

/usr/local/netscape/enterprise-351/ https-myunixmachine/config/obj.conf

4. ネイティブ・ライブラリ(.soまたは.dllファイル)をモジュールとしてロードするようにSun Java System Web Serverに指示します。
4.x以前のiPlanetを使用する場合は、次の行をobj.confファイルの先頭に追加します。

Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/SHARED_LIBRARY
Init fn="wl_init"

SHARED_LIBRARYは、「Sun Java System Web Serverプラグインのインストールと構成」のステップ1でインストールした共有オブジェクトまたはdll(libproxy.soなど)です。load-modules関数は、Sun Java System Web Server起動時に共有ライブラリにロード用のタグを付けます。wl_proxyとwl_initの値は、Sun Java System Web Serverプラグインが実行する関数を識別します。

Planet 6.0を使用するには、次の行をmagnus.confファイルの先頭に追加します。これらの行は、ネイティブ・ライブラリ(.soまたは.dllファイル)をモジュールとしてロードするようにSun Java System Web Serverに指示します。

注意:
スペースの入力が重要です。"と\の間に、またはshlibの前にスペースを入力する必要があります。

Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/SHARED_LIBRARY
Init fn="wl_init"

SHARED_LIBRARYは、「Sun Java System Web Serverプラグインのインストールと構成」のステップ1でインストールした共有オブジェクトまたはdll(libproxy.soなど)です。load-modules関数は、Sun Java System Web Server起動時に共有ライブラリにロード用のタグを付けます。wl_proxyとwl_initの値は、Sun Java System Web Serverプラグインが実行する関数を識別します。

5. リクエストをURLによってプロキシする(「パスによってプロキシする」とも言います)には、プロキシするURLごとに別々の<Object>タグを作成し、PathTrimパラメータを定義します。(パスによるプロキシに加えて、またはそのかわりに、MIMEタイプによってリクエストをプロキシできます。ステップ6の「パスによるプロキシはMIMEタイプによるプロキシに優先します」を参照してください。)文字列*/weblogic/*が含まれるリクエストをプロキシする<Object>タグの例を次に示します。

<Object name="weblogic" ppath="*/weblogic/*">
Service fn=wl_proxy WebLogicHost=myserver.com\
WebLogicPort=7001 PathTrim="/weblogic"
</Object>

<Object>タグを作成してURLでリクエストをプロキシするには:

1. name属性を使用して最初の<Object>タグの内部でこのオブジェクトの名前を指定します(オプション)。name属性は参照用であり、Sun Java System Web Serverプラグインでは使用されません。例:

<Object name=myObject ...>

2. ppath属性を使用してプロキシ対象のURLを<Object>タグ内部で指定します。例:

<Object name=myObject ppath="*/weblogic/*>

ppath属性の値は、Weblogic Server向けのリクエストを識別する任意の文字列です。ppathを使用すると、そのパスの含まれるすべてのリクエストがリダイレクトされます。たとえば、ppathの値が*/weblogic/*の場合は、http://enterprise.com/weblogicで始まるすべてのリクエストがSun Java System Web Serverプラグインにリダイレクトされます。Sun Java System Web Serverプラグインは、そのリクエストを指定されたWebLogicホストまたはクラスタに送信します。

3. <Object>タグと</Object>タグの中にServiceディレクティブを追加します。Serviceディレクティブでは、名前=値ペアとして有効なパラメータを指定できます。名前=値ペアが複数の場合は、単一のスペースで区切ります。例:

Service fn=wl_proxy WebLogicHost=myserver.com\ WebLogicPort=7001 PathTrim="/weblogic"

パラメータの完全なリストは、「Webサーバー・プラグインの一般的なパラメータ」を参照してください。次のパラメータを指定する必要があります。

クラスタリングされていないWebLogic Serverの場合: WebLogicHostおよびWebLogicPortパラメータ。

WebLogic Serverインスタンスのクラスタの場合: WebLogicClusterパラメータ。

Serviceディレクティブは常にService fn=wl_proxyで開始し、その後にパラメータの名前=値ペアを続けます。

2つの独立したppathのオブジェクト定義の例を次に示します。各ppathは、WebLogic Serverの別々のインスタンスに送信されるリクエストを示します。

<Object name="weblogic" ppath="*/weblogic/*">
Service fn=wl_proxy WebLogicHost=myserver.com\
WebLogicPort=7001 PathTrim="/weblogic"
</Object>
<Object name="si" ppath="*/servletimages/*">
Service fn=wl_proxy WebLogicHost=otherserver.com\
WebLogicPort=7008
</Object>

注意:
PathTrimなどの必須でないパラメータを使用すると、Sun Java System Web Serverプラグインを介してppathを渡す方法を、より詳細に構成できます。プラグイン・パラメータの完全なリストは「Webサーバー・プラグインの一般的なパラメータ」を参照してください。

6. MIMEタイプによってリクエストをプロキシする場合は、obj.confファイルで参照されるすべての新しいMIMEタイプをMIME.typesファイルに追加します。MIMEタイプを追加するには、Netscapeサーバー・コンソールを使用するか、直接MIME.typesファイルを編集します。
直接MIME.typesファイルを編集するには、編集するファイルを開き、次の行を入力します。

type=text/jsp        exts=jsp

注意:
Netscape Enterprise Server 4.0 (iPlanet)の場合、JSPのMIMEタイプを追加するのではなく、既存のMIMEタイプをmagnus-internal/jspからtext/jspに変更します。

Netscapeコンソールを使用するには、「プリファレンスの管理」 > 「MIMEタイプ」を選択して追加または編集します。

7. 指定したMIMEタイプの拡張子(.jspなど)を持つリクエストをすべて、URLに関係なくWebLogic Serverにプロキシできます。特定のファイル・タイプのすべてのリクエストをWebLogic Serverにプロキシするには:

1. Serviceディレクティブを既存のデフォルト・オブジェクトの定義に追加します。(<Object name=default ...>)
たとえば、すべてのJSPをWebLogic Serverにプロキシするには、次のServiceディレクティブを、次で始まる最後の行の後に追加します。

NameTrans fn=....

かつ、次で始まる行の前:

PathCheck.
Service method="(GET|HEAD|POST|PUT)" type=text/jsp fn=wl_proxy\
WebLogicHost=192.1.1.4 WebLogicPort=7001 PathPrepend=/jspfiles

このServiceディレクティブは、.jsp拡張子を持つすべてのファイルを、指定されたWebLogic Serverにプロキシし、ファイルは次のようなURLで提供されます。

http://WebLogic:7001/jspfiles/myfile.jsp

PathPrependパラメータの値はリクエストがプロキシされるクラスタまたはWebLogic ServerでデプロイされるWebアプリケーションのコンテキスト・ルートと一致する必要があります。

Sun Java System Web Serverプラグインのエントリを追加した後、デフォルトのObject定義は次の例のようになります。

<Object name=default>
NameTrans fn=pfx2dir from=/ns-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn=pfx2dir from=/mc-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn="pfx2dir" from="/help" dir=\
"c:/Netscape/SuiteSpot/manual/https/ug"
NameTrans fn=document-root root="c:/Netscape/SuiteSpot/docs"
Service method="(GET|HEAD|POST|PUT)" type=text/jsp\
fn=wl_proxy WebLogicHost=localhost WebLogicPort=7001\  PathPrepend=/jspfiles
PathCheck fn=nt-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.html,home.html"
If a required parameter is missing from the configuration, when the object is
invoked it issues an HTML error that notes the missing parameter from the configuration.
ObjectType fn=type-by-extension
ObjectType fn=force-type type=text/plain
Service method=(GET|HEAD) type=magnus-internal/imagemap\  fn=imagemap
Service method=(GET|HEAD) \
type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD) \
type=*~magnus-internal/* fn=send-file
AddLog fn=flex-log name="access"
</Object>

2. WebLogic Serverにプロキシする他のすべてのMIMEタイプに対してデフォルトのオブジェクト定義に同様のService文を追加します。

3. JSPのMIMEタイプでプロキシを構成するには、mime.typesファイルに次のエントリを追加します。

type=text/jsp exts=jsp

MIMEによるプロキシが正しく機能するには、Sun One Web ServerからのJAVAを無効にする必要があります - 無効にしないと、SUN Oneが*.jspで終わるすべてのリクエストを処理しようとし、$doc_rootにリソースが見つからないため404エラーを戻すことになります。

Sun One Web ServerからのJAVAを無効にするには、obj.confファイルのname="default"#NameTrans fn="ntrans-j2ee" name="j2ee"以降をコメント・アウトしてからWebサーバーを再起動します。

8. オプションとして、パスによってプロキシする場合は、HTTPトンネリングを有効にします。

1. weblogic.jarを使用していてt3プロトコルをトンネリングする場合は、次のオブジェクト定義をobj.confファイルに追加し、HTTPトンネリング・リクエストを処理させるWebLogic Serverホスト名とWebLogic Serverポート番号、またはWebLogicクラスタ名を置き換えてください。

<Object name="tunnel" ppath="*/HTTPClnt*">
Service fn=wl_proxy WebLogicHost=192.192.1.4\  WebLogicPort=7001
</Object>

2. WebLogic Serverシン・クライアントwlclient.jarで使用される一意のプロトコルのIIOPをトンネリングする場合は、次のオブジェクト定義をobj.confファイルに追加し、HTTPトンネリング・リクエストを処理させるWebLogic Serverホスト名とWebLogic Serverポート番号、またはWebLogicクラスタ名を置き換えてください。

<Object name="tunnel" ppath="*/iiop*">
Service fn=wl_proxy WebLogicHost=192.192.1.4\  WebLogicPort=7001
</Object>

9. Sun Java System Web Serverプラグインをデプロイしてテストします。

1. WebLogic Serverを起動します。

2. Sun Java System Web Serverを起動します。Sun Java System Web Serverがすでに起動している場合、再起動するか、コンソールから新しい設定を適用して、新しい設定を有効にします。

3. Sun Java System Web Serverプラグインをテストするには、ブラウザを開き、Sun Java System Web Serverに/weblogic/を付加したURLを設定して、デフォルトのWebアプリケーション用に定義されたデフォルトのWebLogic Server HTMLページ、ウェルカム・ファイルまたはデフォルトのサーブレットに移動するかどうかを確認します。

http://myenterprise.server.com/weblogic/

デフォルトのWebアプリケーションの作成方法は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。

obj.confファイル修正のガイドライン

Sun Java System Web Serverプラグインを使用するには、obj.confファイルにいくつかの変更を加える必要があります。これらの変更により、リクエストをWebLogic Serverにプロキシする方法を指定します。リクエストは、URLまたはMIMEタイプによってプロキシできます。それぞれの手順は、「Sun Java System Web Serverプラグインのインストールと構成」を参照してください。

Netscapeのobj.confファイルは、テキストの配置に関して非常に厳格です。問題が起こらないようにするため、obj.confファイルについて次に注意してください。

- 前後の余分なスペースを削除します。余分なスペースが存在すると、Netscapeサーバーが機能しなくなることがあります。

- 入力する文字が1行に収まらない場合は、行末にバックスラッシュ(\)を置いて次の行に入力を続けます。バックスラッシュを入力すると、1行目の末尾が次の行の先頭に直接付加されます。1行目の末尾と2行目の先頭の単語の間にスペースが必要な場合は、1行目の末尾(バックスラッシュの前)または2行目の先頭のいずれかに、スペースを1つだけ入力します。

- 属性が複数の行にまたがらないようにします。(たとえば、クラスタ内のすべてのサーバーは、WebLogicClusterの後に同じ行の中でリストする必要があります。)

obj.confファイルのサンプル(WebLogicクラスタを使用しない場合)

クラスタを使用しない場合にobj.confファイルに追加する行の例を次に示します。この例をテンプレートとして使用し、使用する環境およびサーバーに合わせて変更できます。#で始まる行はコメントです。

注意:
obj.confファイルでは、余分なスペースを挿入しないようにしてください。このサンプルをコピーして貼り付けると、余分なスペースが挿入され、ファイルを読み取るときに問題が発生することがあります。

Enterprise Server構成ファイルの完全なドキュメントは、Sun Java System Web Serverドキュメントで参照できます。

## ------------- BEGIN SAMPLE OBJ.CONF CONFIGURATION  ---------
# (no cluster)
# The following line locates the NES library for loading at
# startup, and identifies which functions within the library are
# NES functions.  Verify the path to the library (the value
# of the shlib=<...> parameter) and that the file is
# readable, or the server fails to start.
Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/libproxy.so
Init fn="wl_init"
# Configure which types of HTTP requests should be handled by the
# NES module (and, in turn, by WebLogic).  This is done
# with one or more "<Object>" tags as shown below.
# Here we configure the NES module to pass requests for
# "/weblogic" to a WebLogic Server listening at port 7001 on
# the host myweblogic.server.com.
<Object name="weblogic" ppath="*/weblogic/*">
Service fn=wl_proxy WebLogicHost=myweblogic.server.com\
WebLogicPort=7001 PathTrim="/weblogic"
</Object>
# Here we configure the plug-in so that requests that
# match "/servletimages/" is handled by the
# plug-in/WebLogic.
<Object name="si" ppath="*/servletimages/*">
Service fn=wl_proxy WebLogicHost=192.192.1.4 WebLogicPort=7001
</Object>
# This Object directive works by file extension rather than
# request path. To use this configuration, you must also add
# a line to the mime.types file:
#
# type=text/jsp             exts=jsp
#
# This configuration means that any file with the extension
# ".jsp" are proxied to WebLogic. Then you must add the
# Service line for this extension to the Object "default",
# which should already exist in your obj.conf file:
<Object name=default>
NameTrans fn=pfx2dir from=/ns-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn=pfx2dir from=/mc-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn="pfx2dir" from="/help" dir=\
"c:/Netscape/SuiteSpot/manual/https/ug"
NameTrans fn=document-root root="c:/Netscape/SuiteSpot/docs"
Service method="(GET|HEAD|POST|PUT)" type=text/jsp fn=wl_proxy\
WebLogicHost=localhost WebLogicPort=7001 PathPrepend=/jspfiles
PathCheck fn=nt-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.html,home.html"
ObjectType fn=type-by-extension
ObjectType fn=force-type type=text/plain
Service method=(GET|HEAD) type=magnus-internal/imagemap\  fn=imagemap
Service method=(GET|HEAD) \
type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
AddLog fn=flex-log name="access"
</Object>
# The following directive enables HTTP-tunneling of the
# WebLogic protocol through the NES plug-in.
<Object name="tunnel" ppath="*/HTTPClnt*">
Service fn=wl_proxy WebLogicHost=192.192.1.4 WebLogicPort=7001
</Object>
#
## ------------- END SAMPLE OBJ.CONF CONFIGURATION ---------

obj.confファイルのサンプル(WebLogicクラスタを使用する場合)

WebLogic Serverクラスタを使用する場合にobj.confファイルに追加する行の例を次に示します。この例をテンプレートとして使用し、使用する環境およびサーバーに合わせて変更できます。#で始まる行はコメントです。

注意:
obj.confでは、余分なスペースを挿入しないようにしてください。このサンプルをコピーして貼り付けると、余分なスペースが挿入され、ファイルを読み取るときに問題が発生することがあります。

詳細は、Netscapeから提供されるEnterprise Serverの構成ファイルのドキュメント全体を参照してください。

## ------------- BEGIN SAMPLE OBJ.CONF CONFIGURATION ---------
# (using a WebLogic Cluster)
#
# The following line locates the NES library for loading at
# startup, and identifies which functions within the library are
# NES functions.  Verify the path to the library (the value
# of the shlib=<...> parameter) and that the file is
# readable, or the server fails to start.
Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/libproxy.so
Init fn="wl_init"
# Configure which types of HTTP requests should be handled by the
# NES module (and, in turn, by WebLogic).  This is done
# with one or more "<Object>" tags as shown below.
# Here we configure the NES module to pass requests for
# "/weblogic" to a cluster of WebLogic Servers.
<Object name="weblogic" ppath="*/weblogic/*">
Service fn=wl_proxy \
WebLogicCluster="myweblogic.com:7001,yourweblogic.com:7001,\
theirweblogic.com:7001" PathTrim="/weblogic"
</Object>
# Here we configure the plug-in so that requests that
# match "/servletimages/" are handled by the
# plug-in/WebLogic.
<Object name="si" ppath="*/servletimages/*">
Service fn=wl_proxy \
WebLogicCluster="myweblogic.com:7001,yourweblogic.com:7001,\
theirweblogic.com:7001"
</Object>
# This Object directive works by file extension rather than
# request path. To use this configuration, you must also add
# a line to the mime.types file:
#
# type=text/jsp             exts=jsp
#
# This configuration means that any file with the extension
# ".jsp" is proxied to WebLogic. Then you must add the
# Service line for this extension to the Object "default",
# which should already exist in your obj.conf file:
<Object name=default>
NameTrans fn=pfx2dir from=/ns-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn=pfx2dir from=/mc-icons\
dir="c:/Netscape/SuiteSpot/ns-icons"
NameTrans fn="pfx2dir" from="/help" dir=\
"c:/Netscape/SuiteSpot/manual/https/ug"
NameTrans fn=document-root root="c:/Netscape/SuiteSpot/docs"
Service method="(GET|HEAD|POST|PUT)" type=text/jsp fn=wl_proxy\
WebLogicCluster="myweblogic.com:7001,yourweblogic.com:7001,\
theirweblogic.com:7001",PathPrepend=/jspfiles
PathCheck fn=nt-uri-clean
PathCheck fn="check-acl" acl="default"
PathCheck fn=find-pathinfo
PathCheck fn=find-index index-names="index.html,home.html"
ObjectType fn=type-by-extension
ObjectType fn=force-type type=text/plain
Service method=(GET|HEAD) type=magnus-internal/imagemap\  fn=imagemap
Service method=(GET|HEAD) \
type=magnus-internal/directory fn=index-common
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
AddLog fn=flex-log name="access"
</Object>
# The following directive enables HTTP-tunneling of the
# WebLogic protocol through the NES plug-in.
<Object name="tunnel" ppath="*/HTTPClnt*">
Service fn=wl_proxy WebLogicCluster="myweblogic.com:7001,\
yourweblogic.com:7001,theirweblogic.com:7001"
</Object>
#
## ------------- END SAMPLE OBJ.CONF CONFIGURATION ---------

境界認証の設定

Sun Java System Web Serverプラグインを介してアクセスされるWebLogic Serverアプリケーションを保護するには、境界認証を使用します。

WebLogic IDアサーション・プロバイダは、Sun Java System Web Serverプラグインを介してWebLogic Serverアプリケーションにアクセスするユーザーなど、WebLogic Serverアプリケーションにアクセスする外部システムのトークンを認証します。次の手順に従って、プラグインを保護するIDアサーション・プロバイダを作成します。

1. WebLogic ServerアプリケーションにカスタムIDアサーション・プロバイダを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムIDアサーション・プロバイダの開発方法に関する項を参照してください。

2. Certトークン・タイプをサポートするようにカスタムIDアサーション・プロバイダを構成し、これをアクティブなトークン・タイプにします。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項を参照してください。

3. Webアプリケーションのweb.xmlデプロイメント記述子ファイルでclientCertProxy属性を「True」に設定します。(クラスタを使用する場合、必要に応じて、管理コンソールの「クラスタ」--「構成」--「一般」タブで、クラスタ全体に対して「クライアント証明書プロキシの有効化」属性を「true」に設定します。)『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のcontext-paramを参照してください。

4. clientCertProxyを設定したら、接続フィルタを使用して、Sun Java System Web Serverプラグインが動作しているマシンからの接続のみをWebLogic Serverが受信するようにします。『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使用方法に関する項を参照してください。

5. プラグインとWebLogic Serverの間でSSLを使用するため、Webサーバー・プラグインは信頼性のある認証局ファイルを必要とします。Sun Microsystemのkeytoolユーティリティを使用して、WL_HOME/server/libにあるDemoTrust.jksキーストア・ファイルから信頼性のある認証局ファイルをエクスポートします。

1. たとえば、wlsdemocaファイルを抽出するには、次のコマンドを使用します。

keytool -export -file trustedcafile.der -keystore DemoTrust.jks -alias wlsdemoca

キーストアから別の信頼性のあるCAファイルを取得するには、別名を変更します。

キーストアの信頼されたCAファイルをすべて表示するには、次のコマンドを使用します。 keytool -list -keystore DemoTrust.jks

パスワードを要求されたら「Enter」を押します。

2. 認証局ファイルをpem形式に変換するには、java utils.der2pem trustedcafile.derを使用します。

IDアサーション・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。

Sun Java System Web ServerプラグインでのSSLの使用

Secure Sockets Layer (SSL)プロトコルを使用すると、Sun Java System Web ServerプラグインとWebLogic Serverの間の接続を保護できます。SSLプロトコルは、Sun Java System Web ServerプラグインとWebLogic Serverの間でやり取りするデータに機密性と整合性をもたらします。

Sun Java System Web Serverプラグインは、Sun Java System Web ServerプラグインとWebLogic Serverの間の接続の保護にSSLプロトコルが使用されるかどうかを決定する際に、(通常はブラウザによって)HTTPリクエストに指定されるトランスポート・プロトコル(httpまたはhttps)を使用しません。

Sun Java System Web ServerプラグインとWebLogic Serverの間でSSLプロトコルを使用するには:

1. SSL向けにWebLogic Serverを構成します。詳細は、「SSLの構成」を参照してください。

2. WebLogic ServerのSSLリスニング・ポートを構成します。詳細は、「SSLの構成」を参照してください。

3. obj.confファイルのServiceディレクティブのWebLogicPortパラメータを、ステップ2で構成したリスニング・ポートに設定します。

4. obj.confファイルのServiceディレクティブのSecureProxyパラメータをONに設定します。

5. obj.confファイルのServiceディレクティブに、SSL接続の情報を定義する追加パラメータを設定します。パラメータの完全なリストは、7-14ページの「Webサーバー・プラグインのSSLパラメータ」を参照してください。

接続エラーとクラスタリング・フェイルオーバー

Sun Java System Web Serverプラグインは、WebLogic Serverに接続しようとする際に、複数の構成パラメータを使用してWebLogic Serverホストへの接続の待機時間と、接続確立後のレスポンスの待機時間を決定します。接続できないか、またはレスポンスがない場合、プラグインはクラスタ内の別のWebLogic Serverに接続してリクエストを送信しようとします。接続が失敗するか、またはクラスタ内のいずれのWebLogic Serverからもレスポンスがない場合は、エラー・メッセージが送信されます。

図5-1は、プラグインがフェイルオーバーを処理する方法を示します。赤いループで許容される最大再試行回数は、ConnectTimeoutSecs ÷ ConnectRetrySecsの値に相当します。

図5-1 接続のフェイルオーバー

「図5-1 接続フェイルオーバー」の説明

接続失敗の考えられる原因

接続リクエストにWebLogic Serverホストが応答できない場合は、ホスト・マシンやネットワークに問題がある、または他のサーバーに障害があることが考えられます。

すべてのWebLogic Server インスタンスが応答できない場合は、WebLogic Serverが動作していないか利用できない、またはサーバーのハング、データベースの問題、アプリケーションに障害があるなどの原因が考えられます。

クラスタリングされていない単一のWebLogic Serverでのフェイルオーバー

単一のWebLogic Serverインスタンスを実行している場合、プラグインはWebLogicHostパラメータで定義されているサーバーに接続しようとします。その試行が失敗すると、HTTP 503エラー・メッセージが戻されます。プラグインは、ConnectTimeoutSecsを超えるまでWebLogic Serverへの接続を試行し続けます。

動的サーバー・リスト

クラスタリングされたバックエンド・サーバーのリストにプロキシするため、またはクラスタリングされていない管理対象サーバー・インスタンスのロード・バランシングを実行するため、WebLogicClusterパラメータが必要です。

クラスタリングされた管理対象サーバーにプロキシする場合、httpd.confまたはweblogic.confファイルでWebLogicClusterパラメータを使用してWebLogic Serverのリストを指定すると、プラグインはクラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つに転送された後に、クラスタ内のサーバーの更新されたリストを格納する動的サーバー・リストが戻されます。更新されたリストでは、クラスタ内の新しいサーバーが追加され、クラスタを離脱したサーバーやリクエストに応答できなかったサーバーは削除されます。このリストは、クラスタ内で変化が発生したときにHTTPレスポンスによって自動的に更新されます。

フェイルオーバー、CookieおよびHTTPセッション

リクエストが、CookieやPOSTデータに格納されているかURLにエンコードされたセッション情報を含む場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼びます)への参照が含まれています。Cookieを含むリクエストは、プライマリ・サーバーに接続しようとします。その試行が失敗すると、プラグインはラウンド・ロビン方式でリストの次の使用可能なサーバーに接続しようとします。そのサーバーは元のセカンダリ・サーバーからセッションを取得し、その同じセッションのプライマリ・サーバーになります。詳細は、図5-1を参照してください。

注意:
POSTデータが64Kを超える場合、プラグインは、セッションIDを取得するためのPOSTデータの解析を行いません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリまたはセカンダリ・サーバーにルーティングできないので、セッション・データが失われるおそれがあります。

ファイアウォールとロード・ディレクタを使用する場合のフェイルオーバーの動作

ほとんどの構成では、Sun Java System Web Serverプラグインはリクエストをクラスタのプライマリ・インスタンスに送信します。そのインスタンスが使用できない場合、リクエストはセカンダリ・インスタンスにフェイルオーバーされます。ただし、ファイアウォールとロード・ディレクタを組み合わせて使用する一部の構成では、WebLogic Serverのプライマリ・インスタンスが使用できない場合でも、いずれか1つのサーバー(ファイアウォールまたはロード・ディレクタ)がリクエストを受け入れて、正常な接続を戻すことができます。WebLogic Serverの使用できないプライマリ・インスタンスへのリクエストの送信が試行された後、リクエストは「接続リセット」としてプラグインに戻されます。

ファイアウォールの組合せを介して実行するリクエストは、(ロード・ディレクタの有無に関係なく)WebLogic Serverによって処理されます。つまり、接続リセットのレスポンスは、WebLogic Serverのセカンダリ・インスタンスにフェイルオーバーします。これらの構成では接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変であることが必要です。そうでない場合、トランザクションの重複処理が発生する可能性があります。

6 別のWebサーバーへのリクエストのプロキシ

次の項では、別のWebサーバーにHTTPリクエストをプロキシする方法について説明します。

- 別のWebサーバーへのリクエストのプロキシの概要

- セカンダリWebサーバーへのプロキシの設定

- プロキシ・サーブレットのデプロイメント記述子のサンプル

別のWebサーバーへのリクエストのプロキシの概要

WebLogic ServerをプライマリWebサーバーとして使用する場合、特定のリクエストをセカンダリWebサーバー(ApacheまたはMicrosoft Internet Information Serverなど)に引き渡す(プロキシする)ようにWebLogic Serverを構成する必要がある場合もあります。プロキシされるリクエストはすべて特定のURLにリダイレクトされます。別のマシンの別のWebサーバーにプロキシすることすらできます。着信リクエストのURLに基づいてリクエストをプロキシします。

HttpProxyServlet(配布キットの一部として提供)は、HTTPリクエストを取得し、プロキシURLにリダイレクトして、WebLogic Serverを介してそのレスポンスをクライアントのブラウザに送信します。HttpProxyServletを使用するには、Webアプリケーションでそれを構成して、リクエストをリダイレクトするWebLogic ServerにそのWebアプリケーションをデプロイします。

セカンダリWebサーバーへのプロキシの設定

セカンダリHTTPサーバーのプロキシを設定するには:

1. プロキシ・サーブレットをWebアプリケーション・デプロイメント記述子に登録します(例6-1「ProxyServletとともに使用するweb.xmlのサンプル」を参照)。Webアプリケーションは、リクエストに応答するサーバー・インスタンスのデフォルトWebアプリケーションである必要があります。プロキシ・サーブレットのクラス名は、weblogic.servlet.proxy.HttpProxyServletです。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。

2. <param-name>にredirectURLを指定し、<param-value>にプロキシされるリクエストのリダイレクト先サーバーのURLを指定して、ProxyServletの初期化パラメータを定義します。

3. ユーザー自身のID証明書とキーで双方向SSLを使用する場合は、必要に応じて次の<KeyStore>初期化パラメータを定義します。デプロイメント記述子に<KeyStore>が指定されていない場合、プロキシでは一方向SSLと見なされます。

- <KeyStore> - Webアプリケーションのキーストアの場所。

- <KeyStoreType> - キーストアのタイプ。定義されていない場合、デフォルトのタイプが使用されます。

- <PrivateKeyAlias> - 秘密鍵の別名。

- <KeyStorePasswordProperties> - Webアプリケーション内のプロパティ・ファイルで、キーストアおよび秘密鍵の別名にアクセスするための暗号化されたパスワードを定義します。このファイルは次のような内容を持ちます。

KeyStorePassword={3DES}i4+50LCKenQO8BBvlsXTrg\=\=
PrivateKeyPassword={3DES}a4TcG4mtVVBRKtZwH3p7yA\=\=

パスワードを暗号化するには、weblogic.security.Encryptコマンド・ライン・ユーティリティを使用する必要があります。Encryptユーティリティや、CertGenおよびder2pemユーティリティの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のOracle WebLogic Server Javaユーティリティの使用に関する項を参照してください。

4. ProxyServletを<url-pattern>にマップします。特に、プロキシするファイルの拡張子(*.jsp、*.htmlなど)をマップします。Webアプリケーション・デプロイメント記述子web.xmlで<servlet-mapping>要素を使用します。
<url-pattern>を「/」に設定した場合、WebLogic Serverによって解決できないリクエストはすべてリモート・サーバーにプロキシされます。ただし、拡張子が*.jsp、*.htm、および*.htmlのファイルをプロキシする場合、これらの拡張子もマップする必要があります。

5. 受信するリクエストをリダイレクトするWebLogic ServerインスタンスにWebアプリケーションをデプロイします。

プロキシ・サーブレットのデプロイメント記述子のサンプル

例6-1は、プロキシ・サーブレットを使用するためのWebアプリケーション・デプロイメント記述子のサンプルです。

例6-1 ProxyServletとともに使用するweb.xmlのサンプル

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.
//DTD Web Application 2.3//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">

<web-app>
<servlet>
<servlet-name>ProxyServlet</servlet-name>
<servlet-class>weblogic.servlet.proxy.HttpProxyServlet</servlet-class>
<init-param>
<param-name>redirectURL</param-name>
<param-value>server:port</param-value>
</init-param>
<init-param>
<param-name>KeyStore</param-name>
<param-value>/mykeystore</param-value>
</init-param>
<init-param>
<param-name>KeyStoreType</param-name>
<param-value>jks</param-value>
</init-param>
<init-param>
<param-name>PrivateKeyAlias</param-name>
<param-value>passalias</param-value>
</init-param>
<init-param>
<param-name>KeyStorePasswordProperties</param-name>
<param-value>mykeystore.properties</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>ProxyServlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>

7 Webサーバー・プラグインのパラメータ

次の項では、ApacheおよびMicrosoft IISのWebサーバー・プラグインを構成するために使用するパラメータを説明します。

- Webサーバー・プラグインの構成ファイルでのパラメータの入力

- Webサーバー・プラグインの一般的なパラメータ

- Webサーバー・プラグインのSSLパラメータ

Webサーバー・プラグインの構成ファイルでのパラメータの入力

各Webサーバー・プラグインのパラメータは、専用の構成ファイルに入力します。この構成ファイルは各Webサーバーで別々の名前を持ち、ファイルの形式にはそれぞれの規則があります。詳細は、各プラグインの次の項を参照してください。

- 第3章「Apache HTTP Serverプラグインのインストールと構成」

- 第4章「Microsoft IISプラグインのインストールと構成」

Webサーバー・プラグインの一般的なパラメータ

Webサーバー・プラグインの一般的なパラメータを表7-1に示します。パラメータでは大文字/小文字が区別されます。

表7-1 Webサーバー・プラグインの一般的なパラメータ

パラメータ名

デフォルト

説明

適用対象

WebLogicHost(単一の WebLogic Serverにプロキシする場合は必須。)

なし

HTTPリクエストを転送する必要があるWebLogic Serverホスト(またはWebLogic Serverで定義されたものと同じ仮想ホスト名)を示します。WebLogicクラスタを使用している場合、WebLogicHostのかわりにWebLogicClusterパラメータを使用します。

ISAPI、ApacheとNSAPIプラグイン、HttpClusterServletおよびHttpProxyServlet

WebLogicPort (単一のWebLogic Serverにプロキシする場合は必須。)

なし

プラグイン(または他のサーバー)からの接続リクエストをWebLogic Serverホストがリスニングするポート。(プラグインおよびWebLogic Serverの間にSSLを使用している場合、このパラメータにSSLのリスニング・ポートを設定し(「SSLの構成」を参照)、SecureProxyパラメータをONに設定します。)

WebLogic Clusterを使用している場合は、WebLogicPortのかわりにWebLogicClusterパラメータを使用します。

ISAPI、ApacheとNSAPIプラグイン、HttpClusterServletおよびHttpProxyServlet

WebLogicCluster

(WebLogic Serverのクラスタまたは複数の非クラスタ・サーバーにプロキシする場合は必須。)

なし

クラスタリングされたバックエンド・サーバーのリストにプロキシするため、またはクラスタリングされていない管理対象サーバー・インスタンスのロード・バランシングを実行するため、WebLogicClusterパラメータが必要です。

ロード・バランシングに使用できるWebLogic Serverのリスト。サーバーまたはクラスタのリストは、「ホスト:ポート」エントリのリストです。複数のクラスタと単一サーバーの組合せを指定すると、このパラメータに戻される動的リストは、クラスタリングされたサーバーのみを戻します。

パラメータの指定方法と必要な形式はプラグインによって異なります。次に含まれる例を参照してください。

- 第4章「Microsoft IISプラグインのインストールと構成」

- 第3章「Apache HTTP Serverプラグインのインストールと構成」

プラグインとWebLogic Serverの間にSSLを使用している場合は、ポート番号をSSLリスニング・ポートに設定して(「SSLの構成」を参照)、SecureProxyパラメータをONに設定します。

プラグインは、使用可能なサーバー間で単純なラウンド・ロビンを行います。このプロパティで指定するサーバー・リストは、サーバーおよびプラグインが保持する動的サーバー・リストの起点です。新しく追加されたり、障害が発生したり、障害から回復したクラスタ・メンバーがあると、WebLogic Serverとプラグインは連携して自動的にサーバー・リストを更新します。

動的クラスタ・リストを無効化するには、DynamicServerListパラメータをOFFに設定します。

プラグインは、Cookie、URLエンコードされたセッション、またはPOSTデータに格納されたセッションを含むHTTPリクエストを、最初にCookieを作成したクラスタ内のサーバーに転送します。

ISAPI、ApacheとNSAPIプラグインおよびHttpClusterServlet

PathTrim

null

RFC仕様に従ったURLの一般的な構文は次のとおりです。

[PROTOCOL]://[HOSTNAME]:{PORT}/{PATH}/{FILENAME};{PATH_PARAMS}/{QUERY_STRING}...

PathTrimは、リクエストがWebLogic Serverに転送される前に、元のURLの{PATH}/{FILENAME}の部分からプラグインによって取り除かれる文字列を指定します。たとえば、次のURL

http://myWeb.server.com/weblogic/foo

が解析のためにプラグインに渡され、URLがWebLogic Serverに渡される前にPathTrimが/weblogicを取り除くように設定されている場合、WebLogic Serverに転送されるURLは次になります。

http://myWeb.server.com:7001/foo

既存のサード・パーティ・サーバーを新しく変更し、プラグインを使用してWebLogic Serverにリクエストをプロキシする場合、/fooへのアプリケーション・パスを変更してweblogic/fooを含むようにする必要があります。PathTrimおよびPathPrependを組み合わせて使用すると、このパスを変更できます。

ISAPI、ApacheとNSAPIプラグイン、HttpClusterServletおよびHttpProxyServlet

PathPrepend

null

RFC仕様に従ったURLの一般的な構文は次のとおりです。

[PROTOCOL]://[HOSTNAME]:{PORT}/{PATH}/{FILENAME};{PATH_PARAMS}/{QUERY_STRING}...

PathPrependには、PathTrimの値が取り除かれた後、リクエストがWebLogic Serverに転送される前に、プラグインによって元のURLの{PATH}の部分の先頭に付加されるパスを指定します。

ファイル名を追加する必要がある場合は、PathPrependではなく、DefaultFileNameプラグイン・パラメータを使用する点に注意してください。

ISAPI、ApacheとNSAPIプラグイン、HttpClusterServletおよびHttpProxyServlet

ConnectTimeoutSecs

10

プラグインがWebLogic Serverホストへの接続を試行する最大時間(秒)。この値はConnectRetrySecsより大きくします。接続できないまま、何回か再試行(ConnectRetrySecsの項を参照)しても成功しないままConnectTimeoutSecsの期限が切れた場合、「HTTP 503/Service Unavailable」のレスポンスがクライアントに送られます。

エラー・レスポンスはErrorPageパラメータを使用してカスタマイズできます。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServlet

ConnectRetrySecs

2

WebLogic Serverホスト(またはクラスタ内のすべてのサーバー)への接続試行の間にプラグインがスリープする間隔(秒)。この値はConnectTimeoutSecsより小さくします。「HTTP 503/Service Unavailable」のレスポンスをクライアントに戻す前にプラグインが接続を試行する回数は、ConnectTimeoutSecsをConnectRetrySecsで除算することで算出されます。

再試行しないようにするには、ConnectRetrySecsをConnectTimeoutSecsと同じ値に設定します。ただし、プラグインは最低2回接続を試みます。

エラー・レスポンスはErrorPageパラメータを使用してカスタマイズできます。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServlet

Debug

OFF

デバッグ操作用に実行されるロギングのタイプを設定します。UNIXシステムの場合、デバッグ情報は/tmp/wlproxy.logファイルに書き込まれ、Windows NT/2000システムの場合は、c:\TEMP\wlproxy.logに書き込まれます。

WLLogFileパラメータを別のディレクトリとファイルに設定して、この場所とファイル名をオーバーライドします。(この場所を変更する他の方法については、「WLTempDir」パラメータを参照してください。)

サーバーにログインするユーザーに対してtmpまたはTEMPディレクトリへの書込み権限が割り当てられていることを確認してください。次のいずれかのロギング・オプションを設定します(HFC、HTW、HFWおよびHTCのオプションを組み合わせて、「HFC,HTW」のようにカンマで区切って設定することもできます)。

ON - プラグインは、情報メッセージおよびエラー・メッセージを記録します。

OFF - デバッグ情報は記録されません。

HFC - プラグインは、クライアントからのヘッダー、情報メッセージおよびエラー・メッセージを記録します。

HTW - プラグインは、WebLogic Serverに送信されたヘッダー、情報メッセージおよびエラー・メッセージを記録します。

HFW - プラグインは、WebLogic Serverから送信されたヘッダー、情報メッセージ、およびエラー・メッセージを記録します。

HTC - プラグインは、クライアントに送信されたヘッダー、情報メッセージおよびエラー・メッセージを記録します。

ERR - プラグインのエラー・メッセージのみを出力します。

ALL - プラグインは、クライアントに送信されたヘッダー、クライアントから送信されたヘッダー、WebLogic Serverに送信されたヘッダー、WebLogic Serverから送信されたヘッダー、情報メッセージおよびエラー・メッセージを記録します。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServletとHttpProxyServlet。

HttpClusterServletおよびHttpProxyServletの場合、可能な値はONとOFFのみです。

WLLogFile

Debugパラメータを参照

DebugパラメータがONに設定されている場合に生成されるログ・ファイルのパスとファイル名を指定します。このディレクトリはこのパラメータの設定前に作成する必要があります。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServletとHttpProxyServlet

WLDNSRefreshInterval

0 (起動時に1回のみルックアップ)

NSAPIおよびApacheにのみ適用されます。

プロキシ構成で定義する場合、WebLogic ServerがサーバーのDNS名からIPへのマッピングをリフレッシュする間隔を秒単位で指定します。WebLogic Serverインスタンスを別のIPアドレスに移行する場合に使用できますが、そのサーバーのIPのDNS名は変更されません。この場合、指定したリフレッシュ間隔でDNS<->IPのマッピングが更新されます。

NSAPIおよびApacheプラグイン

WLTempDir

Debugパラメータを参照

wlproxy.logを作成するディレクトリを指定します。場所が見つからない場合、Windowsの場合はC:/tempに、Unixの場合はすべてのプラットフォームで/tmpにログ・ファイルが作成されます。

POSTデータ・ファイルの_wl_proxyディレクトリの場所も指定します。

WLTempDirおよびWLLogFileの両方を設定した場合、wlproxy.logの場所についてはWLLogFileが優先します。_wl_proxyディレクトリの場所は、依然としてWLTempDirによって決まります。

NSAPI、ISAPIおよびApacheプラグイン

DebugConfigInfo

OFF

特殊な問合せパラメータ「__WebLogicBridgeConfig」を有効にします。このパラメータは、プラグインから構成パラメータに関する詳細を取得するために使用します。

たとえば、DebugConfigInfoを設定して「__WebLogicBridgeConfig」を有効にし、問合せ文字列「?__WebLogicBridgeConfig」を含むリクエストを送信すると、構成情報と実行時統計が収集され、その情報がブラウザに戻されます。この場合、プラグインはWebLogic Serverに接続しません。

このパラメータはデバッグにのみ使用するもので、出力メッセージの形式はリリースによって異なります。セキュリティのため、本番システムではこのパラメータをOFFにしてください。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServletとHttpProxyServlet

StatPath

(Microsoft Internet Information Serverプラグインでは利用できません)

false

trueに設定した場合、プラグインではリクエストをWebLogic Serverに転送する前に、リクエストの変換されたパス(Proxy-Path-Translated)の有無と権限がチェックされます。

ファイルが存在しない場合、「HTTP 404 File Not Found」のレスポンスがクライアントに戻されます。ファイルが存在しているが読み取れない場合は、「HTTP 403/Forbidden」のレスポンスがクライアントに戻されます。どちらの場合も、Webサーバーのデフォルトのメカニズムがこれらのレスポンスを処理します。このオプションは、WebLogic Server Webアプリケーションのドキュメント・ルートとWebサーバーのドキュメント・ルートが同じである場合に役立ちます。

エラー・レスポンスはErrorPageパラメータを使用してカスタマイズできます。

NSAPIおよびApacheプラグイン

ErrorPage

なし

WebサーバーがリクエストをWebLogic Serverに転送できなかった場合に表示されるユーザー独自のエラー・ページを作成できます。

ISAPI、ApacheおよびNSAPIプラグイン

WLSocketTimeoutSecs

2 (0より大きな値)

接続中のソケットのタイムアウトを秒単位で設定します。

WLIOTimeoutSecs (HungServerRecoverSecsの新しい名称)

300

WebLogic Serverからのリクエストへのレスポンスに対するプラグインの待機時間を定義します。プラグインは、サーバーがレスポンスするまでWLIOTimeoutSecsで指定した秒数だけ待機してから、サーバーのレスポンスなしを宣言して、次のサーバーにフェイルオーバーします。この値は、大きな値にしておく必要があります。サーブレットの処理時間より短くした場合は、予期しない結果が発生する場合があります。

最小値: 10

最大値: 制限なし

NSAPI、ISAPIおよびApacheプラグイン

Idempotent

ON

「ON」に設定されている状態で、サーバーが「WLIOTimeoutSecs」(HungServerRecoverSecsの新しい名称)の時間内に応答しない場合、プラグインはフェイルオーバーします。

Idempotentを「ON」に設定している場合も、プラグインはフェイルオーバーされ、サーバーがREAD_ERROR_FROM_SERVERなどのエラーを戻します。

「OFF」に設定した場合、プラグインはフェイルオーバーしません。Apache HTTP Serverを使用している場合は、複数のURLまたはMIMEタイプに対してこのパラメータを別々に設定できます。

ISAPI,、ApacheとNSAPIプラグインおよびHttpClusterServlet

WLCookieName

CookieNameパラメータは非推奨

JSESSIONID

WebLogic Server WebアプリケーションのWebLogic ServerセッションCookie名を変更する場合、プラグインの「WLCookieName」パラメータを同じ値に変更する必要があります。WebLogicセッションCookie名は、WebLogic固有のデプロイメント記述子の<session-descriptor>要素で設定されます。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServletとHttpProxyServlet

DefaultFileName

なし

URIが「/」の場合、プラグインは次の手順を実行します。

PathTrimパラメータで指定されたパスを取り除きます。

DefaultFileNameの値を末尾に付加します。

PathPrependで指定された値を先頭に付加します。

これによって、WebLogic Serverからリダイレクトされなくなります。

「DefaultFileName」は、リクエストがプロキシされるWebLogic ServerのWebアプリケーションのデフォルト・ウェルカム・ページに設定します。たとえば、DefaultFileNameをwelcome.htmlに設定した場合、HTTPリクエストが「http://somehost/weblogic」であれば、「http://somehost/weblogic/welcome.html」になります。このパラメータが機能するためには、リクエストが転送されるすべてのWebアプリケーションで同じウェルカム・ファイルを指定する必要があります。詳細は、「ウェルカム・ページの構成」を参照してください。

Apacheユーザーのための注意: StrongholdバージョンまたはRavenバージョンを使用する場合は、IfModuleブロックではなくLocationブロックでこのパラメータを定義します。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServletとHttpProxyServlet

MaxPostSize

-1

POSTデータの最大許容サイズ(バイト単位)。コンテキスト長がMaxPostSizeを超えた場合、プラグインによってエラー・メッセージが戻されます。-1に設定した場合、POSTデータのサイズはチェックされません。これは、POSTデータを使用してサーバーを過負荷状態にしようとするサービス拒否攻撃を防ぐために役立ちます。

ISAPI、ApacheとNSAPIプラグイン、HttpClusterServletおよびHttpProxyServlet

MatchExpression (Apache HTTP Serverのみ)

なし

MIMEタイプによるプロキシを行う場合、MatchExpressionパラメータを使用してIfModuleブロック内にファイル名のパターンを設定します。

MIMEタイプによるプロキシの場合の例:

<IfModule weblogic_module>
MatchExpression *.jsp
WebLogicHost=myHost|paramName=value
</IfModule>

パスによるプロキシの場合の例:

<IfModule weblogic_module>
MatchExpression /weblogic
WebLogicHost=myHost|paramName=value
</IfModule>

次の構文を使用して、MatchExpressionの新しいパラメータを定義することもできます。

MatchExpression *.jsp PathPrepend=/test PathTrim=/foo

Apacheプラグイン

FileCaching

ON

ONに設定すると、リクエストのPOSTデータのサイズが2048バイトより大きい場合、POSTデータはまずディスク上の一時ファイルに読み込まれ、次に8192バイトのチャンク単位でWebLogic Serverに転送されます。これにより、フェイルオーバーの間もPOSTデータが保持され、プライマリがダウンしても、必要なすべてのデータをセカンダリにコピーすることができます。

FileCachingがONになっていると、データがWebServerとWebLogicの間でまだ転送中であっても、POSTの進行状況を追跡するクライアントは転送が完了したものと認識することに注意してください。したがって、アップロード時にブラウザに進行状況バーを表示して、WebLogic Serverで実際にデータが使用可能になったタイミングを示す場合は、FileCachingをONにしないことも検討する必要があります。

OFFに設定すると、リクエストのPOSTデータのサイズが2048バイトより大きい場合、リクエストを処理するWebLogic Serverクラスタ・メンバーが特定されるまでPOSTデータの読込みが延期されます。その後、プラグインがPOSTデータを読み込み、ただちに8192バイトのチャンク単位でWebLogic Serverに送信します。

FileCachingをOFFにするとフェイルオーバーが制限されることに注意してください。リクエストの処理中にWebLogic Serverプライマリ・サーバーがダウンした場合、すでにプライマリに送信されたPOSTデータはセカンダリに複写できません。

なお、POSTデータのサイズが2048バイト以下の場合は、FileCachingの設定に関係なくプラグインがデータをメモリーに読み込み、フェイルオーバー時にセカンダリへの複写が必要であればこれを使用します。

ISAPI,、ApacheとNSAPIプラグインおよびHttpClusterServlet

FilterPriorityLevel

2

このパラメータの値は、0 (低)、1 (中)、2 (高)です。デフォルト値は2です。この優先順位は、iisforward.iniファイルに置かれる必要があります。このプロパティを使用して、IISのiisforward.dllフィルタの優先レベルが設定されます。受信リクエストが複数のフィルタに一致する場合に、IISは優先レベルに従って、最初に呼び出すフィルタを判別します。

ISAPIプラグイン

WLExcludePathOrMimeType

なし

このパラメータを使用すると、特定のリクエストをプロキシ処理から除外できます。

このパラメータは、Locationタグ・レベルでローカルに定義することも、グローバルに定義することもできます。このプロパティをローカルに定義した場合、グローバルなプロパティはオーバーライドされず、2つのパラメータの結合が定義されます。

NSAPI、ISAPIおよびApacheプラグイン

WlForwardPath

null

WlForwardPathが「/」に設定されている場合は、すべてのリクエストがプロキシされます。特定の文字列で始まるリクエストをプロキシするには、WlForwardPathをその文字列に設定します。たとえば、WlForwardPathを/weblogicに設定すると、/weblogicで始まるすべてのリクエストがWeblogic Serverに転送されます。

このパラメータは、パスによるプロキシを行う場合は必須です。カンマで文字列を区切ることにより、複数の文字列を設定できます。例: WlForwardPath=/weblogic,/bea

ISAPIプラグイン

KeepAliveSecs

20

プラグインとWebLogic Serverの間のアクティブではない接続が閉じられるまでの時間。このパラメータを有効にするには、KeepAliveEnabledをtrue (Apacheプラグインを使用している場合はON)に設定する必要があります。

このパラメータの値は、管理コンソールのサーバー/HTTPタブで設定される期間フィールドの値、またはKeepAliveSecs属性を使用してサーバーMBeanで設定される値以下である必要があります。

ISAPI、ApacheとNSAPIプラグイン、HttpClusterServletおよびHttpProxyServlet

KeepAliveEnabled

true (Microsoft IISプラグイン)

ON (Apacheプラグイン)

プラグインとWebLogic Serverの間の接続のプールを有効化します。

Microsoft IISプラグインの有効な値は、trueおよびfalseです。

Apacheプラグインの有効な値は、ONおよびOFFです。

ISAPI、ApacheとNSAPIプラグイン、HttpClusterServletおよびHttpProxyServlet

QueryFromRequest

(Apache HTTP Serverのみ)

OFF

ONに設定すると、Apacheプラグインは次を使用して、

(request_rec *)r->the request

問合せ文字列をWebLogic Serverに渡します。(詳細は、Apacheドキュメントを参照してください。)これは、次の場合に望ましい動作です。

- Netscapeバージョン4.xブラウザが問合せ文字列にスペースのあるリクエストを行う場合

- HPでRaven Apache 1.5.2を使用する場合

OFFに設定されている場合、Apacheプラグインは(request_rec *)r->argsを使用してWebLogic Serverに問合せ文字列を渡します。

Apacheプラグイン

MaxSkipTime

10

WebLogicClusterパラメータまたはWebLogic Serverから戻される動的クラスタ・リストにあるWebLogic Serverで障害が発生した場合、その障害の発生したサーバーは「bad」とマークされ、プラグインはリスト内の次のサーバーに接続しようとします。

MaxSkipsには、プラグインが「bad」とマークされたサーバーへの接続を再試行するまでの時間を設定します。プラグインは、固有のリクエスト(Cookieのないリクエスト)を受信するたびにリスト内の新しいサーバーに接続しようとします。

ISAPI,、ApacheとNSAPIプラグインおよびHttpClusterServlet

DynamicServerList

ON

OFFに設定すると、プラグインからプロキシされるリクエストをロード・バランシングするために使用される動的クラスタ・リストが無視され、WebLogicClusterパラメータで指定された静的リストのみが使用されます。通常、このパラメータはONのままにします。

このパラメータをOFFに設定すると、いくつかの影響があります。

- 静的リストの1つまたは複数のサーバーで障害が発生した場合、プラグインは応答不能のサーバーへの接続に時間を費やし、その結果としてパフォーマンスが低下する可能性があります。

- クラスタに新しいサーバーを追加した場合は、このパラメータを再定義するまでプラグインはその新しいサーバーにリクエストをプロキシできません。WebLogic Serverは、新しいサーバーがクラスタに追加されたときに動的サーバー・リストにその新しいサーバーを自動的に追加します。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServlet

WLProxySSL

OFF

次の条件に一致する場合、プラグインとWebLogic Server間のSSL通信を維持する場合は、このパラメータをONに設定します。

- HTTPクライアント・リクエストがHTTPSプロトコルを指定しています。

- リクエストが1つまたは複数のプロキシ・サーバー(WebLogic Serverプロキシ・プラグインを含む)を経由して渡されました。

- プラグインとWebLogic Server間の接続でHTTPプロトコルを使用しています。

WLProxySSLをONに設定すると、WebLogic Serverからクライアントに戻されるロケーション・ヘッダーではHTTPSプロトコルが指定されます。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServletとHttpProxyServlet

WLProxyPassThrough

OFF

プロキシ・プラグインまたはHttpClusterServletが一部の他のプロキシまたはロード・バランサで稼働中の連鎖プロキシ設定がある場合、WLProxyPassThroughパラメータを明示的に有効化する必要があります。このパラメータを有効化すると、ネットワークが信頼できるためユーザー証明書などが受渡し可能であると仮定して、プラグインはそのプロキシを信頼するようになります。

NSAPI、ISAPIとApacheプラグインおよびHttpClusterServletとHttpProxyServlet

WLLocalIP

なし

プラグインがマルチ・ホーム・マシンで動作しているWebLogic Serverインスタンスに接続する場合のバインド先の(プラグインのシステム上の)IPアドレスを定義します。

WLLocalIPを設定しない場合、マルチホーム・マシンで任意のIPアドレスが使用されます。

NSAPI、ISAPIおよびApacheプラグイン

WLSendHdrSeparately

ON

このパラメータをONに設定すると、ヘッダーおよびレスポンスの本文が別々のパケットで送信されます。

注意: ヘッダーとレスポンスの本文を2つのコールで送信する必要がある場合、たとえば、他のISAPIフィルタまたは本文の前にヘッダーがあることを期待するクライアントを持つ場合、このパラメータをONに設定します。

ISAPIプラグイン

POSTデータ・ファイルの場所

FileCachingパラメータをONに設定すると、リクエストのPOSTデータのサイズが2048バイトより大きい場合、POSTデータはまずディスク上の一時ファイルに読み込まれ、次に8192バイトのチャンク単位でWebLogic Serverに転送されます。これにより、フェイルオーバーの間もPOSTデータが保持されます。

UNIXでは、POSTファイルが/tmp/_wl_proxyにあります。Windowsでは、このファイルの場所は次にあります(WLTempDirを指定していない場合)。

1. 環境変数TMP

2. 環境変数TEMP

3. C:\Temp

/tmp/_wl_proxyは、HTTP Serverのユーザーが所有する固定ディレクトリです。様々なユーザーによってインストールされた複数のHTTP Serverが存在する場合、このディレクトリに書き込めないHTTP Serverが存在する場合があります。この状況により、次のようなエラーが発生します。

@
@
@ <HTML>
@ <HEAD>
@ <TITLE>Weblogic Bridge Message
@ </TITLE>
@ </HEAD>
@  <BODY>
@ <H2>Failure of server APACHE bridge:</H2><P>
@ <hr>Cannot open TEMP post file '/tmp/_wl_proxy/_post_25444_36' for POST of
@ 4564 bytes

この問題を解決するには、WLTempDirパラメータを使用して、POSTデータ・ファイルの_wl_proxyに対して別の場所を指定します。

Webサーバー・プラグインのSSLパラメータ

注意:
SCG証明書は、WebLogic Serverプロキシ・プラグインで使用できません。SCG以外の証明書は適切に機能し、その場合はWebLogic Serverとプラグインの間でSSL通信を行えます。
キーストア関連の初期化パラメータは、WebLogic Serverプロキシ・プラグインで使用できません。

Webサーバー・プラグインのSSLパラメータを表7-2に示します。パラメータでは大文字/小文字が区別されます。

表7-2 Webサーバー・プラグインのSSLパラメータ

パラメータ

デフォルト

説明

適用対象

EnforceBasicConstraint

Strong

このパラメータは、無効なV3 CA証明書が含まれている証明書チェーンが拒否されないSSL証明書検証に関して存在していたセキュリティ・ホールを修復します。このパラメータによって、有効なCA証明書をルートとし、無効な中間CA証明書を含む証明書チェーンが信頼性を持つことができました。X509 V3 CA証明書は、CAであり、かつクリティカルな拡張としてマークされているBasicConstraints拡張を含む必要があります。この確認は、中間CA証明書に見せかけた非CA証明書から保護します。

適用レベルは次のとおりです。

- OFF
このレベルは、適用を完全に無効にするので、お薦めしません。市販のCA証明書のほとんどは、デフォルト設定のSTRONGで動作します。

EnforceBasicConstraints=off

EnforceBasicConstraints=false

- STRONG
デフォルト値。V3 CA証明書に関するBasicConstraintsがチェックされ、証明書がCA証明書であるかどうかが検証されます。

EnforceBasicConstraints=strong

EnforceBasicConstraints=true

- STRICT
このレベルではSTRONGレベルと同じチェックが行われますが、それに加えて、CA証明書に関するBasicConstraintsが「クリティカル」としてマークされなければならないと規定するIETF RFC 2459が厳格に適用されます。これがデフォルト設定でないのは、市販のCA証明書の多くがRFC 2459に準拠しておらず、BasicConstraintsを「クリティカル」としてマークしていないためです。RFC 2459に厳格に準拠する場合は、これを設定します。

EnforceBasicConstraints=strict

NSAPI、ISAPIおよびApacheプラグイン

SecureProxy

OFF

このパラメータをONに設定すると、プラグインとWebLogic Server間のすべての通信でSSLプロトコルの使用が有効になります。このパラメータを定義する前に、対応するWebLogic ServerのポートをSSLプロトコル用に構成しておく必要があります。

このパラメータは、メイン・サーバー用の構成と仮想ホスト用の構成(仮想ホストが定義されている場合)の2つのレベルで設定できます。仮想ホスト用の構成でこの設定がオーバーライドされない場合、仮想ホスト用の構成はメイン・サーバー用の構成からSSLの構成を継承します。

ISAPI、NSAPIとApacheのプラグイン、HttpClusterServletおよびHttpProxyServlet

TrustedCAFile

なし

プラグインに対する信頼性のある認証局によるデジタル証明書が含まれるファイルの名前。SecureProxyパラメータがONに設定されている場合はこのパラメータが必須です。

ISAPI、NSAPIおよびApacheのプラグイン

RequireSSLHostMatch

true

プラグインが接続するホストの名前が、プロキシ・プラグインが接続するWebLogic Serverのデジタル証明書のサブジェクト識別名フィールドに一致する必要があるかどうかを指定します。

プラグインでSecureProxy=ONおよびRequireSSLHostMatch=trueを設定する場合、ListenAddressプロパティに指定する値を、証明書に指定したホスト名の値と一致させる必要があります。

WebLogic ServerのExternalDNSNameプロパティを使用し、プラグインでSecureProxy=ONおよびRequireSSLHostMatch=trueを設定する場合、ExternalDNSNameプロパティに指定する値を、証明書に指定したホスト名の値と厳密に一致させる必要があります。

ISAPI、NSAPIおよびApacheのプラグイン

SSLHostMatchOID

22

ホスト名の比較に使用されるピア・デジタル証明書内のサブジェクト識別名フィールドを示すASN.1 Object ID (OID)を指定します。このパラメータのデフォルト値は、サブジェクト識別名のCommonNameフィールドに対応します。一般的なOID値は次のとおりです。

- Sur Name-23

- Common Name-22

- Email-13

- Organizational Unit-30

- Organization-29

- Locality-26

ISAPI、NSAPIおよびApacheのプラグイン

KeyStore

なし

汎用プロキシ・サーブレットで双方向SSLを使用してユーザー定義のID証明書とキーを作成する際に指定するWebアプリケーションのキーストアの場所。

HttpClusterServletおよびHttpProxyServletのみに適用

KeyStoreType

なし

汎用プロキシ・サーブレットで双方向SSLを使用する際に指定するキーストアのタイプ。定義されていない場合、デフォルトのタイプが使用されます。

HttpClusterServletおよびHttpProxyServletのみに適用

PrivateKeyAlias

なし

汎用プロキシ・サーブレットで双方向SSLを使用する際に指定する秘密鍵の別名。

HttpClusterServletおよびHttpProxyServletのみに適用

KeyStorePasswordProperties

なし

Webアプリケーション内のプロパティ・ファイル。汎用プロキシ・サーブレットで双方向SSLを使用する際に、キーストアおよび秘密鍵の別名にアクセスするための暗号化されたパスワードを定義します。このファイルは次のような内容を持ちます。

KeyStorePassword={3DES}i4+50LCKenQO8BBvlsXTrg\=\=
PrivateKeyPassword={3DES}a4TcG4mtVVBRKtZwH3p7yA\=\=

パスワードを暗号化するには、weblogic.security.Encryptコマンド・ライン・ユーティリティを使用する必要があります。Encryptユーティリティや、CertGenおよびder2pemユーティリティの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のOracle WebLogic Server Javaユーティリティの使用に関する項を参照してください。

HttpClusterServletおよびHttpProxyServletのみに適用

Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved.