Oracle9i Application Server Release 2 Oracle HTTP Server概要

(1)

Oracle9i Application Server Release 2

Oracle HTTP Server 概要

オラクル・ホワイト・ペーパー 2002 年 9 月

(2)

Oracle9i Application Server Release 2:

Oracle HTTP Server の概要

概要...3 はじめに...3 OHS:機能の概要 ...3 Web サーバー ...3 サポート範囲の広いアプリケーション・サーバー...4 クラスタリング・インフラストラクチャ...4 OHS: Web サーバー ...5 モジュール化されたアーキテクチャ...5 プロセス・アーキテクチャ...5 OHS の構成 ...6 セキュリティとシングル・サインオン...6 仮想ホスト...7 WebDAV のサポート...8 プロキシ・サーバーとURL リライティング ...8 OHS: サポートしているアプリケーション・サーバー ...9 PLSQL による動的コンテンツ − PSP と mod_plsql...9

Perl と Server Side Includes による動的コンテンツ ...9

CGI と FastCGI による動的コンテンツ: Java/C/C++ ...10

Java Object Cache ...10

Dynamic Monitoring Service ... 11

OHS: クラスタリング・フレームワーク ...12 用語...12 Oracle9iAS インスタンスのアーキテクチャ...13 Oracle9iAS クラスタのアーキテクチャ...14 実際の配置例...14 DMZ 内でのクラスタリング配置 ...14 DMZ 間でのクラスタリング配置 ...15 サマリー...16

(3)

概

要

Oracle HTTP Server（OHS）は、Web サーバーおよび動的アプリケーションを作成するために必要なインフラストラクチャを提供します。

実証済みのApache インフラストラクチャに基づいて、Oracle HTTP Server は、次のような重要な拡張機能を追加します。Perl（mod_perl、CGI）、C（CGI、FastCGI、 C++（FastCGI）、そして、もちろんポピュラーな Oracle 言語である PLSQL です。また、フォワードおよびリバースどちらのプロキシ・サーバーとして使用することも可能です。さらに、Oracle9iAS Release 2 では、シングル・サインオン、クラスタリング配置、 高可用性などの新機能が追加されています。本書では、Oracle HTTP Server（OHS）の強力な機能の概要を示します。

はじめに

Oracle9iAS Release 2 では、コアおよびエンタープライズの 2 種類のリリースを利 用できます。コア・リリースには、基本機能、つまりOracle9iAS Web Cache(Web Cache)、Oracle HTTP Server(OHS)、および Oracle9iAS Containers for J2EE(OC4J)が 含まれます。エンタープライズ・リリースは、図1 に示すようなさらに多くの重要機能を提供します。本書では、Oracle HTTP Server（OHS）の機能を中心に説明します。OHS は、スタンドアロン・コンポーネントとして購入することや、インストール・オプションとして購入することはできませんのでご注意ください。OHS は、 Oracle9iAS インストー ル・オプションでインストールされます。

OHS:機能の概要

Oracle HTTP Server 内で利用可能なすべての機能およびコンポーネントの概要を次に示します。

Web サーバー

• Apache 基盤 − OHS は、実証済み Apache Web サーバーを基盤としています。

• セキュリティおよびシングル・サインオン− OHS は、SSL、基本認証お図1: Oracle9iAS の機能

(4)

• 仮想ホスト − 仮想ホストにより、ISP は Web サーバーの 1 つのインスタンスに複数のカスタマをホスティングできます。また、それぞれを別々に構成できます。 • WebDAV − コンテンツのファイル・ベースの格納機能に加え、Oracle リポジトリもサポートします。WebDAV により、MS Office または他の DAV クライアントは、サーバー上でファイルを編集できます。 • プロキシ・サーバーと URL リライティングにより、外部から参照可能な URL に影響を与えずに、迅速にサイトの再編成を行うことができます。 •

サポート範囲の広いアプリケーション・サーバー

