ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方
11gリリース1 (10.3.3)
B61008-01
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストヘ移動
製品
目次へ移動
目次

前
 
次
 

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から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-1KeepAliveEnabledを参照してください。

リクエストのプロキシ

プラグインは、ユーザーが指定する構成に基づいてリクエストを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システムWebサーバー・プラグインのインストールと構成

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_proxywl_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_proxywl_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. Iweblogic.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)を使用しません。

プラグインと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の説明が続きます
「図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のセカンダリ・インスタンスにフェイルオーバーします。これらの構成では接続リセットのレスポンスがフェイルオーバーするため、サーブレットは多重呼出し不変であることが必要です。そうでない場合、トランザクションの重複処理が発生する可能性があります。