| Oracle Application Server WebSphereからの移行 10g リリース3（10.1.3.1.0） B31845-02 |
|
 戻る |
 次へ |
WebSphere 3.5.3とOracle Application Serverは、まったく異なるアーキテクチャから作成されています。WebSphereは、IBM SanFrancisco Javaアプリケーション・フレームワークとそのComponent Broker（両方ともJ2EE規格に先行）に基づいています。Oracle Application Serverには、J2EE 1.3標準APIをサポートする軽量で堅牢な新しいJ2EEコンテナが含まれています。
この章では、全体的な製品機能、アーキテクチャ、クラスタリングとロード・バランシング、J2EEのサポート、および開発ツールとデプロイ・ツールの観点から、WebSphereとOracle Application Serverの主な相違点について説明します。
この項では、WebSphere製品とOracle Application Server製品について説明と比較を行います。
WebSphere 3.5.3の場合、IBM社では、WebSphereというマーケティング上の分類で、いくつかのテクノロジを販売しています。WebSphere Application Serverは、多彩なWebSphereファミリ製品の中核となるもので、後続の3つの項で説明する3つのバージョンで構成されています。
WebSphere Standard Editionは、HTTPサーバー上で動作するサーブレットおよびJSPコンテナ・レイヤーです。これは、IBM HTTP Server、Microsoft IISおよびNetscape iPlanetサーバーなど、一般に広く使用されている多くのHTTPサーバーとともに動作します。WebSphere Standard Editionでは、静的HTMLページ、サーブレットJavaServer PagesおよびXMLをサポートしています。
WebSphere Standard Editionは、HTTPサーバー上で動作するサーブレットおよびJSPコンテナ・レイヤーです。これは、IBM HTTP Server、Microsoft IISおよびNetscape iPlanetサーバーなど、一般に広く使用されている多くのHTTPサーバーとともに動作します。WebSphere Standard Editionでは、静的HTMLページ、サーブレットJavaServer PagesおよびXMLをサポートしています。
WebSphereと同様に、Oracle Application Serverは、インターネットおよびイントラネット用にWeb対応の多層エンタープライズ・アプリケーションをホスティング可能で、ブラウザおよびスタンドアロン・クライアントからアクセス可能な、プラットフォームに依存しないJ2EEアプリケーション・サーバーです。Oracle Application Serverには、Javaで記述された軽量でスケーラブルなJ2EEコンテナであるOracle Containers for J2EE（OC4J）が含まれています。また、Oracle Application Serverは、J2EE 1.3での動作が保証されています。 OC4Jでのサポート対象は次のとおりです。
サーブレット2.4
JSP 2.0
EJB 2.1および3.0（EJB 3.0およびJPAの完全な実装）
JMX 1.2
Oracle Application Serverは、特にインターネット商用サイト、エンタープライズ・ポータルおよび大容量トランザクション・アプリケーションなどの大規模な分散Javaエンタープライズ・アプリケーションを実行する目的で設計されています。Oracle Application Serverによって、実際のアプリケーションの実装に不可欠な領域にJ2EE標準を超える多くの機能が追加されます。この場合、次の機能を含む一連の統合ソリューションが提供されます。
これらのソリューションを信頼性の高いスケーラブルなインフラストラクチャに実装するために、クラスタリング・メカニズムを使用した冗長アーキテクチャにOracle Application Serverをデプロイできます。Oracle Application Serverのコンポーネントおよび特性の詳細は、この章の「アーキテクチャの比較」および「高可用性およびロード・バランシング」を参照してください。
この項では、WebSphereとOracle Application Serverのアーキテクチャについて説明と比較を行います。
WebSphere Advanced Edition 3.5.3は、次のコンポーネントで構成されています。
IBM社のHTTP Serverは、Apache HTTP Server（正式な製品サポートのあるもの）に、IBM実装のSSL機能と、キーや証明書などのIBM管理ツールを組み込んだものです。SSLで使用される公開鍵テクノロジは特許を取得しているため、ライセンス交付用のトラッキングが必要になります。SSLサポートは、配布されているApache HTTP Serverオープン・ソースに、IBMが付加した価値の一部です。ApacheとIBMどちらのHTTP Serverも、すぐに利用可能なサーブレット・サポートは備えていません。
Webサーバー・プラグインは、ネイティブAPIを使用してWebサーバー内で動作し、WebSphere Application Serverにリクエストを転送するモジュールです。WebSphereをインストールすると、インストール・プログラムによってWebサーバーにフックがインストールされます。このフックによって、サーブレットをターゲットとするHTTPリクエストが傍受され（着信URLに基づいて、サーブレット・リクエストかどうかが判断されます）、それらのリクエストはサーブレット・エンジンにリダイレクトされて処理されます。静的コンテンツは、そのままHTTP Serverのみで処理されます。
WebSphere Application Serverコンポーネントを実行するすべてのノードで、管理サーバーを実行している必要があります。実行される機能は次のとおりです。
構成されているすべてのアプリケーション・サーバーの起動、停止および監視
セキュリティ・サーバーの提供
障害発生時に管理サーバーを再起動する監視プロセスの提供
WebSphere Application Serverバージョン3.5.xでは、管理サーバー・リポジトリが必要です。管理サーバー・リポジトリは、構成情報を格納するリレーショナル・データベースです。このデータベースは、WebSphere Application Serverのセットアップ、構成および状態に関する情報の格納に使用されます。
管理サーバーを起動する前に、管理サーバー・リポジトリが存在するかどうかが、WebSphere Application Serverによって確認されます。このリポジトリには、アプリケーション・サーバーの名前、各サーバーが実行されているノード、各サーバーにインストールされているEnterprise Bean、各サーバーの現在の状態など、ドメイン内の各ノードでの実行用に構成されたリソースに関する記述情報が格納されます。
管理サーバー・リポジトリによって、すべての構成情報が1箇所に格納されるため、システム管理者はドメインの管理作業をどのマシンからでも実行できます。各管理サーバーには、ドメインのリソース構成情報の集中ビューがあります。管理者がリソースの構成を変更すると、すべての管理サーバーにその変更内容が表示されます。
この項では、Oracle Application Serverに固有のコンポーネントおよびいくつかの概念について説明します。
|
関連項目: 『Oracle Application Server概要』 『Oracle Application Server管理者ガイド』 『Oracle Application Server Containers for J2EEユーザーズ・ガイド』 |
OracleASインスタンスは、Oracle Application Serverインストールの実行時に生成されます。Oracle Application ServerインストールはOracleホームに対応しており、ここにOracle Application Serverファイルがインストールされます。各Oracle Application Serverインストールで実行時に提供されるOracleASインスタンスは1つのみです。1つの物理ノードに複数のOracleホームを保持できるため、複数のOracle Application Serverインストールおよび複数のOracleASインスタンスを使用できます。
各OracleASインスタンスは、相互運用される複数のコンポーネントで構成されています。Oracle Application Serverでは、これらのコンポーネントによって、ユーザー・リクエストを信頼性の高いスケーラブルな方法で処理できます。これらのコンポーネントには、次のものがあります。
OracleASには、2つのリスナーが含まれています。Apacheオープン・ソース・プロジェクトに基づくOracle HTTP Serverおよび個別の実行スレッドで実行されるOC4Jの一部であるリスナーの2つです。各OracleASインスタンスに、1つのOracle HTTP Serverが含まれています。
OC4Jリスナーは、Oracle HTTP Serverのmod_oc4jモジュールからのリクエストをリスニングして適切なOC4Jインスタンスに転送します。機能の点から見ると、Oracle HTTP Serverは、OC4Jに対するプロキシ・サーバーとして動作します。Oracle HTTP Serverによって、すべてのサーブレット・リクエストまたはJSPリクエストがOC4Jインスタンスにリダイレクトされます。
mod_oc4jは、Apache JServ Protocolバージョン1.3（AJP 1.3）を使用してOC4Jリスナーと通信します。また、Oracle HTTP ServerのApacheモジュールとして動作します。OC4Jリスナーでは、AJP 1.3リクエストのみでなく、HTTPリクエストおよびRMIリクエストも受信できます。
次の図に、OracleASの単一インスタンス内のOracle HTTP Serverおよびその他のOracle Application Serverのランタイム・コンポーネントを示します。
OC4Jインスタンスは、Oracle Application Server内に論理的にインスタンス化されたOC4J実装です。この実装は、Java 2 Enterprise Edition（J2EE）に基づいており、すべてJavaで記述されています。OC4Jインスタンスは、OracleASとともにインストールされる標準のJava Development Kit（JDK）1.4のJava仮想マシン上で動作します（JDK 1.3もサポートされています）。OC4Jインスタンスで使用されるディスクおよびメモリーのフットプリントは、以前のOracle Application ServerのJava環境および競合するJavaアプリケーション・サーバーより少なくなっています。各OC4Jインスタンスは複数のJVMプロセスで構成でき、各JVMプロセスでは複数のJ2EEコンテナを実行できます。JVMプロセスの数は、Oracle Enterprise Manager 10g Application Server ControlコンソールのGUIを使用してOC4Jインスタンスごとに指定できます。
Oracle Application Serverでは、スケーラビリティおよび高可用性を実現する目的で、複数のOC4Jインスタンスをまとめてクラスタリングできます。OC4Jインスタンスをまとめてクラスタリングすると、インスタンス全体に同じ構成およびアプリケーションがデプロイされます。クラスタリングの詳細は、「高可用性およびロード・バランシング」を参照してください。
各OracleASインスタンスには、そのインスタンス内で監視機能およびプロセス管理機能を実行するOPMNサービスが1つ含まれています。このサービスは、OracleASインスタンスのコンポーネント間でメッセージ通信を行うことで、コンポーネントの起動、停止検出およびリカバリを可能にします。この通信は、同じクラスタに属する他のOracleASインスタンス内の別のOPMNサービスにも拡張されるため、クラスタ内の各インスタンスで、（同じクラスタ内の）他のOracleASインスタンスのアクティブなOC4JおよびOracle HTTP Serverのプロセスを認識できます。
また、OPMNサービスは、Application Server Controlコンソールと通信し、そのインタフェースとなることで、Oracle Application Serverを監視、構成および管理するための統合インタフェースとして機能します。Oracle Application Serverコンポーネント、Oracle HTTP Server、OC4JインスタンスおよびDistributed Configuration Manager（次の項を参照）は、サブスクライブ/パブリッシュ型のメッセージ・メカニズムを使用してOPMNサービスと通信します。フェイルオーバーおよび可用性に対応するために、OPMNサービスを実装するプロセスには、障害が発生した場合にOPMNプロセスを再起動するシャドウ・プロセスが含まれています。
各OracleASインスタンスには、インスタンス内の様々なコンポーネントの構成変更を管理および追跡するためのタスクを実行するDCMプロセスが存在します。OracleASインスタンスのコンポーネントに構成変更が行われるたびに、その変更がDCMに伝達されます。DCMによって、その変更が認識され、インフラストラクチャ・データベースのOracle Application Server Metadata Repositoryに記録されます。このリポジトリには、個々のDCMを介してリポジトリに接続しているすべてのOracleASインスタンスの構成情報が含まれています。この方法で同じインフラストラクチャ・リポジトリに接続しているすべてのOracleASインスタンスは、同じOracleAS Farmに属します。いずれかのOracleASインスタンスで障害が発生すると、インスタンスを再起動するためにリポジトリから構成情報が取得されます。
各DCMは、個々のインスタンスのOPMNとも通信し、リポジトリ・データ内の変更に関する通知イベントを送信します。これによって、OPMNでは、Oracle Application Serverコンポーネントを適切に調整できます。
OracleASでは、静的なWebコンテンツと動的に生成されたWebコンテンツの両方をキャッシュする独自の機能を備えたキャッシュ・ソリューションが提供されています。Oracle Web Cacheによって、Webサーバーへのラウンドトリップ数が減少するため、負荷の高いOracle Application Server Webサイトのパフォーマンスおよびスケーラビリティが大幅に向上します。また、Web Cacheでは、一貫性のある予測可能なレスポンスを実現するための多くの機能が提供されています。これらの機能には、ページの部分的なキャッシュ、コンテンツの動的組立て、Webサーバーのロード・バランシング、Web Cacheクラスタリングおよびフェイルオーバーなどがあります。Oracle Web Cacheは、クラスタ内でOracleASインスタンスのロード・バランサとして使用できます。Oracle Web Cacheのクラスタには、Oracle Web Cache自体をデプロイできます。詳細は、『Oracle Application Server Web Cache管理者ガイド』を参照してください。
Oracle Enterprise Manager 10g Application Server Controlコンソールでは、Oracle Application Serverのコンポーネントおよびアプリケーションを管理するためのWebベースのインタフェースが提供されています。Application Server Controlコンソールを使用すると、次のタスクを実行できます。
OracleASコンポーネント、OracleAS中間層インスタンス、インフラストラクチャ・インスタンス、OracleAS中間層クラスタ、およびデプロイ済J2EEアプリケーションとそのコンポーネントの監視
Oracle Application Serverのコンポーネント、インスタンス、クラスタ、およびデプロイ済アプリケーションの構成
OracleASのコンポーネント、インスタンス、クラスタ、およびデプロイ済アプリケーションの操作
OracleASのコンポーネントおよびデプロイ済アプリケーションのセキュリティ管理
Oracle Enterprise Managerおよびその2つのフレームワークの詳細は、Oracle Enterprise Manager 10g のドキュメントを参照してください。
|
関連項目: Application Server Controlコンソールおよびその使用方法については、『Oracle Application Server管理者ガイド』を参照してください。 |
Oracle Application Server 10g では、インフラストラクチャの役割が以前のバージョンから拡張されています。このバージョンでは、エンタープライズ・アプリケーションの開発およびデプロイのために完全に統合されたフレームワークが提供されています。OracleAS Infrastructureインストール・タイプでは、製品メタデータ・サービス、セキュリティ・サービス、管理サービス、およびOracleAS中間層の構成リポジトリとデータ・リポジトリの集中管理が提供されます。中間層で必要なインフラストラクチャ・サービスを統合することで、エンタープライズ・アプリケーションの開発に必要な時間および作業が削減されます。同時に、これらのアプリケーションの開発およびデプロイにかかる合計コストが削減され、デプロイされたアプリケーションの信頼性も向上します。
OracleAS Infrastructureでは、次の総合サービスが提供されます。
製品メタデータ・サービス
OracleAS Infrastructureには、OracleAS中間層インスタンスで必要なすべてのアプリケーション・サーバー・メタデータが格納されます。このデータはOracleデータベースに格納されるため、データベースの堅牢性が利用され、信頼性、スケーラビリティおよび管理性に優れたメタデータ・リポジトリが提供されます。
セキュリティ・サービス
セキュリティ・サービスによって、OracleASにデプロイされたすべてのアプリケーションに対して、一貫性のあるセキュリティ・モデルおよびID管理機能が提供されます。また、シングル・サインオン、Webベースの管理、およびユーザー認証資格証明の集中格納による認証の集中管理が可能になります。Oracle Internet Directoryは、このサービスの基礎となるリポジトリとして使用されます。
管理サービス
このサービスは、Oracle Enterprise ManagerおよびDCMでOracleAS中間層インスタンスおよびOracleAS Infrastructureを管理するために使用されます。また、中間層のクラスタリング・サービスを管理するためにも使用されます。Oracle Enterprise Managerでは、OracleASの統合管理用のWebページを備えたOracleASコンソールを介してデプロイ済J2EEアプリケーションを集中管理することで、全体の管理コストが削減されます。
前述のサービスを実装するOracleAS Infrastructureのコンポーネントには、次のものがあります。
Oracle Application Serverのメタデータ、カスタマ・データまたはアプリケーション・データは、Oracle Application Server Metadata Repositoryに共存することができます。ただし、アプリケーションによって、アクセスできるデータは異なります。
Oracle Application Server Metadata Repositoryには、この項で前述した3つの主なインフラストラクチャ・サービスに対応する3つの主なタイプのメタデータが格納されます。これらのメタデータ・タイプは次のとおりです。
管理メタデータ
セキュリティ・メタデータ
製品メタデータ
表2-1に、アプリケーションのデプロイ時にこれらのタイプのメタデータを格納および使用するOracle Application Serverコンポーネントを示します。
表2-1 メタデータおよびインフラストラクチャ・コンポーネント
Oracle Application Server Metadata Repositoryは、「J2EE and Web Cache」インストール・オプションを使用する場合を除き、すべてのアプリケーションのデプロイに必要です。Oracle Application Serverには、次の3つの中間層インストール・オプションがあります。
J2EE and Web Cache: Oracle HTTP Server、OC4J、Oracle Web Cache、Webサービス、データタグおよびOracle Enterprise Manager 10g Application Server Controlコンソールがインストールされます。
Portal and Wireless: J2EEのすべてのコンポーネント、Oracle Web Cache、UDDI、Oracle Application Server Portal、Oracle Application Server Syndication Services、Oracle Ultra SearchおよびOracle Application Server Wirelessがインストールされます。
Business Intelligence and Forms: J2EEのすべてのコンポーネント、Oracle Web Cache、Oracle Application Server Portal、Oracle Application Server Wireless、Oracle Application Server Forms Services、Oracle Reports、Oracle Business Intelligence DiscovererおよびOracle Application Server Personalizationがインストールされます。
Oracle Application Server Business Activity Monitoring、Oracle Application Server Integration InterConnect、Oracle Workflowなどの統合コンポーネントは、これらの中間層インストール・オプションのいずれかに追加する形でインストールされます。
「Portal and Wireless」および「Business Intelligence and Forms」インストール・オプションの両方では、DCMコンポーネントによって、中間層管理が有効にされ、そのメタデータがメタデータ・リポジトリに格納されます。「J2EE and Web Cache」インストール・タイプでは、DCMによって、デフォルトでファイル・ベースのリポジトリが使用されます。「J2EE and Web Cache」インストール・タイプをインフラストラクチャに関連付けると、ファイル・ベースのリポジトリがメタデータ・リポジトリに移動されます。
|
関連項目: OracleASインストールの詳細は、Oracle Application Server 10g のインストレーション・ガイドを参照してください。 |
Oracle Identity Managementによって、Oracle Application Server内のアプリケーションおよびエンティティのセキュリティ・ライフ・サイクル用のインフラストラクチャが提供されます。Oracle Identity Managementは、次のコンポーネントで構成されています。
Oracle Internet Directory
Oracle Internet Directoryは、Oracleによって実装された、Lightweight Directory Access Protocol（LDAP）バージョン3を使用するディレクトリ・サービスです。このコンポーネントは、Oracleデータベースのアプリケーションとして実行されるため、データベースの優れたパフォーマンス、スケーラビリティおよび高可用性を利用できます。
Oracle Internet Directoryによって、他のOracle Application Serverコンポーネント（OC4J、Oracle Application Server Portal、Oracle Application Server Wirelessなど）に対してユーザーを作成および管理するための集中型リポジトリが提供されます。ユーザーの認可および認証を集中管理することで、ユーザーをOracle Internet Directoryで集中的に定義し、すべてのOracle Application Serverコンポーネントで共有できます。
Oracle Internet Directoryには、Javaベースの管理ツール（Oracle Directory Manager）、信頼できるプロキシ・ベースの管理用のWebベースの管理ツール（Oracle Delegated Administration Services）、および複数のコマンドライン・ツールが付属しています。Oracle Delegated Administration Servicesによって、Oracle Internet Directory管理者以外の委任管理者がOracle Application Server環境のエンド・ユーザーをプロビジョニングする手段が提供されます。また、この機能によって、エンド・ユーザーが自身の属性を変更することもできます。
Oracle Internet Directoryによって、Oracle Application Serverコンポーネントでユーザーおよびグループ・イベントに関するデータを同期させることもできるため、それらのコンポーネントで、ローカル・アプリケーション・インスタンスに格納されている任意のユーザー情報を更新することができます。
Oracle Virtual Directory
Oracle Virtual Directoryによって、既存のIDインフラストラクチャへのアプリケーションの統合が簡単になります。Oracle Virtual Directoryによって、既存のディレクトリまたはユーザー・リポジトリを変更する必要なくこの統合を実現できるため、企業では、データの所有権および表現形式の問題を考慮する必要なくこれらのサービスを迅速にデプロイできます。また、Oracle Virtual Directoryでは、個々のアプリケーションに固有の要件に応じて最適化された、ディレクトリ情報に関するアプリケーション中心の複数のビューも提供されます。
この項では、クラスタリングとロード・バランシング、およびアプリケーション・サーバーを使用する場合のこれらの機能の重要性を定義および説明し、WebSphereとOracle Application Serverで使用される（主にクラスタリングを使用した）高可用性およびロード・バランシングの方法を比較します。
WebSphereでは、Administrative Consoleを介して、クローニング・サービスとワークロード管理サービスにより、クラスタリングとロード・バランシングをサポートしています。
WebSphereでは、クラスタリングは、管理システムで使用可能なクローニングによって実行されます。クローニングでは、構成済のサーバーに基づいて、アプリケーション・サーバーの複数のコピーを作成できます。
クローンは、そのコピー元のアプリケーション・サーバーの構造と属性をそのまま受け継ぎますが、どのノードにも関連付けられず、それぞれのノードで実行されている実際のサーバー・プロセスにも対応しません。
WebSphere Application Serverでは、サーブレット・エンジン、Webアプリケーション、およびワークロード管理、ロード・バランシング、フェイルオーバー用のクローニングがサポートされています。サーブレット、EJBおよびWebリソースはクローン間で共有されますが、アプリケーション・コードの実行には、それぞれのクローンで固有のJVMが使用されます。そのため、同一でありながら、独立したプロセスがアプリケーションの実行場所として提供されます。
ワークロード管理サービスでは、複数のアプリケーション・サービスをアプリケーション・サーバー・グループにグループ化することによって、アプリケーション・サーバー環境のスケーラビリティが向上します。このようなアプリケーション・サーバー・グループに対して、クライアントは単一のサーバーであるようにアクセスし、ワークロード管理サービスによって、同じグループ内のアプリケーション・サーバー間でワークロードが分散されます。1つのアプリケーション・サーバーは、1つのアプリケーション・サーバー・グループにしか組み込めません。WebSphereのワークロード管理では、ステートレス・サーブレットおよびステートレス・セッションBeanに対するロード・バランシングが可能であり、またステートフル・サーブレットおよびステートフル・セッションBeanに対するフェイルオーバー・メカニズムが用意されています。
サーブレットのロード・バランシングは、サーブレット・リダイレクタによって実行されます。サーブレット・リダイレクタは、アプリケーション・サーバーの前のWebサーバーで実行されます。リダイレクタによって、Webサーバーの背後にある複数のアプリケーション・サーバーで実行されているサーブレット・エンジン間で、ワークロードが分散されます。WebサーバーのHTTPセッションからサーブレットの起動が要求されると、リダイレクタによって、そのリクエストがサーブレット・エンジンに転送されます。
EJBコンポーネントのワークロード・マネージャでは、Javaオブジェクト間で負荷が分散されます（サーブレットからEJBコンポーネント、EJBコンポーネントからEJBコンポーネント、およびスタンドアロンのJavaクライアントからEJBコンポーネントに分散）。たとえば、EJBコンポーネントを通じて、サーブレットがデータを要求したり、トランザクションを開始すると、そのEJBコンポーネントのワークロード・マネージャによって、EJBコンテナ（WebSphere Application Serverのインスタンス）またはリモートのEJBハンドラに、リクエストが転送されます。
Oracle Application Serverは、複数の高可用性およびロード・バランシングのメカニズムを使用して設計されています。これらのメカニズムによって、インフラストラクチャ・レベルおよび中間層レベルでのフェイルオーバーおよびスケーラビリティが実現されます。フェイルオーバーの場合は、OracleASの類似コンポーネントのクラスタを作成できます。これらのクラスタによって、類似コンポーネントに冗長性が提供されます。
この項では、Oracle Application Server内の該当するコンポーネントのクラスタリングおよびロード・バランシングの概念と機能について説明します。
|
関連項目: 『Oracle Application Server高可用性ガイド』 |
Oracle Application Serverアーキテクチャでは、中間層での高可用性がサポートされています。多くの場合、この高可用性によってデプロイ済アプリケーションの計画外停止時間を回避できます。この項では、Oracle Application Serverインスタンスのアーキテクチャの概要、および中間層の高可用性機能の一部について説明します。
各Oracle Application Serverインスタンス内の次の機能によって、そのインスタンス内の高可用性およびそのインスタンスが属するクラスタの高可用性が実現されます。
プロセス監視: Oracle Process Manager and Notification Serverシステムを使用することによって、監視対象プロセスで問題が検出された場合、プロセス停止の検出およびプロセスの再起動が行われます。
構成クローニング: 構成情報用にOracle Application Server Metadata Repositoryを使用するDistributed Configuration Management機能を使用することによって、Oracle Application Serverインスタンスおよびクラスタの一部であるOracle Application Serverインスタンスに、分散および管理された構成が提供されます。
データ・レプリケーション: Webアプリケーション・レベルのステートフル・セッション・レプリケーションを提供するOC4Jアイランドが含まれているOC4JインスタンスおよびEJBセッションを使用することによって、単一のOracle Application Serverインスタンス内の複数のプロセス全体、および異なるホストに存在する異なるOracle Application Serverインスタンス全体（Oracle Application Serverクラスタを使用している場合）にデータがレプリケートされます。これによって、Oracle Application Serverインスタンス内のプロセスが使用できなくなるか、またはそのプロセスで障害が発生した場合でも、ステートフル・セッション・ベースのアプリケーションを使用可能な状態にしておくことができます。
スマート・ルーティング: Oracle Web CacheおよびOracle HTTP Server（mod_oc4j）によって、受信リクエスト用の構成可能なインテリジェント・ルーティング機能が提供されます。リクエストは、Oracle Process Manager and Notification Serverシステムとの通信を介してmod_oc4Jでアクティブであると確認されたプロセスおよびコンポーネントにのみルーティングされます。
Oracle Application Serverクラスタ（OracleASクラスタ）は、1つ以上のOracleASインスタンスで構成されています（図2-3を参照）。クラスタ内のすべてのOracleASインスタンスで同じ構成が使用されます。最初にクラスタに追加されたOracleASインスタンスの構成が、2番目以降に追加されるインスタンスにレプリケートされます。構成のみでなく、デプロイ済OC4Jアプリケーションも新しいインスタンスにレプリケートされます。レプリケートされる構成およびアプリケーションの情報は、クラスタで使用されるOracleAS Metadata Repositoryから取得されます。
各クラスタ内に、OracleASインスタンスのロード・バランシングまたはフェイルオーバーを実行するメカニズムはありません。つまり、クラスタには、インスタンス内のOracle HTTP Serverコンポーネントに対するリクエストのロード・バランシングまたはフェイルオーバーを実行する内部メカニズムは存在しません。クラスタ内のOracleASインスタンスのロード・バランシング、およびクラスタ内のOracle HTTP Serverインスタンスのフェイルオーバーは、Oracle Web Cacheやハードウェアのロード・バランシング製品などの個別のロード・バランサを使用して実行できます。
複数のOracleASクラスタおよびスタンドアロンOracleASインスタンスは、さらにOracleAS Farmにグループ化できます。このファーム内のクラスタとインスタンスは、同じOracleAS Metadata Repositoryを共有します。OracleAS Farmの詳細は、『Oracle Application Server管理者ガイド』を参照してください。
図2-3 ロード・バランシングにOracleAS Web Cacheを使用するOracleASクラスタ
Oracle Application Serverのクラスタリング・テクノロジの重要な機能の1つに、マルチキャスト・トラフィックを削減する機能があります。クラスタ内のすべてのサーバーが他のすべてのサーバーとセッション状態を共有する環境では、クラスタ内のすべてのノードにセッション状態をレプリケートする場合にオーバーヘッドとして多くのCPUサイクルが使用されます。Oracle Application Serverでは、OC4Jアイランドの概念を導入することによってこの問題が解決されています。OracleASクラスタ内のOC4Jプロセス（JVM）は、複数のアイランドにサブグループ化できます。アプリケーションのセッション状態は、OracleASクラスタ内のすべてのOC4Jプロセスにではなく、同じアイランドに属するOC4Jプロセスにのみレプリケートされます。このため、セッション状態がレプリケートされるプロセスの数は少なくなります。通常、OC4Jアイランドは、複数の物理ノードにまたがって構成されているため、1つのノードが停止した場合でもアプリケーション状態をフェイルオーバーできます。
2つのノードで4つのOC4Jプロセスが実行されている（各ノードで2つのプロセスが実行されている）OracleASクラスタについて考えてみます（図2-4を参照）。アプリケーションの状態が変化した場合（この変化は同じクライアントからリクエストが到着するたびに発生する可能性があります）、4つのすべてのプロセス間でマルチキャスト・メッセージが送信され、そのアプリケーションの状態が各プロセスで更新されます。これらの4つのプロセスを、2つのノードにまたがって、2つのプロセスで構成されている2つのアイランドに分割すると、アプリケーションの状態のレプリケーションは、同じアイランド内のプロセス間でのみ発生することになります。マルチキャスト・メッセージは4つのプロセスではなく、同じアイランド内の2つのプロセス間でのみ必要とされるため、レプリケーションのオーバーヘッドが半分に削減されます。その結果、ネットワーク・トラフィックおよびCPUサイクルが削減されます。
OC4Jアイランドの構成時、各アイランドに属するOC4Jプロセスの数をノードごとに指定できます。これによって、各ノードのハードウェアおよびオペレーティング・システムの性能に基づいてプロセスの数を増減できます。OracleASクラスタおよびOC4Jアイランドの構成方法の詳細は、『Oracle Application Server高可用性ガイド』を参照してください。
OC4Jを使用して、1つのアプリケーション・サーバー・インスタンス内で実行されているOC4Jプロセス全体またはOracleASクラスタ全体で状態のレプリケーションが行われるようにステートフル・セッションEJBを構成できます。このEJBレプリケーション構成では、複数のOC4Jプロセスを使用して同じステートフル・セッションEJBのインスタンスを実行することによって、ステートフル・セッションEJBに高可用性が提供されます。
EJBクラスタによって、ステートフル・セッションEJBに高可用性が提供されます。この場合、同じマルチキャスト・アドレスで通信する複数のOC4Jプロセス間でこれらのEJBをフェイルオーバーできます。したがって、ステートフル・セッションEJBでレプリケーションを使用すると、プロセス障害とノード障害に対する保護、およびOracle Application Serverで実行されているステートフル・セッションEJBの高可用性を実現できます。
|
関連項目:
|
EJBクラスタリングが有効になっている場合は、OracleASクラスタ内のOC4Jインスタンス間でJNDIネームスペース・レプリケーションも有効になります。いずれかのOC4JインスタンスのJNDIネームスペースに新しくバインドすると、OracleASクラスタ内の他のOC4Jインスタンスに伝播されます。リバインドおよびアンバインドはレプリケートされません。
レプリケーションは、OC4Jアイランドの有効範囲外で行われます。つまり、OC4Jインスタンスの複数のアイランドで、レプリケートされた同じJNDIネームスペースを認識できます。
|
関連項目: 『Oracle Containers for J2EEサービス・ガイド』 |
Oracle Application Server Java Object Cacheでは、分散キャッシュが提供されています。分散キャッシュは、OC4Jにデプロイされたアプリケーションに対する高可用性ソリューションとして機能します。Java Object Cacheは、Javaオブジェクトのインプロセス・キャッシュで、任意のJavaプラットフォーム上の任意のJavaアプリケーションで使用できます。Java Object Cacheを使用すると、アプリケーションで、リクエスト間およびユーザー間でのオブジェクトの共有、およびプロセス間でのオブジェクトのライフ・サイクルの調整を実行できます。
Java Object Cacheでは、各OC4Jプロセスが同じOC4Jアイランド、アプリケーション・サーバー・インスタンスまたはOracle Application Serverクラスタに属していない場合でも、それらのOC4Jプロセス間でのデータ・レプリケーションを実行できます。
Java Object Cacheを使用すると、オブジェクトを生成するアプリケーションに関係なく、共有Javaオブジェクトがローカルにキャッシュされるため、パフォーマンスを向上できます。また、可用性も向上します。オブジェクトのソースが使用できなくなった場合でも、ローカルにキャッシュされたバージョンを使用できるためです。
2つ以上のOracle Web Cacheインスタンスをまとめてクラスタリングし、単一の論理キャッシュを作成できます。物理的には、キャッシュを複数のノードに分散できます。いずれかのノードで障害が発生した場合でも、そのノードで処理されていたリクエストを同じクラスタ内の残りのノードによって実行できます。障害は、障害が発生したメンバーのキャッシュ可能なコンテンツの所有権を継承する、クラスタ内の残りのノードによって検出されます。リクエストは、Oracle Web Cacheクラスタの前に配置されたロード・バランシング・メカニズム（ハードウェアのロード・バランシング機器など）によって、障害の影響を受けていないOracle Web Cacheノードにリダイレクトされます。
Oracle Web Cacheクラスタによって、OracleASインスタンスの可用性も向上します。OracleASインスタンスの前に静的および動的コンテンツをキャッシュすることによって、Oracle Web Cacheでリクエストを処理できるため、（特にOracle HTTP Serverに対して）OracleASインスタンスでリクエストを実行する必要性が低くなります。OracleASインスタンスに対する負荷およびストレスが削減されるため、インスタンス内のコンポーネントの可用性が向上します。
Oracle Web Cacheは、Oracle HTTP Serverに対してステートレスまたはステートフルなロード・バランシングの役割を果たすこともできます。ロード・バランシングは、各Oracle HTTP Serverの使用可能な容量の割合、つまり、各Oracle HTTP Serverの重み付けされた使用可能な容量に基づいて実行されます。重み付けされた使用可能な容量が複数のOracle HTTP Serverで等しい場合、Oracle Web Cacheでは、負荷の分散にラウンドロビン法が使用されます。重み付けされた使用可能な容量の計算式については、『Oracle Application Server Web Cache管理者ガイド』を参照してください。
いずれかのOracle HTTP Serverで障害が発生すると、Oracle Web Cacheによって、残りのOracle HTTP Serverに負荷が再分散され、オンライン状態に戻るまで障害が発生したサーバーが断続的にポーリングされます。その後、有効範囲内のオンライン状態に戻ったOracle HTTP Serverで負荷分散が再計算されます。
|
関連項目: 『Oracle Application Server Web Cache管理者ガイド』 |
OracleAS Infrastructureの高可用性を実現するためのいくつかのソリューションが存在します。これらのソリューションでは、サイト内フェイルオーバーを使用できます。これらのソリューションには、次のものがあります。
コールド・フェイルオーバー・クラスタ・ソリューションでは、同一の構成の2ノードのハードウェア・クラスタが提供されます。一方のノードがアクティブとなり、他方のノードがパッシブとなります。クラスタリング機能を備えたオペレーティング・システムで実行される2つのノード間には、ハードウェア・インターコネクトが存在します。これらのノードは、両方とも共通の共有記憶域にアクセスします。また、これらの2つのノード間では、単一の論理IPアドレスも共有されます。（各ノードには一意の物理IPアドレスも存在します。ただし、中間層では、単一の論理IPアドレスのみが認識可能で、この論理IPアドレスがコールド・フェイルオーバー・クラスタのインフラストラクチャにアクセスする場合に使用されます。）
OracleAS Infrastructureのインストール時、そのインストール用のOracleホームがデータベース・ファイルとともに共有記憶域にインストールされます。操作中は、常に1つのノードのみが共有記憶域にマウントされます。アクティブ・ノードで障害が発生すると、パッシブ・ノードのクラスタリング・ソフトウェアによってその障害が検出され、論理IPアドレスが継承されます。パッシブ・ノードがアクティブ・ノードになり、共有記憶域をマウントし、中間層からのリクエストを処理します。
コールド・フェイルオーバー・クラスタ・ノードは、中間層にインストールすることもできます。この場合のノードは、中間層ではアクティブ/アクティブ、Infrastructureではアクティブ/パッシブになります。
|
関連項目: 『Oracle Application Server高可用性ガイド』 |
コールド・フェイルオーバー・クラスタでは、インフラストラクチャにアクティブ/パッシブ可用性構成が提供され、Oracle Application Server Active Clusters（OracleAS Active Clusters）ソリューションでは、アクティブ/アクティブ可用性構成が提供されます。OracleAS Active Clustersソリューションは、Oracle9i Real Application Clustersテクノロジに基づいています。このソリューションによって、1つのクラスタ内で3つ以上のノードをアクティブにできます。また、各ノードの基礎となるハードウェアでは、ハードウェア・クラスタ・テクノロジも使用されます。ただし、IPアドレスの継承メカニズムは使用されません。かわりに、OracleAS Active Clustersノードに対するリクエストのロード・バランシングが行われるように、それらのノードの前にハードウェアのロード・バランサ機器が構成されます。このロード・バランサには、論理IP名およびアドレスが保持されています。これらの論理IP名およびアドレスは、中間層でインフラストラクチャにアクセスする場合に使用されます。Oracle Net接続では、クラスタ内のノードのアドレス・リストを使用することによって、このハードウェアのロード・バランサの使用が回避されます。いずれかのノードで障害が発生した場合は、ハードウェアのロード・バランサ機器とOracle Netの両方で、アクティブ・ノードに対するリクエストのフェイルオーバーが管理されます。
|
関連項目: 『Oracle Application Server高可用性ガイド』 |
この項では、WebSphereとOracle Application ServerのJ2EE仕様のサポート・レベルの相違点について説明します。
WebSphere 3.5.3はJ2EEサーバーですが、J2EE 1.2に完全準拠しているわけではありません。サポートしているJ2EE API仕様は、次のとおりです。
WebSphereはJ2EEに完全準拠しているわけではありません。J2EEの規格に対するカスタム拡張機能があり、サーブレットのフィルタリングとチェーン、セキュリティ、接続プーリングとデータ・アクセスBean、デプロイメント・ディスクリプタなどのJ2EEの機能をサポートする、非標準のパッケージを含んでいるためです。 これらの拡張機能やパッケージを使用するアプリケーションを、Oracle Application ServerなどのJ2EE準拠のアプリケーション・サーバーに移植するには、コード・レベルで変更する必要があります。
Oracle Containers for J2EE（OC4J）は、J2EE 1.3で完全に動作が保証されています。表2-2に、Oracle Application ServerおよびWebSphereで提供されているJ2EEテクノロジおよびそのサポート・レベルを示します。
表2-2 J2EEテクノロジ・サポート
| J2EEテクノロジ | WebSphere 3.5.3でサポートされているバージョン | Oracle Application Server 10g リリース3（10.1.3.1.0）でサポートされているバージョン |
|---|---|---|
|
JDK |
1.2.2 |
1.4および1.3 |
|
サーブレット |
2.1+ |
2.4 |
|
JSP |
1.0 |
2.0 |
|
EJB |
1.0+ |
2.1および3.0（EJB 3.0およびJPAの完全な実装） |
|
JDBC |
2.0 |
3.0 |
|
JNDI |
1.2 |
1.2 |
|
JTA |
1.0 |
1.0 |
|
JMS |
1.0 |
1.1 |
|
JavaMail |
なし |
1.2 |
|
JAF |
なし |
1.0.1 |
|
JAXP |
1.0.1 |
1.2 |
|
JCA |
1.0 |
1.5 |
|
JAAS |
1.0 |
1.0 |
|
注意: Oracle Application Server OC4Jは、JDK 1.4.1とともにインストールされます。ただし、今回のリリースのOracle Application Server 10g リリース3（10.1.3.1.0）では、OC4JはJDK 1.3.xでも動作します。 |
Oracle Application Serverでは、これらの標準サポートのみでなく、実際のJ2EEアプリケーションを構築するために綿密に設計された統合アーキテクチャが提供されています。これには、EJB用のJARファイル、サーブレットおよびJSP用のWebアーカイブ（WAR）、アプリケーション用のエンタープライズ・アーカイブ（EAR）などの標準のデプロイメント・アーカイブの実装が含まれます。これによって、サーバーの円滑な相互運用性が実現されます。
この項では、WebSphereとOracle Application Serverに付属しているJavaツールを比較します。
ここでは、WebSphereの開発環境、ツールおよびシステム管理コンソールについて説明します。
VisualAge for Javaは、J2EEアプリケーションを構築するためのIBMの統合開発環境（IDE）です。VisualAge for Javaでは、JSPページなどのサーバー・サイドJavaロジックに対して、リモートのデバッグがサポートされます。新たなServlet SmartGuideでは、サーブレット、JSPコンポーネントおよびHTMLプロトタイプが生成されるため、開発者は本番サーバーへのデプロイ前に、IDE内でコードをすばやくテストできます。IBM WebSphere Studioとの統合により、プロトタイプにコンテンツをすばやく追加できるため、プログラマやWeb開発者の生産性も向上します。またVisualAgeには、スタンドアロンのオブジェクト・リレーショナル・マッピング・ツールであるパーシスタンス・ビルダーも付属しています。
WebSphere Studioには、マルチプラットフォームのWebアプリケーションの作成、管理およびデバッグ用のツール・セットが用意されています。その機能は次のとおりです。
JavaServer Pages（JSP）、HTMLおよびDHTML向けのビジュアル・ページ・デザイナー
データベース・アプリケーション、問合せ、JavaBeansおよびサーブレットを作成するウイザード
EJB、サーブレットおよびWebアプリケーションのデプロイ
WebSphere Administrative Consoleには、WebSphereドメインを管理するためのGUIが用意されています。WebSphereドメインは、1つ以上のWebSphereインスタンスで構成されます（各インスタンスでは、1つ以上のアプリケーションが実行されます）。Administrative Consoleは、ドメインで実行されている管理サーバーのいずれかに接続します。また、ドメイン内のすべてのマシンの構成やランタイム状態の変更に使用できます。Administrative Consoleは、管理リポジトリの管理、アプリケーションのデプロイ、およびアプリケーションの構成に使用できます。
この項では、J2EEアプリケーションを作成するための開発ツールおよびデプロイメント・ツールについて説明します。これらのツールは、Oracle Developer Suiteの一部です。
アプリケーション開発者は、Oracle JDeveloperのツールを使用して、OC4JにデプロイするJ2EE準拠のアプリケーションを構築できます。JDeveloperは、Oracle Internet Developer Suite（多層Javaアプリケーションを作成するための機能をすべて備えた統合開発環境）のコンポーネントです。JDeveloperを使用すると、業界標準モデルに基づいて、Javaクライアント・アプリケーション、動的HTMLアプリケーション、Webサーバー・コンポーネント、アプリケーション・サーバー・コンポーネント、およびデータベース・ストアド・プロシージャを開発、デバッグおよびデプロイできます。JDeveloperでは、多層Javaアプリケーションの作成に次の機能を利用できます。
Webアプリケーションの開発
Javaクライアント・アプリケーションの開発
Java in the Database
JavaBeansによるコンポーネント・ベースの開発
簡略化されたデータベース・アクセス
ビジュアル統合開発環境
J2EE 1.3の全面サポート
.earファイル、.warファイル、EJB JARファイルおよびデプロイメント・ディスクリプタの自動生成
Oracle JDeveloperでアプリケーションを構築し、Application Server Controlコンソールを使用してそれらのアプリケーションを手動でデプロイできます。また、JDeveloper以外の開発ツールでアプリケーションを構築することもできます。IBM VisualAgeまたはBorland JBuilderで構築したアプリケーションもOC4Jにデプロイできます。
|
注意: Oracle Application Serverには、JDeveloper以外にオブジェクト・リレーショナル・マッピング・ツールであるOracle TopLinkも付属しています。詳細は、『Oracle TopLink開発者ガイド』を参照してください。 |
Oracle Application Serverでは、J2EEアプリケーションの構成およびパッケージ化のための様々なアセンブリ・ツールが提供されています。これらのツールによる出力は、OC4J固有ではなく、J2EE標準に準拠しています。 提供されているツールには、次のものがあります。
Oracle Application Serverでは、OC4Jを構成、監視および管理するための次の2つの異なる管理機能が提供されています。
Oracle Enterprise Manager 10g Application Server Controlコンソールに統合されたグラフィカルな管理コンソール。これによって、OracleASクラスタ、ファームおよびOC4Jコンテナ全体を一元管理できます。
コマンド・プロンプトから管理タスクをローカル実行またはリモート実行するコマンドライン・ツール。Oracle Enterprise Manager 10g Application Server Controlコンソールのほうが、このコマンドライン・ツールより統合性の高い管理サービス・セットを提供できるため、管理環境としてはApplication Server Controlコンソールを使用することをお薦めします。