• PL/SQL ストアド・プロシージャに、ブラウザから簡単にアクセスできます。 • PSP（PL/SQL Server Pages）では、HTML でのスクリプティング言語としてPL/SQL を使用できます。

• Perl のサポートは、mod_perl を通じて提供されるため、毎回 Perl インタプリタを再起動する必要はありません。

• Sever Side Includes は、ヘッダー/フッターをインクルードする標準メカニズムを提供します。

• C/C++サポートは、FastCGI を通じて利用できるようになったため、プロセスを活動状態に保つことができ、起動コストが不要になりました。 • Object Caching for Java は、複数ノード・オブジェクト・クラスタリング、

グループ・メンバーシップ / 失効化など、Java オブジェクトのためのキャッシュ機能を提供します。

• Dynamic Monitoring Service は、OHS またはインストルメント・アプリケーションを監視します。

クラスタリング・インフラストラクチャ

• 分散構成管理 − クラスタ全体への配置またはクラスタ間のノードのクローニングを行えます。 • 高可用性フレームワーク − 停止検出、再起動、イベント通知により、クラスタ全体の可用性を保証します。 • ロード・バランシング − 新モジュール mod_oc4j は、OHS から同じクラスタまたは別のクラスタにある別のOC4J サーバーに対してルーティングできるようになりました。ラウンド・ロビン・ルーティングを行います。

(5)

OHS: Web サーバー

モジュール化されたアーキテクチャ

Web サーバーのアーキテクチャは、可能なかぎりモジュール化されています。コアWeb サーバー（http プロトコルの場合）は非常に小さく、すべての機能は、プラグインするモジュールとして実装され、リクエストのライフサイクルの適切な箇所で呼び出されます（図2）。モジュール（つまりAPI）は、リクエスト・ライフサイクルの適切な箇所で自動的に呼び出されます。エンド・ユーザーがモジュール・レベルで手を加えることは、技術的には可能ですが、主にサポート上の問題が理由で、奨励されていません。したがって、製品コンポーネントにはドキュメントは提供されておらず、オラクル社はエンド・ユーザーが独自のモジュールを追加することを認めていません。ただし、このモジュールに関する説明は、構成設定や関係するエラーを理解するために役立ちます。

プロセス・アーキテクチャ

OHS は、起動時には、親プロセスとして開始します。このプロセスは、構成全体をロードし、関連付けられたモジュールをロードし、事前構成された多数の子プロセスを開始します。（Windows では、これは複数のスレッドを持つ1 つの子です。）親はhttp リクエストをリスニングしません。その唯一の役割は、子が活動状態であることを確認し、負荷から新しい子が必要になったときには、それを開始することです。図2: HTTP リクエストと応答のサイクル

