Netscape Enterprise Server (NES) プラグインのインストールとコンフィグレーション

検索

e-docs > WebLogic Server > WebLogic Server における Web サーバプラグインの使い方 > Netscape Enterprise Server (NES) プラグインのインストールとコンフィグレーション

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

Netscape Enterprise Server (NES) プラグインのインストールとコンフィグレーション

以下の節では、Netscape Enterprise Server (NES) プロキシプラグインをインストールおよびコンフィグレーションする方法を説明します。

Netscape Enterprise Server プラグインの概要

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 に委託された HTTP リクエストが静的ページと同じ場所から送られてきたように見えます。また、WebLogic Server の HTTP トンネリング機能も Netscape Enterprise Server プラグインを介して動作するため、動的ページだけでなく、すべての WebLogic Server サービスへのアクセスを提供できます。

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

Netscape Enterprise Server および iPlanet サーバのサポート対象のバージョンについては、http://edocs.beasys.co.jp/e-docs/wls/certifications/certifications/index.html の「動作確認状況」ページを参照してください。

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

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

リクエストのプロキシ

このプラグインは、指定されたコンフィグレーションに基づいてリクエストを WebLogic Server にプロキシします。リクエストは、リクエストの URL (または URL の一部) に基づいてプロキシできます。この方法は、パスに基づくプロキシです。要求されたファイルの MIME タイプに基づいてプロキシすることもできます。あるいは、前述の方法を組み合わせて利用することもできます。リクエストが両方の基準に一致する場合、そのリクエストはパスを基準にプロキシされます。リクエストの種類ごとに、プラグインの補足的な動作を定義する追加パラメータを指定することもできます。詳細については、Netscape Enterprise Server プラグインのインストールとコンフィグレーションを参照してください。

動作確認

Netscape Enterprise Server プラグインは、Linux、Solaris、AIX、および Windows の各プラットフォームでサポートされています。プラグインはすべてのリリースのすべてのオペレーティングシステムでサポートされているわけではありません。 Netscape Enterprise Server プラグインの特定のバージョンのプラットフォームサポートについては、「WebLogic Platform サポート対象のコンフィグレーション」を参照してください。

Netscape Enterprise Server プラグインのインストールとコンフィグレーション

Netscape Enterprise Server プラグインをインストールしてコンフィグレーションするには、次の手順を行います。

ライブラリをコピーします。
WebLogic Server NES プラグインモジュールは、UNIX プラットフォームでは共有オブジェクト (.so) として、Windows ではダイナミックリンクライブラリ (.dll) として配布されます。それらのファイルは、WebLogic Server 配布キットの WL_HOME/server/lib ディレクトリまたは WL_HOME/server/bin ディレクトリに配置されています。 WL_HOME は、WebLogic プラットフォームの最上位ディレクトリを表しています。モジュールは次のとおりです。
- Linux: lib/linux/i686/libproxy.so
- AIX: lib/aix/libproxy4x.so or lib/aix/libproxy4x_128.so
- Solaris: lib/solaris/libproxy.so
- Windows: server/bin/proxy36.dll
obj.conf ファイル修正のガイドラインを読んでから、以下の手順に従って 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 プラグインが実行する関数を識別します。
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 属性は参照用であり、Netscape Enterprise Server プラグインでは使用されません。次に例を示します。
```
<Object name=myObject ...>
```
2. 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 ホストまたはクラスタに送信します。
3. <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 サーバプラグインの一般的なパラメータを参照してください。
MIME タイプを基準にリクエストをプロキシする場合は、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 Preferences｜Mime タイプ] を選択して追加または編集します。
指定した MIME タイプの拡張子 (.jsp など) を持つリクエストをすべて、URL に関係なく WebLogic Server にプロキシできます。特定のファイルタイプのすべてのリクエストを WebLogic Server にプロキシするには、次の操作を行います。
1. 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>
```
1. WebLogic Server にプロキシする他のすべての MIME タイプについて、デフォルトのオブジェクト定義に同様の Service 文を追加します。

パスを基準にプロキシする場合は、HTTP トンネリングを有効にします。
次のオブジェクト定義を 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>
```
NES プラグインで HTTP リクエストの WebDAV 拡張を受け付ける場合は、次の手順に従います。
1. magnus.conf を見つけて開きます。
  
  NES インスタンスの magnus.conf ファイルは次の場所にあります。
  
  NETSCAPE_HOME/https-INSTANCE_NAME/config/conf.conf
2. magnus.conf ファイルに次の行を追加して、プラグインが受け付ける WebDAV メソッドを指定します。
```
Init fn="register-http-method"
     methods="PROPFIND,COPY,PROPPATCH,MOVE,LOCK,UNLOCK,MKCOL,SEARCH"
```
  上記の行は、すべての WebDAV メソッドを受け付けるようにプラグインをコンフィグレーションする例を示しています。必要な場合は、限られた数のメソッドだけを指定できます。その場合、Netscape Enterprise Server は指定されたメソッドをプラグインに転送しますが、他のメソッドの場合は「501 Method Not Implemented」エラーを返します。
  
  詳細については、Sun Microsystem の Web サイトで「register-http-method」のドキュメントを参照してください。
3. obj.conf ファイルを開きます。
4. 適切なオブジェクトの check-acl 関数をコメントアウトして、WebDAV リクエストの認証を無効にしておきます。
```
#PathCheck fn="check-acl" acl="default"
```
  WebDAV リクエストの認証をどのように無効にするかについてはユーザに任されています。たとえば、デフォルトオブジェクトのこの行をコメントアウトすると、すべてのリクエストに対する認証が無効になります。その後で他のオブジェクト定義にコメントアウトされていない行を選択的に追加して、CGI プログラムやサーブレットなどに対する認証を有効にすることができます。 WebDAV リクエストに対する NES による認証は無効にしておきます。それにより、WebLogic Server が認証を実行します。
Netscape Enterprise Server プラグインをデプロイしてテストします。
1. WebLogic Server を起動します。
2. Netscape Enterprise Server を起動します。NES が既に動作している場合、再起動するか、コンソールから新しい設定を適用して、新しい設定を有効にします。
3. Netscape Enterprise Server プラグインをテストするには、ブラウザを開き、次の例のように Netscape Enterprise Server の URL + /weblogic/ を設定します。この設定では、デフォルト Web アプリケーションとして定義されている、デフォルトの WebLogic Server HTML ページ、ウェルカムファイル、またはデフォルトサーブレットが開くはずです。
  http://myenterprise.server.com/weblogic/
  
  デフォルト Web アプリケーションの作成方法については、../webapp/components.html の「eb アプリケーションコンポーネントのコンフィグレーション」を参照してください。

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

Netscape Enterprise Server プラグインを使用するには、NES の obj.conf ファイルをいくつかの点で修正する必要があります。その修正では、リクエストがどのように WebLogic Server にプロキシされるのかを指定します。リクエストは、URL または MIME タイプに基づいてプロキシできます。それぞれの手順については、Netscape Enterprise Server プラグインのインストールとコンフィグレーションを参照してください。

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

前後の余分なスペースは削除します。余分なスペースがあると、Netscape サーバが機能しなくなることがあります。
入力文字が 1 行でおさまらない場合、行末に「¥」を置いて次の行の入力を続けます。「¥」があると、最初の行の末尾が次の行頭に直接つながります。行末と次行の語の間に空白が必要な場合は、最初の行の行末 (「¥」の前) か次行の先頭にスペースを 1 文字分だけ入れます。
属性は複数の行にまたがらないようにします。たとえば、クラスタのすべてのサーバは WebLogicCluster の後に同じ行で列挙する必要があります。

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

次に示すのは、クラスタを使用しない場合に 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 コンフィグレーションのサンプル -------

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

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

注意: 単一の Web サーバから複数の WebLogic Server クラスタにプロキシする場合、各クラスタにはユニークな CookieName パラメータが必要です。また、それぞれの値はユニークな文字列で始める必要があります。

詳細については、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 コンフィグレーションのサンプル -------

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

セキュアソケットレイヤ (SSL) プロトコルを使用すると、Netscape Enterprise Server プラグインと WebLogic Server の間で接続を保護できます。SSL プロトコルは、Netscape Enterprise Server プラグインと WebLogic Server の間でやり取りされるデータに機密性と整合性をもたらします。

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

Netscape Enterprise Server プラグインと WebLogic Server の間で SSL プロトコルを使用するには、次の手順を行います。

SSL 向けに WebLogic Server をコンフィグレーションします。詳細については、「SSL プロトコルのコンフィグレーション」を参照してください。
WebLogic Server の SSL リスンポートをコンフィグレーションします。詳細については、「SL プロトコルのコンフィグレーション」を参照してください。
obj.conf ファイルの Service ディレクティブの WebLogicPort パラメータを、手順 2. でコンフィグレーションしたリスンポートに設定します。
obj.conf ファイルの Service ディレクティブの SecureProxy パラメータを ON に設定します。
obj.conf ファイルの Service ディレクティブで、SSL 接続の情報を定義する追加パラメータを設定します。パラメータの詳細なリストについては、Web サーバプラグインの SSL パラメータを参照してください。

WL-Proxy-Client-Cert ヘッダの信頼の指定

