この章では、WebLogic ServerからOracle Application Server 10g リリース3(10.1.3.1.0)にJ2EE Webアプリケーションを移行する場合の問題および必要な作業の概要について説明します。
ここで説明する内容は次のとおりです。
Oracle Application Server 10g は、標準に準拠した包括的な統合アプリケーション・プラットホーム・パッケージです。Oracle Application Server 10g では、状況の変化に迅速に対応してビジネスを行うために必要なすべてのインフラストラクチャおよび機能が提供されています。また、サービス指向アーキテクチャ(SOA)に基づいた、次のような多数のテクノロジ・ソリューションが提供されています。
Webサービスの開発、デプロイおよび管理を行うJ2EEベースのSOAプラットフォーム
データ統合、ビジネス・プロセスの自動化およびビジネス活動の監視を行うエンタープライズ統合サービス
これらのソリューションでは、セキュリティ、システム管理およびグリッド・コンピューティングで共通のインフラストラクチャが使用されるため、低コストのモジュラー型サーバーおよびストレージへの柔軟でスケーラブルなアプリケーションのデプロイが可能になります。
Oracle Application ServerのSOAインフラストラクチャでは、サービスとしてのエンタープライズ・アプリケーションおよびレガシー・システムの開発、統合、編成、プロビジョニング、管理、保護、連携と検出、およびそれらへのアクセスを行うためのそのままで使用可能な機能が提供されています。これらのすべての機能を単一インストールの統合製品で使用できます。
Oracle Application Serverの主要な機能は次のとおりです。
Oracle Containers for J2EE(OC4J): J2EE 1.4と完全に互換性があるコンテナの実装(J2EE 1.3との下位互換性もあり)
Oracle Process Manager and Notification Server(OPMN): 構成可能な分散プロセス・マネージャ
Oracle HTTP Server(mod_oc4jプラグイン付き)
Oracle Enterprise Manager 10g Application Server Control
JMX管理インフラストラクチャ
JAX-RPCに基づいたWebサービスのランタイムおよび管理
JavaオブジェクトとXMLのマッピング
CMPサポートによるOracle TopLinkオブジェクト・リレーショナル・マッピング
Oracle Application ServerとWebLogic Serverの機能の比較については、第2章を参照してください。
移行作業の工数を見積もる場合、次の問題を念頭に置いて移行対象のアプリケーション・コンポーネントを調べると有効です。
J2EE仕様に対するベンダー固有の拡張機能への参照が埋め込まれているため、コードを移植できない場合があります。コード変更の評価および計画を行うことが、移行作業で重要な役割を果たす場合があります。
ベンダー固有の拡張機能の使用中は、コンポーネントの移行が困難または不可能になります。J2EE仕様に対する全面的な再設計については、このドキュメントでは説明しません。ベンダー固有の拡張機能の使用中は、コンポーネントを移行対象として指定せず、再設計および再実装する必要がある場合があります。
J2EE仕様からの逸脱
コンポーネントの大部分がJ2EE仕様に準拠していない場合、このドキュメントは、Oracle Application Serverへの移行方法の決定に関して有効ではありません。コンポーネントのJ2EE仕様がバージョン1.4(このドキュメントが基づいているバージョン)でない場合は、仕様実装時の違いに対処する必要があります。
この移行ドキュメントを作成するにあたって、J2EEアプリケーション・コンポーネントをWebLogic ServerからOracle Application Serverに移行する場合に行った作業を文書化しました。WebLogic Serverに同梱されたサンプルを選択し、WebLogic ServerでテストしてからOracle Application Serverに移行しました。このドキュメントは、それらのサンプルの移行時に発生した問題を基にして作成されています。
ほとんどの移行プロジェクトでは、J2EEアプリケーションを次の手順で移行できます。
WebLogic ServerとOracle Application Serverの相違点(デプロイ、ランタイム(クラス・ローダー)およびサード・パーティ・ライブラリのサポート)を識別します。
プラットフォーム固有の独自機能を削除します(可能な場合)。たとえば、WebLogic Serverでは、BEA JOLT、JSPタグなどです。
プラットフォーム固有のデプロイメント・ディスクリプタを移植します。
各層のJ2EEアプリケーションを次の順序で移植します。
データ層(EJB)
Web層
Javaクライアント
データソース、JMSメッセージ・キューまたはJCAアダプタ(あるいはこれらすべて)
その他のコンポーネント(シングル・サインオン、JAAS、LDAPリポジトリなど)
注意:
|
クラスタリングを実装し、OC4J J2EEコンテナのパフォーマンス・チューニングを実行します。
J2EE規格への準拠の度合いが異なるため、アプリケーション・サーバー間でのアプリケーションの移行が煩雑な作業になる場合があります。アプリケーション・サーバー間でJ2EEアプリケーションを移行する場合の問題には、次のようなものがあります。
理論上は、すべてのJ2EEアプリケーションをすべてのJ2EE準拠のアプリケーション・サーバーにデプロイできますが、実際にはできない場合もあります。
対象となっているJ2EEアプリケーションの実装に関する詳細な知識の不足。
「J2EE準拠」という言葉の定義があいまいです(通常は、J2EEに準拠した機能がアプリケーション・サーバーにあるという意味であり、コード・レベルでJ2EE仕様と互換性があるという意味ではありません)。
ベンダー提供のJ2EE標準への拡張機能のうち、使用されている機能の数がデプロイ方法によって異なるため、アプリケーション・サーバー間でのJavaコードの移植性が低下します。
クラスタリング、ロード・バランシングおよびフェイルオーバーについてのアプリケーション・サーバー間での実装の違い。これらの違いについてはほとんど記述されていないため、移行プロセスではより大きな問題となります。
このドキュメントでは、前述した、WebLogic ServerからOracle Application Serverへアプリケーションを移行する場合の問題について説明します。また、J2EEバージョン1.4仕様に準拠した移行方法および解決方法を示します。
WebLogic ServerからOracle Application Serverへの移行は、比較的簡単なプロセスです。独自のAPIが使用されていない標準のJ2EEアプリケーションは、コードを変更せずにデプロイできます。必要な操作は、構成およびデプロイのみです。独自のユーティリティまたはAPIが使用されていないアプリケーションは、簡単に移植できます。
Oracle JDeveloper Application Migration Assistant(AMA)は、Oracleプラットフォームにアプリケーションを移行するプロセスを簡略化するために、オラクル社が新しく開発したツールです。このツールを使用すると、コードのナビゲーションおよび進捗状況のレポートに従って、WebLogic ServerからOracle Application Server 10g への移行を実行できます。
AMAツールは、Oracle JDeveloperのプラグインとしてインストールされます。AMAツールでは、正規表現を使用して、アプリケーション・ファイル内のコードのうち、Oracleプラットフォームで機能するために変更が必要になる可能性のあるものが識別されます。これらの正規表現は、検索ルール・ファイルと呼ばれるXMLファイルに含まれています。AMAでは、WebLogic Serverアプリケーションの分析および分析レポートの生成を行うことができます。このレポートによって、プロジェクトの統計が収集され、確認項目間のナビゲーションが可能になり、移行時の変更に関する包括的なステータスの追跡記録が提供されます。AMAは、拡張可能なAPIを使用してカスタマイズできます。このAPIによって、追加の検索ルール・ファイルを特定のアプリケーション用に作成および調整できます。
オラクル社では、AMA Search Rules Exchange(http://www.oracle.com/technology/tech/migration/ama/exchange/exchange.html)によって多くの検索ルール・ファイルを提供しています。その1つが、AMA Search Rules for BEA WebLogic Migrationsというファイルです。このファイルに定義されているルールを使用して、WebLogic固有のコードのうち、Oracle Application Serverへの移行時に変更が必要になる可能性のあるものを識別できます。たとえば、このツールで、JoltまたはBEA JCOMを使用しているかどうかを確認できます。また、アプリケーション内で、Defweblogicの起動/停止、T3サービス、WebLogic XAおよびネイティブWebLogic JDBCドライバに対する参照を検索することもできます。
このツールの詳細およびダウンロード方法については、http://www.oracle.com/technology/tech/migration/ama/を参照してください。
このドキュメントでは、WebLogic ServerからOracle Application Serverにコンポーネントを移行する場合の詳細が示されています。すべての構成に対する解決方法が網羅されているわけではありませんが、前述した(移行作業時に他の問題とともに表面化する)移行上の問題の一部に対する解決方法が示されています。このドキュメントに記載されている内容は、WebLogic Serverアプリケーションの評価、Oracle Application Serverへの移行の計画および実行を行う場合に有効です。このドキュメントでは、次の高度な作業について説明されています。
前述の問題に応じたコンポーネントの調査
移行対象の識別
移行環境および移行ツールの準備
対象コンポーネントの移行およびテスト