|
以下の節では、Netscape Enterprise Server (NES) プロキシ プラグインをインストールおよびコンフィグレーションする方法を説明します。
Netscape Enterprise Server プラグインを使用すると、Netscape Enterprise Server (NES または iPlanet とも呼ばれる) から WebLogic Server にリクエストをプロキシできます。このプラグインは、WebLogic Server の動的な機能を必要とするリクエストを WebLogic Server が処理できるようにすることによって NES を拡張します。
Netscape Enterprise Server プラグインは、Netscape Enterprise Server が静的ページを提供し、別のプロセス (おそらく別のホスト) で動作している Weblogic Server インスタンスが動的ページ (JSP や HTTP サーブレットで生成されたページ) を提供する、という環境で使用するためのものです。WebLogic Server と Netscape Enterprise Server プラグインは、クリア テキストまたはセキュア ソケット レイヤ (SSL) を使用して接続されます。エンド ユーザ、つまりブラウザには、WebLogic Server に委託された HTTP リクエストが静的ページと同じ場所から送られてきたように見えます。また、WebLogic Server の HTTP トンネリング機能も Netscape Enterprise Server プラグインを介して動作するため、動的ページだけでなく、すべての WebLogic Server サービスへのアクセスを提供できます。
Netscape Enterprise Server プラグインは、Netscape Enterprise Server で NES モジュールとして動作します。NES モジュールは起動時に NES によってロードされ、特定の HTTP リクエストがそこに委託されます。NES は HTTP (Java) サーブレットと似ていますが、NES モジュールはプラットフォームにネイティブなコードで記述されています。
Netscape Enterprise Server および iPlanet サーバのサポート対象のバージョンについては、(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
) を参照してください。
WebLogic Server Netscape Enterprise Server プラグインは、プラグインから WebLogic Server への接続の再利用可能なプールを使用して効率的なパフォーマンスを提供します。NES プラグインは、プラグインと WebLogic Server 間の「キープアライブ」接続を自動的に実装します。接続が 30 秒 (またはユーザ定義の時間) を超えて非アクティブな場合、その接続は閉じます。この機能は、必要に応じて無効にできます。詳細については、「KeepAliveEnabled」を参照してください。
プラグインは指定されたコンフィグレーションに基づいてリクエストを WebLogic Server にプロキシします。リクエストは、リクエストの URL (または URL の一部) に基づいてプロキシできます。この方法は、パスに基づくプロキシです。要求されたファイルの MIME タイプに基づいてリクエストをプロキシすることもできます。また、両方の方法を組み合わせて使用することも可能です。リクエストが両方の基準に一致する場合、そのリクエストはパスに基づいてプロキシされます。これらのリクエストの種類ごとに、プラグインの補足的な動作を定義する追加パラメータを指定することもできます。詳細については、「Netscape Enterprise Server プラグインのインストールとコンフィグレーション」を参照してください。
Netscape Enterprise Server プラグインをインストールしてコンフィグレーションするには、次の手順を行います。
WebLogic NES プラグイン モジュールは、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
) から使用している環境に適合するライブラリ ファイルを選択し、NES が配置されているファイル システムにコピーします。
obj.conf
ファイルを修正します。obj.conf
ファイルでは、WebLogic Server にプロキシされるリクエストや他のコンフィグレーション情報を定義します。obj.conf
を見つけて開きます。
NES インスタンスの obj.conf
ファイルは次の位置にあります。
NETSCAPE_HOME
/https-
INSTANCE_NAME
/config/obj.conf
NETSCAPE_HOME
は NES がインストールされているルート ディレクトリで、INSTANCE_NAME
は特定の「インスタンス」、つまりユーザが使用しているサーバ コンフィグレーションです。たとえば、myunixmachine
という UNIX マシンでは、obj.conf
ファイルは次の位置で見つかります。
/usr/local/netscape/enterprise-351/
https-myunixmachine/config/obj.conf
.so
または .dll
ファイル) を NES モジュールとしてロードするように NES に指示します。
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
は、「Netscape Enterprise Server プラグインのインストールとコンフィグレーション」の手順 1 でインストールした共有オブジェクトまたは dll
(libproxy.so
など) です。関数「load-modules
」は、NES 起動時に共有ライブラリにロード用のタグをつけます。値「wl_proxy
」と「wl_init
」は、Netscape Enterprise Server プラグインが実行する関数を識別します。
iPlanet 6.0 を使用するには、以下の行を magnus.conf
ファイルの先頭に追加します。これらの行は、ネイティブ ライブラリ (.so
または .dll
ファイル) を NES モジュールとしてロードするように NES に指示します。
Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/SHARED_LIBRARY
Init fn="wl_init"
SHARED_LIBRARY
は、「Netscape Enterprise Server プラグインのインストールとコンフィグレーション」の手順 1 でインストールした共有オブジェクトまたは dll
(libproxy.so
など) です。関数「load-modules
」は、NES 起動時に共有ライブラリにロード用のタグをつけます。値「wl_proxy
」と「wl_init
」は、Netscape Enterprise Server プラグインが実行する関数を識別します。
<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 を基準にリクエストをプロキシするには、次の手順を行います。
name
属性を使用して最初の <Object>
タグの内側にこのオブジェクトの名前を指定します (省略可能)。name
属性は参照用であり、Netscape Enterprise Server プラグインでは使用されません。次に例を示します。<Object name=myObject ...>
ppath
属性を使用してプロキシ対象の URL を <Object>
タグ内部で指定します。次に例を示します。<Object name=myObject ppath="*/weblogic/*>
ppath
属性の値は、Weblogic Server に向けられたリクエストを識別する任意の文字列です。ppath
を使用すると、そのパスの含まれるすべてのリクエストがリダイレクトされます。たとえば、ppath
の値が「*/weblogic/*
」の場合は、「http://enterprise.com/weblogic
」で始まるすべてのリクエストが Netscape Enterprise Server プラグインにリダイレクトされます。Netscape Enterprise Server プラグインは、そのリクエストを指定された WebLogic ホストまたはクラスタに送信します。
<Object>
タグと </Object>
タグの中に Service
ディレクティブを追加します。Service
ディレクティブでは、名前と値のペアとして有効なパラメータを指定できます。名前と値のペアが複数の場合は、1 つのスペースで区切ります。次に例を示します。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 など) を使用すると、Netscape Enterprise Server プラグインを通じて ppath がどのように渡されるのかをさらに細かくコンフィグレーションできます。プラグイン パラメータの詳細なリストについては、「Web サーバ プラグインの一般的なパラメータ」を参照してください。 |
obj.conf
ファイルで参照される新しい MIME タイプをすべて MIME.types
ファイルに追加します。MIME タイプを追加するには、Netscape サーバ コンソールを使用するか、MIME.types
ファイルを直に編集します。
MIME.types
ファイルを直に編集するには、編集用にファイルを開き、次の行を入力します。
type=text/jsp exts=jsp
注意 : | NES 4.0 (iPlanet) の場合、JSP の MIME タイプを追加するのではなく、既存の MIME タイプを次のように変更する必要があります。 |
magnus-internal/jsp
text/jsp
Netscape コンソールを使用するには、[Manage PreferencesMime タイプ] を選択して追加または編集します。
.jsp
など) を持つリクエストをすべて、URL に関係なく WebLogic Server にプロキシできます。特定のファイル タイプのすべてのリクエストを WebLogic Server にプロキシするには、次の操作を行います。 Service
ディレクティブを既存の default
Object
定義に追加します。(<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 アプリケーションのコンテキスト ルートと一致していなければなりません。
Netscape Enterprise 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"
必須パラメータがコンフィグレーションで設定されていない場合は、オブジェクトを呼び出したときに 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>
Service
文を追加します。
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 サーバを再起動します。
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>
wlclient.jar
で使用される唯一のプロトコル) をトンネリングする場合は、次のオブジェクト定義を 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>
/weblogic/
を設定します。この設定では、デフォルト Web アプリケーションとして定義されている、デフォルトの WebLogic Server HTML ページ、ウェルカム ファイル、またはデフォルト サーブレットが開くはずです。
http://myenterprise.server.com/weblogic/
デフォルト Web アプリケーションの作成方法については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』を参照してください。
Netscape Enterprise Server プラグインを使用するには、NES の obj.conf
ファイルをいくつかの点で修正する必要があります。その修正では、リクエストがどのように WebLogic Server にプロキシされるのかを指定します。リクエストは、URL または MIME タイプに基づいてプロキシできます。それぞれの手順については、「Netscape Enterprise Server プラグインのインストールとコンフィグレーション」を参照してください。
Netscape の obj.conf
ファイルは、テキストの配置に関して非常に厳密です。問題が起こらないようにするには、obj.conf
ファイルについて以下の点に注意します。
次に示すのは、クラスタを使用しない場合に obj.conf
ファイルに追加する行の例です。この例をテンプレートとして使用し、ユーザの環境およびサーバに合うように変更できます。# で始まる行はコメントです。
注意 : | obj.conf ファイルでは、意味のないホワイト スペースを挿入しないようにしてください。このサンプルをコピーして貼り付けると、余分なホワイト スペースが挿入されて、ファイルを読み取るときに問題が生じることがあります。 |
Enterprise Server コンフィグレーション ファイルの詳細な説明は、Netscape Enterprise Server プラグインのマニュアルで参照できます。
## ------------- ここから OBJ.CONF コンフィグレーションのサンプル ---------
# (クラスタなし)
# 以下の行は、起動時にロードする NES ライブラリを
# 指定し、ライブラリ内のどの関数が NES 関数かを
# 示す。ライブラリへのパス (shlib=<...> パラメータの
# 値) とそのファイルが読み取り可能であることを確認する。
# 読み取り可能でない場合、サーバは起動に失敗する
Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/libproxy.so
Init fn="wl_init"
# NES モジュール (さらには WebLogic) で処理する
# HTTP リクエストの種類をコンフィグレーションする。これは
# 次の例のように 1 つまたは複数の「<Object>」タグで指定する
# ここでは、NES モジュールをコンフィグレーションして
# 「/weblogic」のリクエストを、ホスト myweblogic.server.com の
# ポート 7001 でリスンする WebLogic Server に渡す
<Object name="weblogic" ppath="*/weblogic/*">
Service fn=wl_proxy WebLogicHost=myweblogic.server.com\
WebLogicPort=7001 PathTrim="/weblogic"
</Object>
# ここでは、プラグインをコンフィグレーションして
# 「/servletimages/」に一致するリクエストが
# plug-in/WebLogic で処理されるようにする
<Object name="si" ppath="*/servletimages/*">
Service fn=wl_proxy WebLogicHost=192.192.1.4 WebLogicPort=7001
</Object>
# この Object ディレクティブは、リクエストのパスではなく
# ファイル拡張子で機能する。このコンフィグレーションを使用するには、
# 次の mime.types ファイルにも行を追加する必要がある
#
# type=text/jsp exts=jsp
#
# このコンフィグレーションでは、「.jsp」の拡張子が付いたファイルが
# WebLogic にプロキシ送信される。次に、
# この拡張子の Service 行を Object 定義「default」に追加する。
# この定義は obj.conf ファイルにすでに存在している必要がある
<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>
# 次のディレクティブは、NES プラグインを介して
# WebLogic プロコトルの HTTP トンネリングを有効にする
<Object name="tunnel" ppath="*/HTTPClnt*">
Service fn=wl_proxy WebLogicHost=192.192.1.4 WebLogicPort=7001
</Object>
#
## ------- ここまで OBJ.CONF コンフィグレーションのサンプル -------
次に示すのは、WebLogic Server クラスタを使用する場合に obj.conf
ファイルに追加する行の例です。この例をテンプレートとして使用し、ユーザの環境およびサーバに合うように変更できます。#
で始まる行はコメントです。
注意 : | obj.conf ファイルでは、意味のないホワイト スペースを挿入しないようにしてください。このサンプルをコピーして貼り付けると、余分なホワイト スペースが挿入されて、ファイルを読み取るときに問題が生じることがあります。 |
詳細については、Netscape から提供される Enterprise Server のコンフィグレーション ファイルに関するマニュアルを参照してください。
## ------------- ここから OBJ.CONF コンフィグレーションのサンプル ---------
# (WebLogic クラスタを使用)
#
# 以下の行は、起動時にロードする NES ライブラリを
# 指定し、ライブラリ内のどの関数が NES 関数かを
# 示す。ライブラリへのパス (shlib=<...> パラメータの
# 値) とそのファイルが読み取り可能であることを確認する。
# 読み取り可能でない場合、サーバは起動に失敗する
Init fn="load-modules" funcs="wl_proxy,wl_init"\
shlib=/usr/local/netscape/plugins/libproxy.so
Init fn="wl_init"
# NES モジュール (さらには WebLogic) で処理する
# HTTP リクエストの種類をコンフィグレーションする。これは
# 次の例のように 1 つまたは複数の「<Object>」タグで指定する
# ここでは、NES モジュールをコンフィグレーションして
# 「/weblogic」のリクエストを WebLogic Server のクラスタに渡す
<Object name="weblogic" ppath="*/weblogic/*">
Service fn=wl_proxy \
WebLogicCluster="myweblogic.com:7001,yourweblogic.com:7001,\
theirweblogic.com:7001" PathTrim="/weblogic"
</Object>
# ここでは、プラグインをコンフィグレーションして
# 「/servletimages/」に一致するリクエストが
# plug-in/WebLogic で処理されるようにする
<Object name="si" ppath="*/servletimages/*">
Service fn=wl_proxy \
WebLogicCluster="myweblogic.com:7001,yourweblogic.com:7001,\
theirweblogic.com:7001"
</Object>
# この Object ディレクティブは、リクエストのパスではなく
# ファイル拡張子で機能する。このコンフィグレーションを使用するには、
# 次の mime.types ファイルにも行を追加する必要がある
#
# type=text/jsp exts=jsp
#
# このコンフィグレーションでは、「.jsp」の拡張子が付いたファイルが
# WebLogic にプロキシ送信される。次に、
# この拡張子の Service 行を Object 定義「default」に追加する。
# この定義は obj.conf ファイルにすでに存在している必要がある
<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>
# 次のディレクティブは、NES プラグインを介して
# WebLogic プロコトルの HTTP トンネリングを有効にする
<Object name="tunnel" ppath="*/HTTPClnt*">
Service fn=wl_proxy WebLogicCluster="myweblogic.com:7001,\
yourweblogic.com:7001,theirweblogic.com:7001"
</Object>
#
## ------- ここまで OBJ.CONF コンフィグレーションのサンプル -------
Netscape Enterprise Server プラグインを介してアクセスされる WebLogic Server アプリケーションを保護するには、境界認証を使用します。
WebLogic ID アサーション プロバイダは、WebLogic Server アプリケーションにアクセスする外部システム (Netscape Enterprise Server プラグインを介して WebLogic Server アプリケーションにアクセスするユーザを含む) のトークンを認証します。次のように、プラグインを保護する ID アサーション プロバイダを作成します。
web.xml
デプロイメント記述子ファイルで clientCertProxy
属性を True に設定します。クラスタを使用する場合は、Administration Console の [クラスタ|コンフィグレーション|全般] タブで、クラスタ全体に対して [クライアント証明書プロキシを有効化
] 属性を True に設定することもできます。『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「context-param」を参照してください。clientCertProxy
を設定したら、接続フィルタを使用して、Netscape Enterprise Server プラグインが動作しているマシンからの接続のみを WebLogic Server が受け入れるようにします。『WebLogic Security プログラマーズ ガイド』の「ネットワーク接続フィルタの使い方」を参照してください。
キーストアから別の信頼性のある CA ファイルを取得するには、エリアス名を変更します。
キーストアの信頼された CA ファイルをすべて表示するには、次のコマンドを使用します。
keytool -list -keystore DemoTrust.jks
ID アサーション プロバイダの詳細については、『WebLogic Server セキュリティ プロバイダの開発』の「ID アサーション プロバイダ」を参照してください。
セキュア ソケット レイヤ (SSL) プロトコルを使用すると、Netscape Enterprise Server プラグインと WebLogic Server の間で接続を保護できます。SSL プロトコルは、Netscape Enterprise Server プラグインと WebLogic Server の間でやり取りされるデータに機密性と整合性をもたらします。
Netscape Enterprise Server プラグインは、SSL プロトコルを使用して Netscape Enterprise Server プラグインと WebLogic Server の間の接続が保護されるかどうかを、(通常はブラウザによって) HTTP リクエストで指定される転送プロトコル (http
または https
) では判断しません。
Netscape Enterprise Server プラグインと WebLogic Server の間で SSL プロトコルを使用するには、次の手順を行います。
obj.conf
ファイルの Service
ディレクティブの WebLogicPort
パラメータを、手順 2 でコンフィグレーションしたリスン ポートに設定します。obj.conf
ファイルの Service
ディレクティブの SecureProxy パラメータを ON
に設定します。obj.conf
ファイルの Service
ディレクティブで、SSL 接続の情報を定義する追加パラメータを設定します。パラメータの詳細なリストについては、「Web サーバ プラグインの SSL パラメータ」を参照してください。
WebLogic Server に接続するときに、Netscape Enterprise Server プラグインは複数のコンフィグレーション パラメータを使用して WebLogic Server ホストへの接続の待ち時間と、接続確立後の応答の待ち時間を判断します。接続できないか、応答がない場合、このプラグインはクラスタ内の別の WebLogic Server に接続してリクエストを送信しようとします。接続が失敗するか、クラスタ内のどの WebLogic Server からも応答がない場合は、エラー メッセージが送信されます。
図 5-1 は、プラグインがどのようにフェイルオーバを処理するのかを示しています。
接続要求に WebLogic Server ホストが応答できない場合は、ホスト マシンやネットワークに問題がある、またはサーバに障害があることが考えられます。
すべての WebLogic Server インスタンスが応答できない場合は、WebLogic Server が動作していないか利用できない、またはサーバのハング、データベースの問題、アプリケーションに障害があるなどの原因が考えられます。
WebLogic Server インスタンスが 1 つ動作している場合、プラグインは WebLogicHost パラメータで定義されているサーバに接続しようとします。その試行が失敗すると、HTTP 503
エラー メッセージが返されます。プラグインは、ConnectTimeoutSecs を超えるまで WebLogic Server への接続を試み続けます。
WebLogicCluster
パラメータで WebLogic Server のリストを指定すると、プラグインではクラスタ メンバー間でのロード バランシングの起点としてそのリストが使用されます。最初のリクエストがそれらのサーバの 1 つに転送された後に、クラスタ内のサーバの更新されたリストを格納する動的サーバ リストが返されます。更新されたリストではクラスタ内の新しいサーバが追加され、すでにクラスタから外れているか、リクエストに応答できなかったサーバが削除されます。このリストは、クラスタで変更が行われたときに HTTP 応答によって自動的に更新されます。
リクエストがクッキー、POST データ、または URL エンコーディングを通じてセッション情報を格納している場合、そのセッション ID にはセッションが最初に確立された特定のサーバ (プライマリ サーバ) への参照と元のセッションがレプリケートされる追加サーバ (セカンダリ サーバ) への参照が含まれています。クッキーが含まれているリクエストは、プライマリ サーバに接続しようとします。その試行が失敗すると、リクエストはセカンダリ サーバに転送されます。プライマリ サーバとセカンダリ サーバが両方とも失敗すると、セッションが失われて、プラグインは動的クラスタ リストの別のサーバにあらためて接続しようとします。詳細については、「図 5-1 接続のフェイルオーバ」を参照してください。
注意 : | POST データが 64K を超える場合、プラグインは、セッション ID を取得するための POST データの解析を行いません。したがって、セッション ID を POST データに格納した場合、プラグインはリクエストを正しいプライマリまたはセカンダリ サーバにルーティングできないので、セッション データが失われるおそれがあります。 |
ほとんどのコンフィグレーションでは、Netscape Enterprise Server プラグインはリクエストをクラスタのプライマリ インスタンスに送信します。そのインスタンスが利用できない場合、リクエストはセカンダリ インスタンスにフェイルオーバされます。ただし、ファイアウォールとロードディレクタを組み合わせて使う一部のコンフィグレーションでは、WebLogic Server のプライマリ インスタンスが利用できない場合でもどれか 1 つのサーバ (ファイアウォールまたはロードディレクタ) がリクエストを受け付けて、正常な接続を返すことができます。利用できない WebLogic Server のプライマリ インスタンスに送信しようとしたリクエストは、プラグインに「connection reset」として返されます。
ファイアウォールの組合せで実行するリクエストは、ロードディレクタの有無に関係なく、WebLogic Server が処理します。つまり、connection reset
という応答は、WebLogic Server のセカンダリ インスタンスにフェイルオーバします。connection reset
という応答がこれらのコンフィグレーションではフェイルオーバするため、サーブレットは多重呼び出し不変でなければなりません。それ以外の場合、トランザクションの重複処理になる可能性があります。