プラグインは WL-Proxy-Client-Cert ヘッダでユーザの ID 証明書をエンコードし、そのヘッダを WebLogic Server インスタンスに渡すことができます (「別の Web サーバへのリクエストのプロキシ」を参照)。 WebLogic Server インスタンスは、それがセキュアなソース (プラグイン) から来ているものと信頼し、ヘッダの証明書情報を使用してユーザを認証します。以前の WebLogic Server のデフォルト動作では、WL-Proxy-Client-Cert ヘッダを常に信頼していました。 WebLogic Server 6.1 SP2 からは、WL-Proxy-Client-Cert ヘッダの信頼を明示的に定義する必要があります。新しいパラメータ clientCertProxy を使用すると、証明書ヘッダを信頼するかどうか指定することができます。セキュリティの強化には、WebLogic Server へのすべての接続を制限する接続フィルタを使用します。そうすることで、プラグインが動作しているマシンからの接続のみを WebLogic Server で受け容れることができます。

clientCertProxy パラメータは、HTTPClusterServlet および Web アプリケーションに追加されています。

HTTPClusterServlet では、このパラメータを次のように web.xml ファイルに追加します。

<context-param>

        <param-name>clientCertProxy</param-name>

        <param-value>true</param-value>

</context-param>

Web アプリケーションでは、このパラメータを次のように web.xml ファイルに追加します。

ServletRequestImpl context-param

<context-param>

        <param-name>weblogic.httpd.clientCertProxy</param-name>

        <param-value>true</param-value>

</context-param>

このパラメータは、次のようにクラスタで使用することもできます。

<Cluster ClusterAddress="127.0.0.1" Name="MyCluster"

        ClientCertProxyHeader="true"/>

接続エラーとクラスタのフェイルオーバ

WebLogic Server に接続するときに、Netscape Enterprise Server プラグインは複数のコンフィグレーションパラメータを使用して WebLogic Server ホストへの接続の待ち時間と、接続確立後の応答の待ち時間を判断します。接続できないか、応答がない場合、このプラグインはクラスタ内の別の WebLogic Server に接続してリクエストを送信しようとします。接続が失敗するか、クラスタ内のどの WebLogic Server からも応答がない場合は、エラーメッセージが送信されます。

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

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

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

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

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

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

動的サーバリスト

WebLogicCluster パラメータで WebLogic Server のリストを指定すると、プラグインではクラスタメンバー間でのロードバランシングの起点としてそのリストが使用されます。最初のリクエストがそれらのサーバの 1 つに転送された後に、クラスタ内のサーバの更新されたリストを格納する動的サーバリストが返されます。更新されたリストはクラスタ内の新しいサーバを追加し、すでにクラスタから外れているか、リクエストに応答できなかったサーバを削除します。このリストは、クラスタで変更が行われたときに HTTP 応答によって自動的に更新されます。

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

リクエストがクッキー、POST データ、または URL エンコーディングを通じてセッション情報を格納している場合、そのセッション ID にはセッションが最初に確立された特定のサーバ (プライマリサーバ) への参照と元のセッションがレプリケートされる追加サーバ (セカンダリサーバ) への参照が含まれています。クッキーが含まれているリクエストは、プライマリサーバに接続しようとします。その試行が失敗すると、リクエストはセカンダリサーバに転送されます。プライマリサーバとセカンダリサーバが両方とも失敗すると、セッションが失われて、プラグインは動的クラスタリストの別のサーバにあらためて接続しようとします。詳細については、接続のフェイルオーバ図 4-1を参照してください。

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

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

*赤いループで許可される再試行の限度は、次の式で計算されます。
ConnectTimeoutSecs ÷ ConnectRetrySecs.

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

ほとんどのコンフィグレーションでは、Netscape Enterprise Server プラグインはリクエストをクラスタのプライマリインスタンスに送信します。そのインスタンスが利用できない場合、リクエストはセカンダリインスタンスにフェイルオーバされます。ただし、ファイアウォールとロードディレクタを組み合わせて使う一部のコンフィグレーションでは、WebLogic Server のプライマリインスタンスが利用できない場合でもどれか 1 つのサーバ (ファイアウォールまたはロードディレクタ) がリクエストを受け付けて、正常な接続を返すことができます。利用できない WebLogic Server のプライマリインスタンスに送信しようとしたリクエストは、プラグインに「connection reset」として返されます。

ファイアウォールの組合せで実行するリクエストは、ロードディレクタの有無に関係なく、WebLogic Server が処理します。つまり、connection reset という応答は、WebLogic Server のセカンダリインスタンスにフェイルオーバします。connection reset という応答がこれらのコンフィグレーションではフェイルオーバするため、サーブレットは多重呼び出し不変でなければなりません。それ以外の場合、トランザクションの重複処理になる可能性があります。