図3: Oracle HTTP Server (Web サーバー・コンポー

(6)

それぞれの子プロセス（最大1024 個）は、1 度に 1 つの HTTP リクエストを処理します。子は、相互排除メカニズム（ユーザー構成可能）に基づいて、誰が次のリクエストを受けるかを決定します。

OHS の構成

OHS の以前のリリースでは、 OHS の構成には、構文とディレクティブの充分な理解が必要でした。

Oracle9iAS Release 2 では、OHS の構成の大部分はOEM（Oracle Enterprise Manager） Web Site により行われます。

ただし、OEM Web Site についてはこの文書では詳しい説明は行いません。各種設定の優先順位階層を図4 に示します。このように設定に複数のレベルがあることは、ISP の望む柔軟性のある配置を実現する場合に非常に便利です。さらに、これらを理解することは、OEM Web Site によって正しく構成を行うために役立ちます。

セキュリティとシングル・サインオン

Oracle HTTP Server の Web サーバー・コンポーネントは、暗号化、認証、認可のような標準Web サーバー・セキュリティ機能を提供します。特に暗号化では、OHS は標準 SSLv3 をサポートします。また、Oracle 9i DB およ び他のOracle 製品とサーバー証明書を共有できます。 OHS は、静的アプリケーションと動的アプリケーションの両方に対して、認可スキームに基づいたグループを提供します。ただし、これらのグループはフラット・ファイルで定義する必要があります。認証面では、OHS は、シングル・サインオンに対して重要な拡張を追加しました。つまり、Oracle9iAS Single Sign-On による LDAP ディレクトリ統合を可能にしまし た。この統合は、mod_osso により行われます。理解しやすいように、ここに使用例を示します。 1. ユーザーは、ページ http://www.foo.com/subscribe/content をリクエストします。 1. サーバー設定 − 親プロセスに適用されます。通常は1 つの OHS インスタンスです。 2. デフォルト・ホスト設定 − OHS がホスティングするデフォルトWeb サイトに適用されます。 3. 仮想ホスト設定 − 特定の仮想ホストに適用されます。（詳細は後述の「仮想ホスト」参照）。 4. ディレクトリ、位置、ファイル設定 − 特定のディレクトリにあるすべてのファイル、ある種類のすべてのURL、または特定のファイルにマップされたすべての URL に適用されます。 5. ディレクトリ設定は、そのディレクトリでこれらの設定を特別なファイル（.htaccess）に入れることによっても適用できます。図4: 優先順位階層

(7)

2. OHS は、ユーザーがまだログインしていないことを認識した場合は、ユーザーをOracle9iAS Single Sign-On にリダイレクトします。

3. ユーザーがログインすると、Oracle9iAS Single Sign-On は、ユーザーがリクエ ストしたページにリダイレクトします。このプロセスで、Oracle9iAS Single Sign-On は暗号化された Cookie を設定します。この Cookie は、mod_osso のようなパートナ・アプリケーションのみが復号化できます。 4. OHS は、リクエストを受け取ると（再度）、正しい Cookie が設定されていること、つまりユーザーがすでに認証されていることを通知し、ユーザーを通過させます。 5. ここで、ユーザーは、別のサーバーに置かれている（可能性のある）サイト http://www.bar.com/subscri be /content をリクエストしますが、同じOracle9iAS Single Sign-On にリダイレクトします。 6. OHS（新しいサーバーの）は、リクエストを受け取り、 Cookie がすでに設定されていることを通知するため、ユーザーにログインを要求せずに通過させます。したがって、開発者は、何もプログラムする必要なしに、シングル・サインオン・ベースのアプリケーションを配置でき、エンド・ユーザーは、何回もログインせずに複数のサイトにアクセスできます。

仮想ホスト

ISP としては、1 台のマシンに対して複数のホスト名をマップして、複数の人々を限られたインフラストラクチャでホスティングすることは一般的です。現在、これらの異なるホスト名のそれぞれを、一般に仮想ホストと呼ばれる構成セットアップを通じて独自のサイトにマップできます。デフォルト・ホストのほとんどすべての構成設定は、仮想ホストでも利用可能です。つまり、仮想ホスティングにより失われる機能はほとんどありません。したがって、カスタマのホスティングにより、独自の構成の制御を提供すること（サーバー全体には何も影響を与えません）、または別の構成を本番で使用する前に同じサーバーでテストすることができます。図5: mod_osso とシングル・サインオン

(8)

WebDAV のサポート

DAV とは、Distributed Authoring and Versioning（分散オーサリングおよびバージョニング）の略です。これは、ベース・プロトコルとしてHTTP を使用する IETF 標準です。WebDAV 対応サイトで、クライアント（MS Office、Dreamweaver などのツール）がドキュメントの編集を行えるようにします。このプロトコルの大部分の実装（Apache の mod_dav など）では、ファイル・システムを編集可能なファイルのためのサーバー上の記憶場所とすることができます。 OHS は、Oracle データベースを外部記憶装置として利用できるようにすることにより、これを拡張しました。また、他の保管場所を外部記憶装置として提供するために、簡単に使用できるAPI も提供しています。したがって、OHS 管理下のサイトにあるファイルを直接編集および保管するため、MS Word を使用できます。これらのオフィス・ドキュメントはデータベースに保管することもでき、エンド・ユーザーはそれについて知る必要はありません。

プロキシ・サーバーと

URL リライティング

活発なWeb サイトには、しばしば変更が加えられます。それに伴って、ディレクトリ構造およびURL が変更になることもあります。OHS では、URL リライティングをサポートするエンジンを搭載することにより、容易にそのような変更に対処できるようにしています（エンド・ユーザーはブックマークを変更する必要はありません）。また、フォワードおよびリバースの両方向のプロキシ機能をサポートしているため、異なるサーバーにより提供されるコンテンツを、簡単に1 つのサーバーから提供されているように見せることができます。この機能は、プライマリ・アプリケーション・サーバーからのプロセスを妨害する可能性のあるモデム接続を隔離するためにも頻繁に使用されます。図6: mod_osso と シングル・サインオン

(9)

OHS: サポートしているアプリケーション・サーバー

PLSQL による動的コンテンツ

− PSP と mod_plsql

Java Server Pages のコンセプトと同様、PL/SQL Server Pages モジュールは、PL/SQL をHTML ページ内のスクリプティング言語として使用できます。ページはストアド・プロシージャに変換され、次に説明するメカニズムによりブラウザに対する出力が送信されます。 OHS には、ブラウザからデータベース・ストアド・プロシージャに対するリクエストを可能にするモジュール（mod_plsql）が入っています。これは、最もポピュラーな機能の1 つです。すべてのPL/SQL は、データベース上で動作します。ここに、mod_plsql の流れを示します。 1. OHS はリクエストを受け取ります。登録済みモジュールに応じて、OHS はどのモジュールにリクエストを処理させるかを決定します。この場合は mod_plsql です。 2. mod_plsql はデータベースに接続し、コール・パラメータを準備し、データベース内のPLSQL プロシージャを呼び出します。 3. PL/SQL プロシージャは、データベースからアクセスされたデータとストアド・プロシージャを使用してHTML ページを生成します。このタスクをさらに簡単に行えるよう、データベースにインストールできるパッケージが製品に用意されています。 4. レスポンスは mod_plsql に戻され、mod_plsql はそれをブラウザに送信します。 mod_plsql は OHS 子プロセス内で稼働します。したがって、子プロセスは、それぞれデータベースに対する接続を所有し、プロセス存続中はそれを維持します。この接続は、OHS 子プロセス間で共有されません。したがって、大きなサイトでの接続数は、子プロセスの数（および他の構成設定）により決まります。

Perl と Server Side Includes による動的コンテンツ

Server Side Include は、サイトのすべてのページに、動的コンテンツまたは一定の静的コンテンツを追加する簡単な方法を提供します。これは一般に、ヘッダー/ フッター情報のために使用されます。OHS は、特定のタイプのファイルまたは特定の仮想ホストに対してのみこれらを利用できる特別なディレクティブをサポートしています。

(10)

Perl は、Web のためのスクリプトと CGI プログラムを開発する最も一般的方法の 1 つです。しかし、Perl インタプリタが大きいため、起動と停止に時間がかかります。OHS は、Perl インタプリタをメモリー内で常に稼働状態に保つことにより、この実行を最適化します。また、Web リクエストを処理できる新しい Perl モジュールを追加することにより、Web サーバー機能を拡張できます（図 2 参照）。

CGI と FastCGI による動的コンテンツ: Java/C/C++

CGI プログラムを書く機能は、ほとんどの Web サーバーにおいて一般的な機能です。ただし、OHS は、リクエストのライフサイクルを超えて、これらのプログラムをライブに保つ機能を追加します。したがって、2 回目以降のリクエストでは、CGI プログラム（関連するデータベース接続も含めて）を再起動するオーバーヘッドが不要です。その結果、パフォーマンスが劇的に向上します。これを可能にするフレームワークは、FastCGI と呼ばれます。C および C++を実行できます（J2EE /Java ベースの CGI の利用は一般的ではありません）。

図9: FastCGI のアーキテクチャ クライアント・リクエストが到着すると、Web サーバーは FastCGI プロセスに対する接続をオープンし、FastCGI プロセスがアプリケーションの入口点を呼び出して、結果を戻します。FastCGI プロセスは、配置オプションの選択により、同じマシンまたは別のマシンに置くことができます。単一スレッドのFastCGI アプリケーションに対しては、マルチ・プロセスに基づく構成が自動的に提供され、マルチ・スレッドのFastCGI アプリケーションは単一プロセスにより処理されます。 FastCGI は、複数の役割を果たすことができます。1 つは HTTP リクエストに対するレスポンスを生成する役割、もう1 つは Web サーバーに対する認可リクエストを受理または拒絶する認可者としての役割です。

Java Object Cache

OHS 自身は J2EE サポートを提供しません。このサポートは、OC4J により提供されます。ただし、OHS は、プロセス内、プロセス間、およびローカル・ディスク上でJava オブジェクトを管理するために設計された Java クラスのセットを提供しています。これらのクラスの主な目的は、取出や作成にコストのかかるオブジェクトについて、そのローカル・コピーを管理することにより、サーバーのパフォー

(11)

各オブジェクトには属性のセットが関連付けられており、それにより、オブジェクトをキャッシュにどのようにロードするか、オブジェクトをどこに保管するか（メモリーか、ディスクか、または両方か）、どのように無効化するか（時間によるか、明示的リクエストによるか）、オブジェクトが失効化された場合に誰に通知するか、などが制御されます。オブジェクトは、グループとしてまたは個々に無効化できます。これは、オブジェクトの集中制御が行われていない場合でも可能です。

Dynamic Monitoring Service

基本的なWeb サーバーは、ブラウザからアクセスできる一般的な監視情報を提供します。OHS は、ベース・コードの装備によりこれらの測定項目を拡張しました。これによるパフォーマンスへの影響はなく、しかも、Web を通じてランタイムでアクセスできます。また、開発者は同じAPI を、C と Java の両方で利用できます。この監視は動的なものです。つまり、測定項目は、エンド・カスタマ・アプリケーションも含めて、製品のすべてのコンポーネントに応じて自在に追加および削除できます。動的監視は、ランタイム・オーバーヘッドを最小限にします。DMS は、明示的リクエストがなければ、イベント・トレース、頻繁な割込み、過剰な後処理、パフォーマンス・データの過剰な転送を行いません。

図10: Java Object Cache のアーキテクチャ

図11: OHS Dynamic Monitoring Service のアーキテク

(12)

図11 に、OHS アーキテクチャの様々な部分に連結された、いくつかの DMS モジュールを示します。 DMS は、パフォーマンス・アナリスト、サポート・エンジニア、コンサルタント、カスタマのバグやパフォーマンス問題を本番システムの現場で解決しなければならない人々が使用する診断ツールとして最も適しています。

OHS: クラスタリング・フレームワーク

Oracle9iAS Release 2 では、クラスタリングと分散構成に関するいくつかの新しい 用語が導入されました。まず、その用語について説明し、その後でクラスタリング・フレームワークについて詳しく説明します。

用語

Oracle9iAS インスタンス: この用語は、 同じOracle ホームから開始されるコンポーネント・プロセスの集まりを表します。この用語に類似した概念は、 Oracle9iAS の１つのインストレーションにおける実行インスタンスです。これは、次の図で1 で表されています。ノード（サーバー・マシン）: 理論的には、同じクラスタの一部、またはそうでない複数のOracle9iAS インスタンスを１ つのノードで実行できます。コンポーネント・インスタンス: 複数の Oracle9iAS インスタンスに渡って、同一に構成されたコンポーネント・プロセスを表します。したがって、コンポーネント・インスタンスには、異なるマシンで稼働していることもある実際のプロセスがいくつか含まれます。これは、次の図で2 で表されています。 Oracle9iAS クラスタ: Oracle9iAS インスタンスの集まりを表します。どの物理的 インスタンスでもリクエストを処理することができますが、要求側が手にする最終結果は同じです。クラスタは、次の図で3 で表されています。一般的な配置の観点からは、クラスタはサーバーの集合です。すべてのサーバーは同一に構成され、1 つの Oracle9iAS インスタンスを含みます。この Oracle9iAS インスタンスは、OHS を含み、複数の OC4J1プロセスが含まれることもあります。

(13)

Oracle9iAS インスタンスのアーキテクチャ

Oracle9iAS インスタンス内のプロセスは、大きく 2 つの独立したカテゴリに分け ることができます。 • リクエストの処理に重要なプロセス − OHS、OC4J など • ブック・キーピング・プロセス − OPMN、DCM2 など クラスタリング・フレームワークは次のように要約できます。ブック・キーピング・プロセスは、周辺環境とプロセスを監視し、重要なプロセスが、最新の構成で、正しくリクエストを処理する方法を見つけられるようにします。新機能のそれぞれについて、少し詳しく説明します。

Oracle Process Manager and Notification Server（OPMN）は、Oracle9iAS インスタン ス内のプロセスを管理するとともに、内部および外部の別のコンポーネント・インスタンスからのすべてのイベントを、受信を希望する者に通知します。この方法で、OHS は、異なるマシンに戻ったばかりのOC4J プロセスについて確実に知ることができます。イベントは、異なるプロセス間を、HTTP を介してすべて通信されます。

Distributed Configuration Manage- ment（DCM）は、外部環境（Oracle Enterprise Manager、インフラストラクチャ・データベースなど）から構成情報を取り出し、OPMN が伝播するためのイベントを生成します。この2 つの機能により、コンポーネント・インスタンスは、構成の更新、または起動/停止コマンドを確実に実行できます。 Infrastructure Repository には、関係するすべての構成情報が含まれます。したがって、すべての構成ファイルと配置情報は、クラスタつまりOracle9iAS イ ンスタンスの外部に保管されます。DCM は、個々のコンポーネントのために、その情報を構成ファイルに変換します。

ｍod_oc4j は、OHS にプラグインする新しいモジュールで、すべての OC4J インスタンスに対するルーティングを行います。これは、DCM および OPMN と共同で機能し、ルーティング・テーブルを最新状態に維持して、OC4J インスタンスで活動状態にあるOC4J プロセスのみの間でロード・バランシングを行います。このモジュールは、バックエンドでOC4J インスタンスと通信するために AJP を使用します。mod_oc4j のロード・バランシング・メカニズムはシンプルなラウンド・ロビンです。

(14)

Oracle9iAS クラスタのアーキテクチャ

前述のように、クラスタは同一構成のOracle9iAS インスタンスの集まりであり、 同じクラスタ名でタグが付けられます。次のような利点があります。構成 − DCM（OPMN と共同で機能）は、クラスタ全体に対して（J2EE）アプリケーションをデプロイできますが、1 つのノードまたはインスタンス構成の変更をクラスタ内のすべてのインスタンスに適用することもできます。ランタイム更新 − OPMN は、そのイベント・メカニズムを通じて、すべての mod_oc4j のロード・バランシング情報が新しい（または無効となった）OC4J プロセスと一貫性を持つように保証します。簡単なノード（Oracle9iAS インスタンス）の追加/削除 − DCM のクラスタ全体を対象とする構成機能と、OPMN により提供されるランタイム・プロセス・テーブル更新により、負荷の重いサイトを処理するためにクラスタに新しい Oracle9iAS インスタ ンスを追加する場合は、インスタンスを起動し、クラスタのメンバーとしてタグを付ける簡単な作業で済みます。その他は、すべてDCM と OPMN により透過的に処理されます。クラスタリング・フレームワークの詳細と事例は、別のドキュメントで説明され ています。 このドキュメントの目的とする、OPMN によるクラスタリング・フレームワークおよびフォールト・トレランス、OPMN と DCM による分散配置、mod_oc4j によるロード・バランシングがクラスタリング・フレームワークによりどのように提供されるかについては、このドキュメント内で前述されています。

実際の配置例

この項では、Oracle9iAS 全体との関連で OHS を配置する方法について、一般的事例をいくつか示します。ここでは、ファイアウォールのような外部システムとの相互作用と、OHS を外部システムと同時に機能させるために必要とされる変更点に焦点を絞ります。

DMZ 内でのクラスタリング配置

多くの場合、Oracle9iAS インスタンスのクラスタは、完全にファイアウォールの 中で配置されます。ロード・バランサ（またはWeb キャッシュ）が、このクラスタのフロントエンドとなり、OHS インスタンス間でリクエストのロード・バランシングを行います。

(15)

この事例では、外部ファイアウォールがHTTP リクエストを通過させるように構成する必要があります。内部ファイアウォールは、DCM がインフラストラクチャ・データベースを利用できるようにするため、データベース接続できるように構成する必要があります（他のPL/SQL、J2EE アプリケーションも同様にそのデータ・ソースを獲得する必要があります）。すべてのOPMN は、 2 つのファイアウォールの同じ側にあるため、イベント通信メカニズム（HTTP）はファイアウォールを通過する必要はなく、新しいポートをオープンする必要もありません。また、すべてのOHS と OC4J も DMZ にあるため、それらの間のAJP 通信はいずれのファイアウォールも通過する必要がありません。したがって、OHS とクラスタリング・フレームワークには、この配置メカニズムのための新しい要件はありません。

DMZ 間でのクラスタリング配置

このような配置では、 DMZ に Web サーバーのクラスタがあり、別の保護されたゾーンにOC4J サーバーのクラスタがあります。さらに、これらの背後にまた別のファイアウォールがあり、重要なデータ・ソースを守っています。外部ファイアウォールに対しての新しい要件はありません。HTTP が通過できるようにする必要があるのみです。一方、Web サーバー・クラスタとアプリケーション・サーバー・クラスタの間にある第2 のファイアウォールに対しては、2 つの新しい要件があります。OHS インスタンスとOC4J インスタンスの間で AJP メッセージをルーティングできること、および異なるクラスタを制御しているOPMN 間で HTTP ベースのイベントをルーティングできることです。さらに、すべてのDCM は、データベースに接続する必要があります。つまり、奥の2 つのファイアウォールは、データベース・ポートをオープンしている必要があります。図12: DMZ 内でのクラスタリング配置 図13: DMZ 間でのクラスタリング配置

(16)

サマリー

Oracle HTTP Server は、第 1 に Web サーバーです。実証済みの Apache テクノロジに基づき、本格的サイトとして必要なすべての機能を提供します。また、データ・ストアとしてOracle9i DB を使用する WebDAV もサポートします。第 2 に、Oracle HTTP Server は、多数のアプリケーション・サーバー・コンポーネントを含みます。 PLSQL、Perl、Server Side Include、C/C++など、様々な言語で Web アプリケーションを動的に書くことのできる機能を提供します。また、監視のためのDMS、Java オブジェクトをキャッシュするためのJava Object Cache などのフレームワークも提供します。第3 に、Oracle9iAS のためのクラスタリング・フレームワークを提供します。こ の新しいインフラストラクチャにより、J2EE アプリケーションを迅速に分散配置できます。また、最適なロード・バランシングを行い、リクエストに対するランタイムの影響を最小限にするために、障害用クラスタですべてのプロセスを監視し、透過的にルーティング表を更新します。

このような機能により、Oracle HTTP Server は、Oracle 9iAS の単なる 1 つのコンポーネントというだけでなく、Oracle9iAS の豊富な機能を引き出す役目を果たし ています。

(17)

Oracle9i Application Server Release 2 Oracle HTTP Server 概要 2002 年 9 月

著書: Oracle HTTP Server Team Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com オラクル社は、インターネットを強化するソフトウェアを提供します。 Oracle はオラクル社の登録商標です。ここに記載した各種製品およびサービスの名称は、オラクル社の商標である場合があります。ここに記載した他のすべての製品とサービスの名称は、その所有権者の商標である場合があります。