| Oracle Fusion Middleware Java EEアップグレード・ガイド 11g リリース1（11.1.1） B55925-01 |
|
 戻る |
 次へ |
過去のリリースでは、Oracle Application ServerにOracle Containers for Java EE（OC4J）が含まれており、OC4JがJava EEアプリケーションの開発、デプロイおよび管理に使用する業界標準のコンテナを提供していました。
Oracle Fusion Middleware 11g では、OC4JがOracle WebLogic Serverに置き換えられました。
そのため、Oracle Fusion Middlewareの中核となるアーキテクチャは、1つの管理サーバーと1つ以上の管理対象サーバーで構成されるWebLogic Serverドメインを中心として構築されています。
詳細は、次の項を参照してください。
次の項では、OC4JユーザーがOracle WebLogic Serverへのアップグレードを準備する際に知っておく必要のある主な概念について説明します。
OC4JとOracle WebLogic Serverのトポロジを比較する場合は、次の2つの基本的なトポロジを検討できます。
図3-1は、一般的なスタンドアロンのOC4JインスタンスとスタンドアロンのOracle WebLogic Serverドメインの比較を示しています。 いずれの場合も、インスタンスやドメインへのHTTPリクエストは組込みHTTPリスナーによって処理されます。
Oracle WebLogic Serverの管理対象サーバーは、Oracle Application Server 10g で構成したOC4Jインスタンスに似ています。 ただし、WebLogic Serverでは、Oracle WebLogic Server管理コンソールをホストする専用の管理サーバーが常に提供されます。 管理コンソールでは、OC4Jの管理に使用するApplication Server Controlに似た、Oracle WebLogic Server用のWebベースの管理ツールが提供されます。
管理対象サーバーのない単純なOracle WebLogic Server開発ドメインも構成できます。 このような環境では、アプリケーションは管理サーバーにデプロイします。 ただし、通常、管理サーバーは管理コンソールのホスト専用であり、アプリケーションはドメイン内の1つ以上の管理対象サーバーにデプロイします。
図3-1 Oracle WebLogic ServerとOC4Jのスタンドアロン・アーキテクチャの比較
図3-2は、一般的なOracle Application Server 10g リリース2（10.1.2）の統合されたWebサーバーおよびOC4J中間層インストールと、Oracle Fusion Middleware 11g における同様のトポロジとの比較を示しています。
Oracle Fusion Middlewareでは、Web層とユーティリティのCD-ROMに格納されているインストールおよび構成ツールを使用して、個別のWeb層インストールをインストールして構成する必要があります。
図3-2 フロントエンドWebサーバーを使用したOracle WebLogic ServerとOC4Jの比較
Oracle Application Server 10g リリース3（10.1.3）では、クラスタリングに関する次の概念を導入しています。
Oracle Application Serverのクラスタ・トポロジ: 1つのアクティブなOracle Enterprise Manager Application Server Controlから複数のOracle Application Serverインスタンスを管理可能にします。
Application Server Controlの「クラスタ・トポロジ」ページから、クラスタ・トポロジ内の複数のOracle Application Serverインスタンスを表示し、これらのインスタンスに対して管理タスクを実行できます。 クラスタ・トポロジ内の異なるインスタンス間の通信は、Oracle Notification Service（ONS）を使用して行います。
OC4Jグループ: クラスタ・トポロジ内のOC4Jインスタンスをグループ化し、OC4Jインスタンスに対してグループ全体のタスクを一度に実行するメカニズムを提供します。
たとえば、OC4Jインスタンスのグループを作成した後、そのグループにアプリケーションをデプロイしたり、そのグループのデータソースを変更することができます。 ただし、重要な制限が1つあり、グループ内の各OC4Jの構成がグループ内の他のOC4Jインスタンスと同一である必要があります。
OC4Jアプリケーション・クラスタリング: クラスタ・トポロジ内の異なるOC4Jインスタンスにデプロイされたアプリケーション間で状態情報を交換可能にする機能です。
これらのOC4J機能とOracle WebLogic Serverの相違点の詳細は、次を参照してください。
表3-1は、OC4Jのクラスタリング機能とOracle WebLogic Serverで使用可能なクラスタリング機能の比較を示しています。
図3-3は、OC4JとOracle WebLogic Serverのクラスタリングの相違点を示しています。
表3-1 OC4Jのクラスタリング機能とOracle WebLogic Serverの比較
| OC4Jの機能 | Oracle WebLogic Serverにおける同等の機能 | 詳細情報 |
|---|---|---|
|
Oracle Application Serverのクラスタ・トポロジ |
『Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server』のWebLogic Serverドメインの理解に関する項 |
|
|
『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』のWebLogic Serverのクラスタリングの理解に関する項およびクラスタ・アーキテクチャに関する項 |
||
|
Oracle WebLogic ServerのHTTPセッション・ステート・レプリケーション |
『Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server』のHTTPセッション・ステート・レプリケーションに関する項 |
一般的なOracle WebLogic Serverドメインのディレクトリ構造は、Oracle Application Server 10g インスタンスのディレクトリ構造といくつかの点で異なります。
Oracle Application Server 10g をインストールする場合は、j2eeディレクトリを含む単一のOracleホームを作成します。 OC4J固有の構成ファイルとログ・ファイルはj2eeディレクトリ内に格納されます。
Oracle WebLogic Serverでは、インストールはMiddlewareホーム内のみで行われます。 Middlewareホーム内で、インストーラによりOracle WebLogic Serverホーム・ディレクトリが作成されます。 ドメインを構成する場合は、Oracle WebLogic Server構成ウィザードを使用してuser_projectsディレクトリ内に新規ドメインを作成します。
図3-4は、Oracle WebLogic ServerとOC4Jのディレクトリ構造の違いを示しています。
次の項は、OC4JユーザーがOracle WebLogic Serverドメインの機能を学習するために役立ちます。
10g リリース2（10.1.2）または10g リリース3（10.1.3）のどちらを使用してるかに応じて、Oracle Application Server 10g 環境を次の2つの方法のうちいずれかで編成します。
Oracle Application Server 10g リリース3（10.1.3）では、クラスタ・トポロジにアプリケーション・サーバーとOC4Jインスタンスを編成します。
Oracle Application Server 10g リリース2（10.1.2）では、複数のOracle Application Serverインスタンスをファームに、OC4JインスタンスをOracle Application Serverクラスタに追加できます。
Oracle Fusion Middleware 11g では、まったく異なるメカニズムを使用して環境を編成します。Oracle WebLogic Server環境は、ドメインと呼ばれる論理グループに分類されます。これらのドメインは、次のもので構成されます。
以前のバージョンのOracle Application Server 10gでは、OC4Jインスタンスと、OC4Jインスタンスごとに1つ以上のJava仮想マシン（JVM）をインストール、作成および構成しました。
Oracle Fusion Middleware 11g では、1つの管理サーバーと1つ以上の管理対象サーバーを含むOracle WebLogic Serverドメインを構成して、Java EEアプリケーションをデプロイします。
次の項では、OC4J環境からOracle WebLogic Server環境に移行する際に役立つOracle WebLogic Serverドメインの詳細を説明します。
図3-4に示すように、作成したOC4Jインスタンスに関連付けられているバイナリ・ファイルと構成ファイルは、Oracle Application Server 10g のOracleホーム（j2eeディレクトリ構造）内のサブディレクトリ構造に格納されます。 このような直接的なファイル・システムの関連付けが必要なだけではなく、OC4Jのバイナリとインスタンス構成との間の関係がインスタンスごとのレベルになります。
対照的に、Oracle WebLogic Serverでは、インストールされたソフトウェアとその各種構成インスタンスが明確に分離されています。 単一のOracle WebLogic Serverのインストールを使用して、それぞれが異なる一連のサーバーで構成された複数のドメインを作成できます。
デフォルトでは、Oracle WebLogic Server構成ウィザードは、各ドメインの構成ファイルがuser_projects/domainsディレクトリ内に配置されることを前提としています。 ただし、ドメインに関連付けられたファイルはファイル・システム内のどこにでも配置できます。 WebLogic Serverインスタンスをドメイン・ディレクトリから実行する場合の唯一の要件は、Oracle WebLogic Serverディレクトリがアクセス可能であることです。
また、WebLogic Serverモデルでは、WebLogic Serverのバイナリとインスタンス構成の間の関係は、ドメイン（一連のインスタンス）レベルとなります。
OC4Jは、標準のJava Development Kit（JDK）のJava仮想マシン（JVM）上で実行されます。 デフォルトでは、OC4Jインスタンスごとに1つのJVMを使用します。 ただし、1つのOC4Jインスタンスを複数のJVMで実行するように構成することもできます。 このようにOC4Jインスタンスを構成するには、numprocプロパティを使用するか、またはApplication Server Controlコンソールを使用します。
OC4Jインスタンスを複数のJVMで実行するように構成すると、そのOC4Jインスタンスは基本的に複数のプロセスで実行されます。 これによって、パフォーマンスが向上し、デプロイ済アプリケーションのフォルト・トレランスのレベルが高まります。 ただし、複数のJVMを使用すると、効率的な実行のために追加のハードウェア・リソースが必要になります。
Oracle WebLogic Serverには、これと同等の設定または機能はありません。 かわりに、各サーバーが常に単一のJava仮想マシン上で実行されます。 ただし、ドメイン内の同じホスト上で実行される管理対象サーバーの数を増やすことで、OC4Jのnumproc設定と同じ機能が得られます。
OC4Jインスタンスでは、リクエストの受入れが可能なプロトコルごとに異なる一連のリスニング・ポートを使用します。 OC4Jでは、OC4J Webサイトの概念を使用して、OC4Jインスタンスごとに特定のHTTP、HTTPS、AJPまたはAJPSポート（またはポート範囲）を構成します。 同様に、OC4JインスタンスではRMIおよびJMSトラフィック用の専用ポート（およびポート範囲）を構成できます。
デフォルトでは、WebLogic Serverのリクエスト・ポートおよびプロトコル管理モデルは、次の2つの重要な点でOC4Jと異なります。
最初に、Oracle WebLogic Serverインスタンスは受信アプリケーション・リクエストに対して2つのリスニング・ポートのみを使用するように構成されています。1つは暗号化されていないリクエスト用（必ず設定）、もう1つはSSL暗号化リクエスト用（任意）です。
次に、これらのポートは、ポートが特定のプロトコル専用となるOC4Jインスタンスのケースとは対照的に、サポートされているすべてのプロトコルのリクエストを受け入れるように構成されます。
通常は、このデフォルトのリスニング・ポート・モデルでほとんどのユースケースに対応できますが、Oracle WebLogic Serverではネットワーク・チャネルと呼ばれる機能を提供しています。この機能を使用すると、特定のプロトコル専用のポートを追加してWebLogic Serverインスタンスを構成できます。 この機能は、このような構成を必要とする特別なユースケースに使用できます。
サポートされているOC4J構成の1つに、フロントエンドWebサーバー（ほとんどの場合、Oracle HTTP Server）が受信HTTPリクエストを受信するように構成されているトポロジがあります。 受信リクエストは次に、AJPプロトコルを介してOracle HTTP Serverから適切なOC4Jインスタンスへとルーティングされます。 この構成では、OC4Jインスタンスは直接HTTPリクエストを受信せず、OC4JインスタンスでHTTPリスナーは構成されていません。
対照的に、Oracle WebLogic Serverインスタンスでは常にHTTPリクエストを受け入れますが、AJPをサポートしていません。 ただし、セキュリティとスケーラビリティを確保するために、WebLogic Serverドメインの前面にWeb層を配置できます（多くの場合は配置されています）。 Oracle HTTP Serverを含む多くのWebサーバーは、WebLogic Serverドメイン内のサーバーに対するWeb層として機能することが保証されています。
詳細は、第7章「Java EEおよびWebサーバー環境のアップグレード」を参照してください。
Oracle Application Server 10g とは異なり、Oracle WebLogic Serverでは、環境のインストール・タスクと構成タスクを分離しています。
Oracle Application Server 10g では、Oracle Universal Installerを使用してOracle Application Server環境（その環境内のOC4Jインスタンスを含む）のインストールと構成を行います。
Oracle WebLogic Serverでは、次の2つの個別ツールを使用して環境のインストールと構成を行います。
Oracle WebLogic Serverインストーラ: Oracle WebLogic Serverドメインを構成する準備として、ディスク上にMiddlewareホームを作成し、必要なOracle WebLogic Serverファイルを配置するために使用します。
Oracle WebLogic Server構成ウィザード: Oracle WebLogic Serverドメインの作成と構成に使用します。
このようにインストール・タスクと構成タスクを分離することにより、3.1.3.2.1項で説明されているように、単一のOracle WebLogic Serverインスタンスから複数のドメインを作成できます。
次の項では、OC4JとOracle WebLogic Serverの管理に使用できる管理ツールの比較に加えて、Oracle WebLogic Serverの一般的な管理タスクの実行方法の概要も説明します。
Oracle WebLogic Serverドメインの管理に使用するツールは、OC4Jベースの環境の管理に使用するツールとは次の点で異なります。
Oracle WebLogic Serverの管理ツールの完全なリストについては、『Introduction to Oracle WebLogic Server』のシステムの管理ツールとAPIの概要に関する項を参照してください。
表3-2 OC4JおよびOracle WebLogic Serverの管理ツールの比較
表3-3 その他のOracle WebLogic Serverの管理ツール
| 管理ツール | 説明 |
|---|---|
|
Oracle WebLogic Serverには このツールを使用すると、同様にOC4J admin_client.jarでJava EEアーティファクト・デプロイメントを実行できます。 以前のOC4Jリリースでは、OC4Jへのデプロイはadmin.jarと |
|
|
Oracle WebLogic Serverには、Apache Antスクリプト内でWebLogic Serverの管理プロセスを実行できるようにする一連の管理Antタスクが用意されています。 これらのAntタスクは、OC4JのAntタスクと同様のタイプの機能を実行します。 |
次の項では、一般的な管理タスクについて説明しており、これらのタスクはOracle WebLogic Serverで実行します。
OC4Jインスタンスの起動と停止は、Application Server ControlまたはOPMNコマンドライン（opmnctl）を使用して行います。 同様に、WebLogic Serverインスタンスの起動と停止は、Oracle WebLogic Server管理コンソールまたはWebLogicのスクリプト作成ツール（WLST）を使用して行います。
また、WebLogic Serverインスタンスは、ドメイン・ディレクトリのbinディレクトリで使用可能な起動スクリプトを介して起動することもできます。 これらのスクリプトには、管理サーバーを起動するstartWebLogicスクリプト、およびドメイン内の管理対象サーバーを起動するstartManagedWebLogicスクリプトが含まれています。
詳細は、『Oracle Fusion Middleware Managing Server Startup and Shutdown for Oracle WebLogic Server』を参照してください。
Oracle WebLogic Serverの診断機能は、Weblogic診断フレームワーク（WLDF）を介して提供されます。 WLDFは、Oracle Application Server 10g の監視サーバーであるOracleAS Dynamic Monitoring Service（DMS）と同等またはそれ以上の機能を提供します。
WLDFの機能には、動的なコード・インスツルメンテーション、イメージ・キャプチャ、監視および通知が含まれています。そのためアプリケーション診断機能が拡張され、Java EEアプリケーション管理の総所有コストを大幅に削減できます。
また、WLDFの機能は、WLDFコンソール拡張機能を介して管理コンソール内のカスタム・ダッシュボードとして公開できます。 現在DMSを使用しているアプリケーションは、Oracle Fusion Middleware 11g でも引き続きDMSを使用できます。
サード・パーティのアプリケーション管理ツールを使用している場合は、通常、そのサード・パーティのツールを更新すれば、Oracle WebLogic Server上で実行されているアップグレード済アプリケーションに対して引き続きそのツールを使用できます。
Oracle WebLogic Serverのロギング・サービスでは、Oracle Application Server 10g のロギング機能に似た、包括的な一連のロギング機能を提供します。 また、Oracle Diagnostics Logging（ODL）フレームワークの機能は、Oracle Fusion Middleware 11g で使用できるJava Required Files（JRF）テンプレートを利用してOracle WebLogic Serverに統合することもできます。
詳細は、5.1.4項「Java Required Files（JRF）ドメイン・テンプレートの使用」を参照してください。
そのため、アプリケーションでODLフレームワークを直接使用してロギングを行っている場合は、Oracle WebLogic Serverにデプロイする前にアプリケーションに変更を加える必要がありません。 JRF ODLをWebLogic Serverに統合すると、次のようになります。
ODLログ・メッセージは、ファイル・システム上でOracle WebLogic Serverのログ・ファイルとは個別に格納されているログ・ファイルに送信されます。これらのログ・ファイルは次の場所に格納されています。
domain_directory/servers/server_name/logs/server_name-diagnostic.log
重大なメッセージ（エラー）は、ODLとOracle WebLogic Serverドメイン・ログ・ファイルの両方に記録されます。
ODLのログの問合せおよびJMX MBeanの構成は、ドメインの管理サーバーから実行できます。
OC4J Serverインスタンスでは、目的ごとに異なるスレッド・プールを使用します（system、HTTPおよびJCAはデフォルトで起動時に作成されるスレッド・プールです）。 各スレッド・プールのパラメータ（スレッド数の最大値や最小値など）は、個別にチューニングできるため、特定の環境に応じた最適なアプリケーション・リクエスト・スループットを実現できます。
Oracle WebLogic Serverインスタンスにはデフォルトで1つのスレッド・プールが作成され、全体的なスループットを最大にするためにスレッド数が自動的にチューニングされます。 すべてのリクエストは、着信時に共通キューにエンキューされ、管理構成された目標（アプリケーションで必要とされるレスポンス時間や、他のアプリケーションとの相対的なフェアシェアによる全スレッドの割当てなど）に応じて優先度が決定されます。
WebLogicワーク・マネージャと呼ばれるこのOracle WebLogic Server機能により、Oracle WebLogic Serverインスタンスでは最適なリクエスト処理を実現するためにスレッド数を自己チューニングできます。
詳細は、『Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server』のワーク・マネージャを使用したスケジュール済作業の最適化に関する項を参照してください。
表3-4は、OC4JおよびOracle WebLogic ServerでサポートされているJava標準の比較を示しています。
表3-4 OC4JおよびOracle WebLogic ServerでサポートされているJava標準の比較
| 標準 | OC4Jでサポートされているバージョン | Oracle WebLogic Serverでサポートされているバージョン |
|---|---|---|
|
6.0 |
6.0 |
|
|
1.4/5.0 |
5.0 |
|
|
1.1から2.0 |
1.1から2.1 |
|
|
1.1 |
1.1および1.2 |
|
|
2.2から2.5 |
2.2から2.5 |
|
|
2.1および3.0 |
2.1および3.0 |
|
|
非サポート |
2.1 |
|
|
1.1 |
1.1 |
|
|
1.0.2bおよび1.1 |
1.0.2bおよび1.1 |
|
|
1.2 |
1.2 |
|
|
1.5 |
1.5 |
|
|
1.1 |
1.1 |
|
|
1.2 |
1.2 |
|
|
1.0 |
1.2 |
|
|
1.0 |
1.1 |
|
|
3.0 |
3.0 |
