| Oracle Application Server WebLogicからの移行 10gリリース3（10.1.3.1.0） B31844-01 |
|
 戻る |
 次へ |
WebLogic ServerおよびOracle Application Serverは、いずれもJ2EE 1.3または1.4の機能（WebLogic Serverのバージョンによって異なる）をサポートするJ2EEサーバーですが、これら2つのアプリケーション・サーバーは、製品構成から実行時アーキテクチャまで様々な点で本質的に異なります。この章では、これらの相違点について説明します。この章の構成は次のとおりです。
この項では、WebLogic ServerおよびOracle Application Serverの全体的なアーキテクチャについて、説明と比較を行います。
次の表に、Oracle Application ServerおよびWebLogic ServerでサポートされているJ2EE標準の仕様レベルを示します。
表2-1 Oracle Application ServerおよびWebLogic ServerでのJ2EEサポート状況
| 製品 | J2EE 1.3 | J2EE 1.4 |
|---|---|---|
|
Oracle Application Serverのリリース番号 |
9.0.4 10.1.2 |
10.1.31 |
|
WebLogic Serverのバージョン番号 |
7.0 8.1 |
9.0 Beta2 |
1 J2EE 1.3との下位互換性あり
2 このドキュメントの作成時（2005年11月）現在
このドキュメントでは、Oracle Application Server 10g リリース3（10.1.3.1.0）とWebLogic Server 7.0および8.1について主に説明します。
WebLogic Serverには、独自のコンポーネントおよび概念がいくつかあります。各WebLogic Serverは、管理対象サーバーまたは管理サーバーのいずれとしても構成およびデプロイできます。管理対象サーバーでは、クライアントからのリクエストの受信時に、デプロイされているアプリケーション・ロジックのホスティングおよび実行が行われます。管理サーバーでは、管理対象サーバーの構成および監視が行われますが、アプリケーションのホスティングは行われません。図2-1に、WebLogic Serverのコンポーネントおよび各コンポーネントの相互関係を示します。
すべてのノードに、複数の管理対象サーバーを含めることができます。各管理対象サーバーは、J2EEコンテナ（WebおよびEJB）を実行するJavaプロセス（JVM）です。管理サーバーもJavaプロセスですが、管理サーバーは、管理対象サーバーの起動時に構成情報を管理対象サーバーに伝播させるために必要です。この構成情報は、管理サーバー・ノードのファイル・システムに格納されています。
管理サーバーは、個々の管理対象サーバーおよびWebLogicドメイン全体を監視し、情報を記録するためにも使用されます。1つのWebLogicドメインは、スタンドアロンの管理対象サーバー、管理対象サーバーのクラスタ、および1つの管理サーバーで構成できます。管理サーバーがオフラインになった場合でも、クライアント・リクエストは管理対象サーバーで処理されます。ただし、新しく起動される管理対象サーバーでは構成情報を使用できません。また、サーバー・クラスタでは監視サービスを使用できません。管理サーバーに、自動フェイルオーバーまたはレプリケーション機能はありません。WebLogicドメインの構成データは、手動でバックアップする必要があります。管理サーバーの機能には、コンソールのGUI（HTTPを介したリモート操作）またはコマンドライン・ユーティリティを使用してアクセスできます。
管理サーバーから管理対象サーバーをリモート起動するには、管理対象サーバーが存在する各ノードでノード・マネージャが実行されている必要があります。ノード・マネージャは、UNIXデーモンまたはWindowsサービスとしてバックグラウンドで実行されるJavaプログラムです。ノード・マネージャを使用すると、管理対象サーバーがハングしたり、管理サーバーからのコマンドに応答しなくなった場合に、管理サーバーから管理対象サーバーを強制終了できます。
WebLogic Serverは、Webサーバーとして稼働するように設定することもできます。このモードでは、HTTP 1.1がサポートされ、管理対象サーバーに対するクライアント・リクエストはXML構成ファイルの設定に基づいて解決されます。HTTPリクエストの処理に、WebLogic Serverのかわりにサード・パーティ製のプロキシ・プラグインを使用することもできます。サポートされているプラグインはApache、NetscapeおよびMicrosoft IISです。
この項では、Oracle Application Serverに固有のコンポーネントおよび概念のいくつかについて説明します。ここではその概要を示します。
|
関連項目: 『Oracle Application Server概要』 『Oracle Application Server管理者ガイド』 『Oracle Application Server高可用性ガイド』 『Oracle Application Server Containers for J2EEユーザーズ・ガイド』 |
Oracle Application Serverに実装されているJ2EEサーバーは、Oracle Containers for J2EE（OC4J）と呼ばれます。OC4JはPure Javaの実装です。OC4Jは標準のJDK上で稼働します。また、フットプリントが小さく非常に軽量です。OC4Jによって、より優れたパフォーマンスおよびスケーラビリティを実現することができます。また、OC4Jは、簡単にデプロイおよび管理できます。 Oracle Application Server 10g リリース3（10.1.3.1.0）のOC4Jでは、J2EE 1.4のAPIがサポートされています。図2-3に、Oracle Application ServerでのJ2EEコンポーネント・レイヤーのアーキテクチャ・ビューを示します。
この移行ドキュメントは、WebLogic ServerからOracle Application Server 10g リリース3（10.1.3.1.0）にJ2EEアプリケーションを移行する場合に発生する可能性がある問題を理解するために有効です。
|
注意: このドキュメントで、WebLogic Serverがリリース番号なしで記載されている場合は、WebLogic Server 7.0および8.1を示しています。それ以外の場合は、バージョン番号が明確に記載されています。 |
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では、これらのコンポーネントによって、ユーザー・リクエストを信頼性に優れたスケーラブルな方法で処理できます。これらのコンポーネントには、次のものがあります。
Oracle Application Serverには、2つのリスナーが含まれています。Apacheオープン・ソース・プロジェクトに基づいたOracle HTTP Serverおよび個別スレッドで実行されるOC4Jの一部であるリスナーです。各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リクエストも受信できます。
次の図に、Oracle Application Serverの単一インスタンス内のOracle HTTP Serverおよびその他のOracle Application Serverのランタイム・コンポーネントを示します。
OC4Jインスタンスは、Oracle Application Server内に論理的にインスタンス化されたOC4J実装です。この実装は、Java 2 Enterprise Edition（J2EE）1.4に完全に準拠していて、すべてJavaで記述されています。OC4Jインスタンスは、標準のJava Development Kit（JDK）1.4.2および5.0のJava仮想マシン上で動作します（JDK 5.0は、Oracle Application Serverとともにインストールされます）。OC4Jインスタンスで使用されるディスクおよびメモリーの量は、他のJavaアプリケーション・サーバーと比較すると少量です。1つのOC4Jインスタンスを複数のJVMプロセスで構成でき、各JVMプロセスで複数のJ2EEコンテナを実行できます。JVMプロセスの数は、Oracle Enterprise Manager 10g Application Server ControlコンソールのGUIを使用してOC4Jインスタンスごとに指定できます。
OC4Jは、スタンドアロン構成でインストールおよび実行できます。この構成では、Oracle HTTP Serverがインストールされないため、OC4Jリスナーでクライアント・リクエストを直接受信します。プロセスの監視および管理機能を実行するOracle Process Manager and Notification Serverも、インストールされないコンポーネントの1つです。このため、スタンドアロン構成では、OC4Jは管理対象外となります。
OC4Jインスタンスの論理アーキテクチャは、図2-3に示されているとおり、次のコンポーネントで構成されています。
JMX
Application Server Controlコンソールのユーザー・インタフェースは、OC4Jインスタンスを完全に管理および監視するために使用可能なJMX準拠のクライアント上に構築されています。Application Server Controlコンソールによって提供されるJMX機能は、MBeanというJavaコンポーネントを介して使用可能です。MBean（管理対象Bean）は、JMXで管理可能なリソースを表すJavaオブジェクトです。MBeanは、J2EEの管理仕様（JSR-77）で定義されています。これは、Sun社によって公開されているJ2EE 1.4仕様の一部です。 MBeanの詳細は、『Oracle Containers for J2EE構成および管理ガイド』および『Oracle Containers for J2EEサービス・ガイド』を参照してください。
Webサービス
OC4Jでは、JAX-RPC 1.1を含むJ2EE 1.4標準に基づいて、Webサービスが完全にサポートされています（WebLogic Server 8.1ではJAX-RPC 1.0までサポートされています）。また、Webサービスの相互運用性もサポートされています。 詳細は、『Oracle Application Server Web Services開発者ガイド』を参照してください。
EJB、サーブレット、JCAコンテナ
OC4Jには、EJB、サーブレットおよびJCAに対応する完全なJ2EE 1.4コンテナ機能が実装されています。OC4Jでは、可用性およびスケーラビリティ向上のためにコンテナ・コンポーネントを使用可能にするクラスタリング機能が提供されています。
Oracle TopLink永続性レイヤー
TopLinkでは、Javaオブジェクト・リレーショナル・マッピングの永続性アーキテクチャが提供されます。柔軟性が高く、生産的なメカニズムを使用してJavaオブジェクトおよびEJBをリレーショナル・データベース表に格納できるため、開発者は、完全なオブジェクト指向の設計および手法に集中できます。 今回のリリースのOracle Application Serverでは、EJBのコンテナ管理の永続性はTopLinkと統合されています。 TopLinkのコンテナ管理の永続性が、デフォルトのコンテナ管理の永続性プロバイダとなります。 TopLink WorkbenchおよびOracle JDeveloper 10g の機能が豊富なユーザー・インタフェース・ツールを使用すると、開発者は、オブジェクト・リレーショナル・マッピングを短時間で簡単に構成できます。 既存のコンテナ管理のEJBに対しては、TopLinkのコンテナ管理の永続性への移行を自動化する移行ユーティリティが提供されています。 TopLinkの詳細は、A.3「Oracle TopLink」および『Oracle TopLinkスタート・ガイド』を参照してください。
Oracle Application Serverでは、スケーラビリティおよび高可用性を実現する目的で、複数のOC4JインスタンスをOracle Application Serverクラスタの一部としてまとめてクラスタリングできます。複数のOC4Jインスタンスをまとめてクラスタリングすると、すべてのインスタンスで一貫性のある構成が行われ、同じアプリケーションがデプロイされます。クラスタリングの詳細は、2.3.2「Oracle Application Serverによる高可用性およびロード・バランシングのサポート」を参照してください。
各OracleASインスタンスにはOPMNコンポーネントが1つあり、このコンポーネントによって、そのインスタンス内のプロセスの監視機能およびプロセス管理機能が実行されます。OPMNは、OracleASインスタンス内のプロセスを管理して、プロセスの起動、停止検出およびリカバリを可能にします。
個別のOracleASインスタンス内のOPMNコンポーネントで相互にメッセージを送信して、各OPMNで他のOracleASインスタンス内のコンポーネントを認識することもできます。OPMNでこの機能を実行すると、OracleASインスタンスはクラスタとしてまとめてOPMNで管理されます。 このようなクラスタを、Oracle Application Serverクラスタ（OracleASクラスタ）と呼びます。（クラスタの詳細は、2.3.2「Oracle Application Serverによる高可用性およびロード・バランシングのサポート」を参照してください。）
OPMNは、Application Server Controlコンソールと通信し、そのインタフェースとなることで、Oracle Application Serverの監視、構成および管理を行うための統合インタフェースとしても機能します。また、一部の管理タスクもOPMNコマンドライン・ユーティリティを使用して実行することができます。Oracle HTTP Serverおよび各OC4Jインスタンスでは、OPMNサービスとの通信にサブスクライブ/パブリッシュ型のメッセージ・メカニズムが使用されます。プロセス・レベルでのフェイルオーバーおよび可用性を実現するために、OPMNサービスを実装するプロセスでは、障害が発生した場合にOPMNプロセスを再起動するシャドウ・プロセスが保持されます。
|
関連項目: 『Oracle Process Manager and Notification Server管理者ガイド』 |
Oracle Enterprise Manager 10g Application Server Controlコンソール（Application Server Controlコンソール）では、Oracle Application Serverのコンポーネントおよびアプリケーションを管理するためのWebベースのインタフェースが提供されています。OC4Jのアプリケーションとしてデフォルトでデプロイされます。Application Server Controlコンソールを使用すると、次のタスクを実行できます。
OracleASコンポーネント、OracleASインスタンス、OracleASクラスタ、Oracle HTTP Server、およびデプロイ済のJ2EEアプリケーションとそのコンポーネントの監視
Oracle Application Serverのコンポーネント、インスタンス、クラスタ、およびデプロイ済アプリケーションの構成
OracleASのコンポーネント、インスタンス、クラスタ、およびデプロイ済アプリケーションの操作
OracleASのコンポーネントおよびデプロイ済アプリケーションのセキュリティ管理
OC4Jのインスタンスおよびアプリケーションのパフォーマンス・メトリックの取得
Oracle Enterprise Managerおよびその2つのフレームワークの詳細は、『Oracle Enterprise Manager概要』を参照してください。
|
関連項目: Application Server Controlコンソールおよびその使用方法については、『Oracle Application Server管理者ガイド』を参照してください。 |
次の表に、Oracle Application Server 10g リリース3（10.1.3.1.0）とWebLogic Server 7.0および8.1でサポートされているWebサービス標準の仕様レベルを示します。
表2-2 サポートされているWebサービス標準
| Oracle Application Server 10g リリース3（10.1.3.1.0） | WebLogic Server 7.0 |
WebLogic Server 8.1 | |
|---|---|---|---|
|
WS-I Basic Profile |
1.0, 1.1 |
1.0より前 |
1.0 |
|
WSDL |
1.1 |
1.1 |
1.1 |
|
SOAP |
1.1/1.2 |
1.1/1.2（受信） 1.1（送信） |
1.1/1.2 |
|
WS-Reliability |
1.0 |
サポートされていない |
サポートされていない |
|
WS-Security |
バージョン1.0の次のものがサポートされています。
|
サポートされていない |
バージョン1.0の次のものがサポートされています。
|
|
UDDI |
2.0 |
2.0 |
2.0 |
その他の注意事項は次のとおりです。
Oracle Application ServerではApache Axisがサポートされています。WebLogic ServerアプリケーションでAxisを実行している際に、標準のAxisライブラリに独自の修正を行っていない場合は、同じアプリケーションをOracle Application Serverにデプロイできます。
WebLogicのWebサービスは、標準のJ2EEエンタープライズ・アプリケーションとしてパッケージされています。Webサービスをデプロイする方法は、エンタープライズ・アプリケーションをデプロイする方法と同じです。
オプションのJAX-RPCデータ型は、Oracle Application ServerおよびWebLogic Serverの両方でサポートされています。
WebLogic Serverでは、autotypeおよびservicegenのANTタスクが使用されます。 そのため、いくつかの制限があります。データ型がcomplexTypeで、そのcomplexTypeにsequenceが1つ含まれており、そのsequenceに、maxOccursに1より大きい値またはunboundedが指定されているelementが1つ含まれている場合、autotypeはJAX-RPC仕様に準拠しません。JAX-RPC仕様によると、このタイプのXML Schemaのデータ型は、JavaBeanクラスのsetterメソッドとgetterメソッドのペアを持つJava配列にマップする必要があります。WebLogicのWebサービスは、仕様のこの最後の部分に準拠していません。
RESTスタイルのWebサービスではSOAPエンベロープのかわりにXML文書が使用されますが、このWebサービスは、Oracle Application Serverでサポートされています。
この項では、高可用性およびロード・バランシング、およびアプリケーション・サーバーを使用する場合のこれらの機能の重要性について説明します。また、WebLogic ServerとOracle Application Serverのそれぞれの手法を比較します。
複数のWebLogic Serverをまとめてクラスタとしてグループ化できます。クラスタ全体のデプロイによって、クラスタ内のすべてのサーバーにアプリケーションを同様にデプロイすると、クラスタ全体でのクライアント・リクエストのロード・バランシングおよびアプリケーションのフェイルオーバーが可能になります。WebLogicクラスタでクラスタリングを行うメリットがあるエンティティは、HTTPセッション状態、EJBオブジェクトおよびRMIオブジェクトです。WebLogicでは、複数のロード・バランシング・アルゴリズムが使用されています。これらのアルゴリズムには、ラウンドロビン、重みベース、パラメータベースなどがあります。
|
注意: 後続の各項では、WebLogic Serverで使用されている高可用性メカニズムおよびロード・バランシング・メカニズムの概要を示します。詳細は、http://www.weblogic.comを参照してください。 |
WebLogicクラスタに対してリクエストを行っているクライアントは、それらのリクエストのロードをクラスタ内のサーバーに分散できます。これを行うには、WebLogicプロキシ・プラグインがインストールされたWebサーバーまたはハードウェア・ロード・バランサを使用する必要があります。WebLogicプロキシ・プラグインでは、ラウンドロビン・ロード・バランシング・メカニズムを使用してリクエストのロードの分散が行われます。 ハードウェア・ロード・バランサを使用すると、ハードウェアのメカニズムを使用してクラスタ内のロード・バランシングが実行されます。
WebLogic Serverでは、クライアントのHTTPセッション状態をレプリケートすることでサーブレットおよびJSPのフェイルオーバーが行われます。 サーブレットまたはJSPに対する最初のリクエストがWebLogic Serverで受信されると、サーブレットのセッション状態が別のサーバーにレプリケートされます。レプリケートされたセッション状態は、常にオリジナルのセッション状態と同じ状態に維持されます。WebLogicプロキシ・プラグインによって、Cookieを介してまたはURLをリライトすることでクライアントに2つのサーバーの名前が戻されます。オリジナルのセッション状態をホスティングするサーバーで障害が発生すると、WebLogicプロキシ・プラグインによって、CookieまたはURLの情報が使用され、レプリケートされたセッション状態が保持されているサーバーにクライアントがリダイレクトされます。クラスタでは、アクティブなセッション状態のそれぞれのオリジナルおよびレプリカが常に維持されます。このシナリオでは、セッション状態はメモリー内にレプリケートされます。WebLogic Serverでは、ファイル・システムへのレプリケーションまたはJDBCを介したデータベースへのレプリケーションもサポートされていますが、これらのレプリケーション方法ではフェイルオーバーは自動的には実行されません。
WebLogic Serverでは、クラスタ対応のJNDIサービスおよびクライアント・スタブを使用することで、EJBおよびRMIオブジェクトのロード・バランシングとフェイルオーバーが実現されます。
クラスタのメンバーである各WebLogic Serverで、ローカルJNDIツリーが維持されます。このツリーには、ローカル・サーバーおよびクラスタにデプロイされている（クラスタリング可能な）オブジェクトに関する情報が含まれています。クラスタリング可能なオブジェクトが複数のサーバーにデプロイされると、それらのサーバー内にクラスタリング可能なオブジェクトが存在することが各JNDIツリーに反映されます。クラスタリング可能なオブジェクトが1つのサーバーにデプロイされると、新しくデプロイされたことが、そのサーバーからクラスタ内の他のサーバーにマルチキャストで通知されます。 その通知に従って、他のサーバーでそれぞれのJNDIツリーが更新されます。 また、オブジェクトがデプロイされたサーバーから他のサーバーに、オブジェクトのスタブも送信されることに注意してください。
JNDIサービス内のクラスタリング可能オブジェクトがクライアントからルックアップされると、リクエストを処理するサーバーからクライアントにオブジェクトのスタブが戻されます。 このスタブには、オブジェクトが実際にデプロイされているサーバーに関する情報が含まれています。また、このスタブには、オブジェクトへのメソッド・コールを分散するロード・バランシング・ロジックも含まれています。使用可能なロード・バランシング・アルゴリズムは、ラウンドロビン、重みベース、ランダムおよびパラメータベースです。 クライアントから見ると、クラスタは透過的です。クラスタリングされたオブジェクトをサーバー側で処理していることがクライアントによって認識されることなく、JNDIルックアップおよびロード・バランシングが行われます。
クラスタリングされたオブジェクトがステートフルな場合（ステートフル・セッションEJBなど）、オブジェクトの状態は2番目のサーバーにレプリケートされます。このレプリケーションは、HTTPセッション状態の場合と同様の方法で行われます。 クライアントの最初のリクエストを処理するように選択されたサーバーから別のサーバーに、オブジェクトの状態がレプリケートされます。クライアント・スタブは、この2番目のサーバーを認識するように更新されます。1番目のサーバーで障害が発生すると、メソッドの起動の試行時にスタブで例外が受信されます。次に、その起動要求は、スタブによって、レプリケートされたオブジェクト状態を保持しているサーバーにリダイレクトされます。このサーバーで、レプリケートされた状態を使用してオブジェクトがインスタンス化され、メソッドの起動が実行されます。また、オリジナルのサーバーで障害が発生しているため、このサーバーでは、状態をレプリケートするために別のサーバーが選択されます。ステートフル・オブジェクトのフェイルオーバーは、このように実行されます。
ステートレス・オブジェクトのフェイルオーバーは、状態のレプリケートが不要なため、より簡単に実行できます。サーバーで障害が発生したことを示す例外が受信されると、クライアント・スタブによって、コールされたオブジェクトの別のインスタンスをホスティングしているもう1つのサーバーが選択され、そのサーバーにメソッドの起動がリダイレクトされます。
Oracle Application Serverアーキテクチャでは、Oracle Application Serverインスタンスの高可用性がサポートされています。多くの場合、この高可用性によってデプロイ済アプリケーションの計画外停止時間を回避できます。通常、Oracle Application Serverでは、クラスタリングおよびプロセス監視によって高可用性が実現されます。クラスタリングを行うと、デプロイ済J2EEアプリケーションのフェイルオーバー、ロード・バランシングおよびスケーラビリティが保証されます。また、クラスタ内の個々のプロセスを監視することによって、プロセスの信頼性が保証されます。次の各項では、クラスタリングおよびプロセス監視を行った場合のこれらのメリットをOracle Application Serverで実現する方法について説明します。
|
関連項目:
|
Oracle Application Serverインスタンスの各プロセスはOPMNによって監視されます。Oracle Application Serverインスタンスのコンポーネント・プロセスがハングまたはクラッシュした場合は、OPMNシステムによってプロセス停止の検出およびプロセスの再起動が行われます。監視対象のコンポーネントには、Oracle HTTP ServerプロセスおよびOC4Jプロセスが含まれます。OPMNの詳細は、2.1.3.5「Oracle Process Management Notification（OPMN）Server」を参照してください。
OPMNには、クラスタリングされたOracle Application Serverコンポーネントを管理するための機能があります。Oracle Application ServerインスタンスのOPMNプロセスは、他のOracle Application ServerインスタンスのOracle HTTP ServerおよびOC4Jプロセスの可用性を認識するように構成できます。これによって、クラスタ内のすべてのコンポーネント・プロセスの状態をOPMNでリアルタイムに確認できます。
HTTPセッション状態およびステートフル・セッションEJBの高可用性は、アプリケーション・クラスタリングによって実現されます。このタイプのクラスタリングでは、アプリケーション・レベルのフェイルオーバーおよび冗長性が有効になります。OC4Jにデプロイされたアプリケーションの場合、HTTPセッションおよびステートフル・セッションEJBのオブジェクトおよび値は、異なるサーバー・ノードのOC4Jインスタンスにレプリケートできます。これらのOC4Jインスタンスでは、同じアプリケーションがホスティングされます。1つのノードで障害が発生すると、そのノード上のクラスタリングされたアプリケーションに対して行われたリクエストは、同じクラスタリングされたアプリケーションをホスティングする、障害が発生していないノードに転送されます。アプリケーションのフェイルオーバーは、クライアントに対して透過的です。セッション状態のレプリケーションは、次の2つの方法のうちのいずれかの方法で実行できます。
メモリー内
セッション状態のレプリケーションがメモリー内で実行される場合、各構成ノード間の通信はマルチキャストまたはpeer-to-peerで行われます。マルチキャストの場合は、共通のアドレスおよびポートを介してセッション状態の情報がマルチキャストされます。 アドレスおよびポートの情報は、アプリケーションのデプロイメント構成ファイルに指定されています。同じマルチキャスト・アドレスおよびポートでデプロイされたすべてのアプリケーションの状態情報は、同じアプリケーション、同じマルチキャスト・アドレスおよび同じポートが指定されている他のノードにレプリケートされます。レプリケーションに含めるノードの数は、マルチキャスト・トラフィックが最小限になるように明示的に指定できます。
peer-to-peerの場合は、1つのピア・ノードから別のピア・ノードにセッション状態の情報がユニキャストされます。各構成ノードは、動的に検出するか、または静的に定義する（OC4Jスタンドアロン・デプロイメントの場合のみ）ことができます。動的検出の場合、ノードをOPMNに登録することで、他のピアを検出したり、ピアのリストにそのノード自体を追加できるようになります。これによって、状態情報がリスト内の各ピアにレプリケートされます。
データベース内
セッション状態の情報は、データベース内で永続化できます。 データベースのJNDIデータソース名は、アプリケーションのデプロイメント構成ファイルに指定されています。レプリケートされた情報は、3つのデータベース表に格納されます。これらの表は、データベース・レプリケーションを初めて実行する際に作成されます。 セッション・データは、セッションのTTL期間中格納されています。データベース自体が障害から保護されていて、バックアップおよびリカバリのスキームが準備されている場合は、クラスタを構成するすべてのプロセスおよびノードで障害が発生しても、データベース内の永続状態情報を使用して状態情報をリカバリできます。
|
注意: メモリー内またはデータベース内でオブジェクトを永続化する場合は、すべてのセッション・オブジェクトがシリアライズ可能である必要があります。 |
各クラスタ内に、OracleASインスタンスのロード・バランシングまたはフェイルオーバーを実行するメカニズムはありません。つまり、クラスタには、インスタンス内のOracle HTTP Serverコンポーネントに対するリクエストのロード・バランシングまたはフェイルオーバーを実行する内部メカニズムは存在しません。 クラスタ内のOracleASインスタンスのロード・バランシング、およびクラスタ内のOracle HTTP Serverインスタンスのフェイルオーバーは、Oracle Web Cacheやハードウェアのロード・バランシング製品などの個別のロード・バランサを使用して実行できます。
スマート・ルーティング: Oracle Web CacheおよびOracle HTTP Server（mod_oc4j）には、受信リクエスト用の構成可能なインテリジェント・ルーティング機能があります。 リクエストは、Oracle Process Manager and Notification Serverシステムとの通信を介してmod_oc4Jでアクティブであると確認されたプロセスおよびコンポーネントにのみルーティングされます。このスマート・ルーティング・メカニズムによって、クラスタリングされたOC4Jインスタンスにデプロイされている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オブジェクトがローカルにキャッシュされるため、パフォーマンスを向上できます。また、オブジェクトのソースが使用できなくなった場合でも、ローカルにキャッシュされたバージョンを使用できるため、可用性も向上します。
この項では、WebLogic PlatformおよびOracle Application Serverで提供されるJavaツールを比較します。
ここでは、WebLogicの開発環境および管理コンソールについて説明します。
WebLogic Workshopは、JavaおよびXMLを使用したWebサービスの構築およびデプロイ用ビジュアル開発環境です。Workshopでは、EJB、データベース、JMSトピック、キューおよびその他のWebサービスやアプリケーションと対話するためのフレームワークおよびコントロールのセットが提供されています。コントロールの一部は、Java Webサービス（JWS）のファイル定義以外のWebLogic Platform独自のものです。JWSファイルには、WebLogic ServerにWebサービスを実装するためのロジックが含まれています。ただし、JWSは、J2EEまたはWebサービス標準ではないため、他のアプリケーション・サービスには移植できません。
WebLogic Serverの管理コンソールでは、WebLogic Serverドメインを管理するためのGUIが提供されています。1つのWebLogic Serverドメインは、1つ以上のWebLogic Serverインスタンス（各インスタンスで1つ以上のアプリケーションを実行）またはインスタンスのクラスタで構成されています。管理コンソールによって、ドメイン内で稼働している目的の管理サーバーに接続し、ドメイン内の任意のマシンの構成を変更したり、実行時の状態を変更することができます。管理コンソールを使用すると、クラスタの定義、サーバーの追加、アプリケーションのデプロイ、アプリケーションの構成、およびWebサーバー、Webサービス、リソースの管理をドメインで実行できます。
この項では、J2EEアプリケーションを作成するための開発ツールおよびデプロイメント・ツールについて説明します。これらのツールは、Oracle Developer Suiteの一部です。
アプリケーション開発者は、Oracle JDeveloperのツールを使用して、OC4JにデプロイするJ2EE準拠のアプリケーションを構築できます。JDeveloperは、Oracle Internet Developer Suite（多層Javaアプリケーションを作成するための機能をすべて備えた統合開発環境）のコンポーネントです。JDeveloperを使用すると、Javaクライアント・アプリケーション、動的HTMLアプリケーション、Webサーバー・コンポーネント、アプリケーション・サーバー・コンポーネント、および業界標準モデルに基づいたデータベース・ストアド・プロシージャを開発、デバッグおよびデプロイできます。多層Javaアプリケーションを作成する場合、JDeveloperでは次の機能が使用されます。
Webアプリケーションの開発
Javaクライアント・アプリケーションの開発
Java in the Database
簡略化されたデータベース・アクセス
ビジュアル統合開発環境
J2EE 1.4に完全に準拠
.earファイル、.warファイル、ejb-jar.xmlファイルおよびデプロイメント・ディスクリプタの自動生成
Oracle JDeveloperでアプリケーションを構築し、Application Server ControlコンソールまたはOC4J管理コンソールを使用してそれらのアプリケーションを手動でデプロイできます。また、JDeveloper以外の開発ツールでアプリケーションを構築することもできます。IBM VisualAgeまたはBorland JBuilderで構築したアプリケーションもOC4Jにデプロイできます。
|
注意: Oracle Application Serverには、JDeveloper以外にオブジェクト・リレーショナル・マッピング・ツールであるOracle Application Server TopLinkも付属しています。 詳細は、『Oracle TopLink開発者ガイド』を参照してください。 |
|
注意: Oracle JDeveloper Application Migration Assistant（Oracle JDeveloperのプラグイン移行ツール）を使用すると、移行する必要があるアプリケーション・コードを迅速に識別できます。 このツールの詳細およびダウンロード場所については、1.2.4「移行ツール」を参照してください。 |
Oracle Application Serverでは、J2EEアプリケーションの構成およびパッケージ化のための様々なアセンブリ・ツールが提供されています。これらのツールによる出力は、OC4J固有ではなく、J2EE標準に準拠しています。提供されているツールは次のとおりです。
Oracle Application Serverでは、コンポーネントを構成、監視および管理するための2つの異なる管理機能が提供されています。
Oracle Enterprise Manager 10g Application Server Controlコンソール（グラフィカルな管理ツール）。これによって、OracleASクラスタ、ファームおよびOC4Jコンテナ全体を一元管理できます。
コマンド・プロンプトから管理タスクをローカル実行またはリモート実行するコマンドライン・ツール。（Application Server Controlコンソールの方が、このコマンドライン・ツールより統合性の高い管理サービス・セットを使用できるため、Application Server Controlコンソールを管理環境として使用することをお薦めします。）
