BEA ホーム | 製品 | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic Server > 管理者ガイド > WebLogic Server Web コンポーネントのコンフィグレーション |
管理者ガイド
|
WebLogic Server Web コンポーネントのコンフィグレーション
以下の節では、WebLogic Server Web コンポーネントをコンフィグレーションする方法について説明します。
WebLogic Server は、動的な Java ベース分散アプリケーションのホストとなる他にも、大容量 Web サイトを処理できる高機能 Web サーバとして、HTML ファイルや画像ファイルなどの静的ファイル、およびサーブレットと JavaServer Pages (JSP) を提供します。WebLogic Server は、HTTP 1.1 規格をサポートしています。
サーバまたは仮想ホストごとに、Administration Console を使用して HTTP 操作パラメータをコンフィグレーションできます。
各 WebLogic Server が HTTP リクエストをリスンするポートを指定できます。任意の有効なポート番号を指定できますが、ポート 80 を指定した場合、HTTP を介してリソースにアクセスするために使用する HTTP リクエストからポート番号を省略できます。たとえば、リスン ポートとしてポート 80 を定義した場合、http://hostname:portnumber/myfile.html ではなく、http://hostname/myfile.html という形式を使用できます。
リスン ポートは、通常のリクエストとセキュアな (SSL を使用した) リクエストで別個に定義します。通常のリスン ポートは Administration Console の [サーバ] ノードの [コンフィグレーション|一般] タブで定義し、SSL リスン ポートは [接続|SSL] タブで定義します。
HTTP アプリケーションと Web アプリケーションは、Sun Microsystems のサーブレット仕様 2.3 に従ってデプロイされます。この仕様では、Web アプリケーションとは Web ベース アプリケーションのコンポーネントを 1 つにまとめるための標準化された方法であると定義されています。これらのコンポーネントには、JSP ページ、HTTP サーブレット 静的リソース (HTML ページや画像ファイルなど) が含まれます。また Web アプリケーションは、エンタープライズ EJB や JSP タグ ライブラリなどの外部リソースにアクセスすることもできます。各サーバは、任意の数の Web アプリケーションのホストになることができます。通常、Web アプリケーションの名前は、その Web アプリケーションのリソースを要求するために使う URI の一部として使用します。
JSP は、デフォルトではサーバの一時ディレクトリにコンパイルされます。たとえば、サーバが「myserver」で webapp が「mywebapp」である場合、一時ディレクトリは <domain_dir>¥myserver¥.wlnotdelete¥appname_mywebapp_4344862 となります。
詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。
Web アプリケーションは、WebLogic Server のクラスタにデプロイできます。ユーザが Web アプリケーションのリソースを要求すると、そのリクエストはその Web アプリケーションがホストするクラスタの構成サーバの 1 つに転送されます。アプリケーションがセッション オブジェクトを使用する場合、そのセッションはクラスタ内の全サーバにレプリケートされなければなりません。セッションのレプリケートにはいくつかの方法があります。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
ドメイン内のすべてのサーバおよび仮想ホストで、デフォルト Web アプリケーションを宣言できます。デフォルト Web アプリケーションは、デプロイされている別の Web アプリケーションによって解決できない任意の HTTP リクエストに応答します。他のすべての Web アプリケーションとは異なり、デフォルト Web アプリケーションの名前は、URI の一部として使用されません。サーバまたは仮想ホストに割り当てられた Web アプリケーションを、デフォルト Web アプリケーションとして宣言することができます (Web アプリケーションの割り当てについては、この節で後述します。仮想ホストの詳細については、仮想ホスティングのコンフィグレーションを参照してください)。
WebLogic Server に付属のサンプル ドメインでは、デフォルトの Web アプリケーションが既にコンフィグレーションされています。このドメインのデフォルト Web アプリケーションは、DefaultWebApp という名前でドメインの applications ディレクトリに配置されています。
正常にデプロイされていないデフォルト Web アプリケーションを宣言すると、エラーがログに記録されるとともに、そのデフォルト Web アプリケーションにアクセスしようとしたユーザに対して HTTP 400 エラー メッセージが表示されます。
たとえば、shopping という Web アプリケーションが存在する場合、その Web アプリケーションの cart.jsp という JSP にアクセスするには、次の URL を使用します。
http://host:port/shopping/cart.jsp
しかし、shopping をデフォルト Web アプリケーションとして指定した場合、cart.jsp にアクセスするには次の URL を使用します。
(host は WebLogic Server が稼働するマシンのホスト名、port は WebLogic Server がリクエストをリスンするポートの番号)
サーバまたは仮想ホストのデフォルト Web アプリケーションを宣言するには、Administration Console を使用して、次の手順を実行します。
仮想ホスティングを使用すると、サーバまたはクラスタが応答するホスト名を定義できます。仮想ホスティングを使用するときは、WebLogic Server またはクラスタの IP アドレスにマップする 1 つまたは複数のホスト名を、DNS を使って指定します。また、仮想ホストによって提供される Web アプリケーションを指定します。仮想ホスティングをクラスタ内で使用する場合、ロード バランシング機能により、DNS ホスト名の 1 つが他のホスト名より多くのリクエストを処理する場合でもハードウェアを最も効率的に使用できます。
たとえば、books という Web アプリケーションが仮想ホスト名 www.books.com のリクエストに応答し、これらのリクエストが WebLogic Server A、B、および C に向けられるよう指定し、一方、cars という Web アプリケーションが仮想ホスト名 www.autos.com に応答し、これらのリクエストが WebLogic Server D および E に向けられるよう指定できます。アプリケーションと Web サーバの条件に合わせて、仮想ホスト、WebLogic Server、クラスタ、および Web アプリケーションのさまざまな組み合わせをコンフィグレーションできます。
仮想ホスティングを使用すると、複数の Web アプリケーション用の画像などの静的ファイルを提供する 1 つのディレクトリを作成することもできます。 たとえば、仮想ホストを使用して画像ファイルを提供するには、次のようなマッピングを作成できます。
<local-path>c:/usr/gifs</local-path>
<url-pattern>/images/*</url-pattern>
HTTP:// localhost:7001/mywebapp/images/test.gif への要求があると、WebLogic Server 実装は要求された画像を c:/usr/gifs/images/* で検索します。
仮想ホストをこのように使用するには、画像ファイルを格納する images という名前のディレクトリを作成する必要があります。 このディレクトリは「/images/test.gif」などの相対 URI に配置する必要があります。
また、定義した各仮想ホストに対して、個別に HTTP パラメータと HTTP アクセス ログを定義できます。仮想ホストに対して設定された HTTP パラメータとアクセス ログは、サーバに対して設定された HTTP パラメータとアクセス ログをオーバーライドします。指定できる仮想ホストの数に制限はありません。
仮想ホスティングをアクティブ化するには、仮想ホストをサーバまたはサーバ クラスタに割り当てます。クラスタに割り当てられた仮想ホスティングは、そのクラスタ内のすべてのサーバに適用されます。
各仮想ホストに対して、デフォルト Web アプリケーションを指定することもできます。仮想ホストのデフォルト Web アプリケーションは、同じサーバまたはクラスタで仮想ホストとしてデプロイされている別の Web アプリケーションに解決できないすべてのリクエストに応答します。
他の Web アプリケーションとは異なり、デフォルト Web アプリケーションの名前 (コンテキスト パスとも言う) は、そのデフォルト Web アプリケーションのリソースにアクセスするために使う URI の一部として使用されません。
たとえば、www.mystore.com という仮想ホスト名を定義し、shopping という Web アプリケーションをデプロイしたサーバにその仮想ホストを割り当てた場合、shopping の cart.jsp という JSP にアクセスするには、次の URI を使用します。
http://www.mystore.com/shopping/cart.jsp
しかし、shopping をこの仮想ホスト www.mystore.com のデフォルト Web アプリケーションとして指定した場合は、次の URI を使用して cart.jsp にアクセスします。
http://www.mystore.com/cart.jsp
詳細については、WebLogic Server による HTTP リクエストの解決方法を参照してください。
仮想ホストを定義するには、Administration Console を使用して次の手順を実行します。
仮想ホスト名が必ず解決されるようにするには、仮想ホスト名を入力した行をサーバ上の etc/hosts ファイルに追加する必要があります。
WebLogic Server による HTTP リクエストの解決方法
WebLogic Server が HTTP リクエストを受信すると、WebLogic Server は、URL のさまざまな部分を解析し、その情報を利用してどの Web アプリケーションとサーバがそのリクエストを処理すべきかを決定することによって、そのリクエストを解決します。以下の例では、Web アプリケーション、仮想ホスト、サーブレット、JSP、および静的ファイルのリクエストのさまざまな組み合わせとその応答を示します。
注意: Web アプリケーションをエンタープライズ アプリケーションの一部としてパッケージ化する場合は、Web アプリケーションへのクエストの解決に使用する代わりの名前を指定できます。詳細については、「エンタープライズ アプリケーションの一部としての Web アプリケーションのデプロイメント」を参照してください。
次の表に、WebLogic Server によって提供される URL とファイルのサンプルを示します。「インデックス ディレクトリのチェック」カラムは、特定のファイルが要求されていない場合にディレクトリ リストを提供するかどうかを指定する [インデックス ディレクトリ] 属性に関するものです。[インデックス ディレクトリ] 属性は、Administration Console の [Web アプリケーション] ノードの [コンフィグレーション|ファイル] タブで設定します。
oranges Web アプリケーション内の /naval という <url-pattern> でマップされているサーブレット。 サーブレット マッピングでは、いくつか考慮すべきことがある。詳細については、「サーブレットのコンフィグレーション」 |
||
oranges Web アプリケーション内の /naval という <url-pattern> にマップされているサーブレットがデフォルト Web アプリケーションとして定義されている。 詳細については、「サーブレットのコンフィグレーション」 |
||
|
詳細については、「HTTP エラー応答のカスタマイズ」を参照。 |
|
www.fruit.com というホスト名を持つ仮想ホストのデフォルト Web アプリケーションのウェルカム ファイル* |
||
www.fruit.com というホスト名を持つ仮想ホストのデフォルト Web アプリケーションの最上位ディレクトリのリスト |
||
www.fruit.com というホスト名の仮想ホストに関連付けられている oranges Web アプリケーションの myfile.html |
* 詳細については§「ウェルカム ページのコンフィグレーション」を参照してください。
WebLogic Server は、HTTP トランザクションのログを、共通ログ フォーマットまたは拡張ログ フォーマットのいずれかのフォーマットでテキスト ファイルに保存します。共通ログ フォーマットは、デフォルトの、標準規則に従った形式です。拡張ログ フォーマットでは、記録されている情報をカスタマイズできます。定義した各サーバまたは各仮想ホストに対して、HTTP アクセス ログの性質を定義する属性を設定できます。
サーバまたは仮想ホストに対する HTTP ログの設定については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
ログ ファイルは、そのファイルのサイズ、または指定した時間のいずれかに基づいてローテーションすることができます。これらの 2 つの条件のいずれかが満たされると、現在のアクセス ログ ファイルが閉鎖され、新しいログ ファイルが開始されます。アクセス ログ ファイルの名前は、ファイルがいつローテーションされたかを示す日付と時刻が含まれるようにコンフィグレーションできます。時刻をコンフィグレーションしない場合、ローテーションされたファイルの名前には、ローテーションごとに増分される数値が含まれます。HTTP アクセス ログは、定義した Web Server ごとに保存されます。
HTTP 情報ログのデフォルト フォーマットは、共通ログ フォーマットです。この標準フォーマットのパターンは以下のとおりです。
host RFC931 auth_user [day/month/year:hour:minute:second
UTC_offset] "request" status bytes
拡張ログ フォーマットを使用した HTTP アクセス ログの設定
WebLogic Server は、W3C によって定義された拡張ログ フォーマット、バージョン 1.0 もサポートしています。このフォーマットは新しく登場した規格で、WebLogic Server は W3C の草案仕様に準拠しています。最新バージョンは、「W3C Technical Reports and Publications page」に公開されています。
拡張ログ フォーマットを使用すると、各 HTTP 通信に関する記録情報のタイプと順序を指定できます。拡張ログ フォーマットを有効にするには、Administration Console の [HTTP] タブで、[フォーマット] 属性を [Extended] に設定します (カスタム フィールド識別子の作成を参照)。
このフォーマットでは、ログ ファイルに記録される情報のタイプをディレクティブによって指定します。ディレクティブは、実際のログ ファイルに組み込まれます。ディレクティブは、新しい行から「#」という記号で始まります。ログファイルが存在しない場合、デフォルト ディレクティブが記述された新しいログ ファイルが作成されます。しかし、サーバの起動時にログ ファイルが既に存在する場合、そのファイルの先頭には有効なディレクティブが存在しなければなりません。
ログ ファイルの最初の行には、そのログ ファイル フォーマットのバージョン番号を示すディレクティブが存在しなければなりません。また、ファイルの先頭の近くには、Fields ディレクティブが存在しなければなりません。
#Version: 1.0
#Fields: xxxx xxxx xxxx ...
ここで各 xxxx は、記録されるデータ フィールドを表します。フィールド タイプは、W3C 仕様に定義されているとおり、単純な識別子として指定されるか、またはプレフィックス-識別子というフォーマットを取ります。次に例を示します。
#Fields:date time cs-method cs-uri
この識別子は、HTTP アクセスごとにトランザクションの日付と時間、クライアントが使用したリクエスト メソッド、およびリクエストの URI を記録するようサーバに指示します。各フィールドはスペースによって区切られ、各レコードは新しい行に書き込まれてログ ファイルに追加されます。
注意: ログ ファイル内の#Fields ディレクティブの後には新しい行が続かなければなりません。これは、最初のログ メッセージがディレクティブと同じ行に追加されないようにするためです。
以下の識別子がサポートされています。プレフィックスは必要ありません。
W3C 仕様で定義されている cached フィールドは、WebLogic Server ではサポートされていません。
以下の識別子はプレフィックスを必要とし、単独では使用できません。ここでは、サポートされている個々のプレフィックスの組み合わせについて説明します。
拡張ログ フォーマットを使用する HTTP アクセス ログ ファイルに追加するために、ユーザ定義のフィールドを作成することもできます。カスタム フィールドを作成するには、ELF ログ ファイルで Fields ディレクティブを使用してフィールドを指定します。次に、そのフィールドに対応し、必要な出力が生成される Java クラスを作成します。フィールドごとに別々の Java クラスを作成することも、複数のフィールドを出力する Java クラスを作成することもできます。このようなクラスの Java ソースのサンプルをこのマニュアルの中で示します。カスタム ELF フィールドを作成する Java クラスを参照してください。
Fields ディレクティブの詳細については、Fields ディレクティブの作成を参照してください。
weblogic.servlet.logging.CustomELFLogger
Java クラスでは、logField() メソッドを実装しなければなりません。このメソッドは、HttpAccountingInfo オブジェクトと FormatStringBuffer オブジェクトを引数として取ります。
注意: カスタム フィールドを定義する Java クラスの記述では、システムの処理速度を低下させるようなコードは実行しないでください (たとえば、DBMS へのアクセス、大量の I/O、または ネットワークの呼び出しなど)。HTTP アクセス ログ ファイルのエントリは HTTP リクエストごとに作成されます。
注意: 複数のフィールドを出力する場合は、タブでフィールドを区切ります。フィールドの区切り方およびその他の ELF フォーマットの詳細については、「Extended Log Format」を参照してください。
HttpAccountingInfo オブジェクトの get メソッド
次のメソッドは HTTP リクエストに関するさまざまなデータを返します。これらのメソッドは、javax.servlet.ServletRequest、javax.servlet.http.Http.ServletRequest、および javax.servlet.http.HttpServletResponse のさまざまなメソッドと似ています。
これらのメソッドの詳細については、次の表に示す Java インタフェースの対応するメソッドを参照するか、表内の特定の情報を参照してください。
コード リスト 6-1 カスタム ELF フィールドを作成する Java クラス
import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;
/* この例では、User-Agent フィールドを
MyCustomField というカスタム フィールドに出力する
*/
public class MyCustomField implements CustomELFLogger{
public void logField(HttpAccountingInfo metrics,
FormatStringBuffer buff) {
buff.appendValueOrDash(metrics.getHeader("User-Agent"));
}
}
サービス拒否攻撃とは、偽りのリクエストによってサーバを過負荷状態にしようとする悪意ある試みです。一般的な攻撃の 1 つは、HTTP POST メソッドで膨大な量のデータを送信するというものです。WebLogic Server では、3 つの属性を設定して、この種の攻撃を防ぐことができます。3 つの属性は、Administration Console の [サーバ] または [仮想ホスト] で設定します。これらの属性を仮想ホストに対して設定した場合、その値は [サーバ] で設定した値をオーバーライドします。
HTTP トンネリングのための WebLogic Server の設定
HTTP トンネリングとは、HTTP プロトコルしか使用できないときに、WebLogic Server と Java クライアントの間にステートフルなソケット接続をシミュレートするための手段です。HTTP トンネリングは、通常セキュリティ ファイアウォール内の HTTP ポートを「トンネリング」するために使用されます。HTTP はステートレスなプロトコルですが、WebLogic Server はトンネリング機能を提供して接続を通常の T3Connection のように見せかけます。しかし、通常のソケット接続に比べてパフォーマンスが若干低下する場合があります。
HTTP プロトコルでは、クライアントはリクエストを送信し、サーバから応答を受信することしかできません。一方、サーバも自主的にクライアントと通信できません。つまり、HTTP プロトコルはステートレスであり、連続的な双方向接続を行うことができません。
WebLogic HTTP トンネリングは、HTTP プロトコルを通して T3Connection をシミュレートすることによって、こうした制限を乗り越えます。トンネリング接続を調整してパフォーマンスを向上させるには、Administration Console で 2 つの属性を設定します。これらの属性にアクセスするには、[サーバ] の [接続|プロトコル] タブを開きます。接続に関する問題が発生しない限り、これらの属性はデフォルトのままにしておくことをお勧めします。これらの属性は、クライアント接続が有効かどうか、またはクライアントが生存しているかどうかをサーバが調べるために使用されます。
クライアントからの WebLogic Server への接続
クライアントが WebLogic Server への接続を要求する場合、HTTP トンネリングを使用するために必要なことは URL に HTTP プロトコルを指定することだけです。次に例を示します。
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, "http://wlhost:80");
Context ctx = new InitialContext(env);
クライアント側では、特殊なタグが http プロトコルに付加されます。このため WebLogic Server は、これが通常の HTTP リクエストではなくトンネリング接続であることを認識します。この処理では、アプリケーション コードを変更する必要はありません。
クライアントは、ポートが 80 の場合でも URL にポートを指定しなければなりません。WebLogic Server では HTTP リクエスト用のリスン ポートを任意に設定できますが、ポート 80 を使用するのが最も一般的です。通常、ファイアウォールを介したポート 80 へのリクエストは許可されるからです。
WebLogic Server 用のリスン ポートは、Administration Console の [サーバ] ノードの [コンフィグレーション|一般] タブで指定します。
静的ファイルを提供するネイティブ I/O の使用(Windows のみ)
Windows NT/2000 上で WebLogic Server を実行する場合、WebLogic Server で Java メソッドを使用する代わりにネイティブ オペレーティング システム呼び出しの TramsmitFile を使用するように指定して、HTML ファイル、テキスト ファイル、および画像ファイルなどの静的ファイルを提供することができます。ネイティブ I/O を使用すると、サイズの大きな静的ファイルを提供するときのパフォーマンスが向上します。
ネイティブ I/O を使用するには、ネイティブ I/O を使用して提供されるファイルが含まれている Web アプリケーションの web.xml デプロイメント記述子に 2 つのパラメータを追加します。 1 つ目のパラメータ、weblogic.http.nativeIOEnabled を TRUE に設定して、ネイティブ I/O ファイルの提供を有効にします。 2 つ目のパラメータ、weblogic.http.minimumNativeFileSize にはネイティブ I/O を使用して提供するファイルの最小サイズを設定します。 提供するファイルがこの値より大きい場合にネイティブ I/O が使用されます。 このパラメータを指定しない場合、400K の値が使用されます。
通常、ネイティブ I/O では、提供するファイルが大きいほどパフォーマンスが向上します。ただし、WebLogic Server を実行するマシンの負荷が増大すると、この利点は小さくなります。 weblogic.http.minimumNativeFileSize の適切な値を見つけるためにテストする必要があります。
以下の例では、web.xml デプロイメント記述子に追加するすべてのエントリを示します。 このエントリは、web.xml ファイルで、<distributable> 要素の後、<servlet> 要素の前に配置しなければなりません。
<param-name>weblogic.http.nativeIOEnabled</param-name>
<param-value>TRUE</param-value>
<param-name>weblogic.http.minimumNativeFileSize</param-name>
<param-value>500</param-value>
weblogic.http.nativeIOEnabled は、FileServlet のコンテキスト パラメータとしても設定できます。
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |