この章では、J2EEプラットフォーム、アプリケーション・サーバーおよびOracle Application Serverの概要を説明します。また、WebSphere Advanced Edition 3.5.3からOracle Application Server 10g リリース3(10.1.3.1.0)への移行に関連する情報についても説明します。
この章の内容は次のとおりです。
アプリケーション・サーバー市場は急速に発展しています。特に、ここ数年の最も大きな進展は、ベンダー間での標準化を実現するSun社のJava 2 Platform, Enterprise Edition(J2EE)仕様が登場したことです。
J2EEプラットフォームおよびコンポーネントの仕様では、特に、Webベースの多層エンタープライズ・アプリケーションを開発およびデプロイするための標準プラットフォームが定義されています。
J2EEでは、企業が多層コンピューティング・モデルに移行する際に発生する問題に対する解決方法が提供されています。対処される問題には、信頼性、スケーラビリティ、セキュリティ、アプリケーションのデプロイ、トランザクション処理、Webインタフェースの設計およびタイムリなソフトウェアの開発などがあります。J2EEは、Java 2 Platform, Standard Edition(J2SE)に基づいて構築されており、Sun社の「Write Once, Run Anywhere(一度書けば、どこでも動く)」というパラダイムを多層コンピューティング環境で実現します。J2EEには、次の表に示すコンポーネントが含まれています。
表1-1 J2EEアーキテクチャ・コンポーネント
コンポーネント | 説明 |
---|---|
J2EEアプリケーション・モデル |
多層のThinクライアント・サービスを開発するためのアプリケーション・モデル |
J2EEプラットフォーム |
J2EEアプリケーションをホスティングするためのプラットフォーム |
J2EE互換性テスト・スイート |
J2EEプラットフォーム製品が、J2EEプラットフォームおよびコンポーネント仕様に規定された要件を満たしているかどうかを検証するための互換性テスト・スイート |
J2EEリファレンス実装 |
J2EEプラットフォームのリファレンス実装 |
J2EEアプリケーション・モデルは、多層アプリケーション・モデルです。アプリケーション・コンポーネントは、コンテナによって中間層で管理されます。コンテナは、ライフ・サイクル管理、デプロイメント、セキュリティ・サービスなどのサービスをアプリケーション・コンポーネントに提供する標準ランタイム環境です。このコンテナ・ベースのモデルによって、ビジネス・ロジックがシステム・インフラストラクチャから分離されます。
J2EEプラットフォームは、ランタイム環境および標準サービス・セットで構成されています。これらによって、Webベースの多層エンタープライズ・アプリケーションを開発するための必要な機能が提供されます。次の2つの表に、J2EEプラットフォームのコンポーネントおよびサービスを示します。
表1-2 J2EEランタイム・アプリケーション・コンポーネント
コンポーネント | 説明 |
---|---|
アプリケーション・クライアント |
デスクトップ・コンピュータで実行するJavaプログラムで、通常はGUIに使用されます。 |
アプレット |
通常はWebブラウザで実行されるJavaプログラムのコンポーネント。 |
サーブレット |
Webサーバーで実行するJavaプログラムで、動的コンテンツの生成に使用されます。 |
JavaServer Pages(JSP) |
クライアント(通常はWebブラウザ)に動的コンテンツを戻すために使用されるテクノロジ。 |
Enterprise JavaBeans(EJB) |
コンポーネント・ベースの分散コンピューティングを実現するためのアプリケーション・アーキテクチャ。 |
コンテナ |
ライフ・サイクル管理、デプロイメント、セキュリティ・サービスなどのサービスをアプリケーション・コンポーネントに提供するランタイム環境。 |
リソース・マネージャ・ドライバ |
外部データソースに対するネットワーク接続を有効にするシステム・レベルのコンポーネント。 |
データベース |
ビジネス・データの格納に使用される一連の関連ファイルで、JDBC APIを介してアクセスできます。 |
表1-3 J2EE標準サービス
サービス | 説明 |
---|---|
HTTP |
Webサーバーとブラウザ間でメッセージを送受信するためにインターネットで使用される標準プロトコル。 |
HTTPS |
Webサーバーとブラウザ間でメッセージを送受信するためにインターネットで使用されるセキュリティ・プロトコル。 |
Java Transaction API(JTA) |
アプリケーションおよびアプリケーション・サーバーでトランザクションにアクセスするためのAPI。 |
RMI-IIOP |
RMI: Javaオブジェクト間でリモート通信するためのプロトコル。 IIOP: ブラウザおよびサーバーでテキスト以外のものを交換するためのプロトコル。 RMI-IIOPは、CORBA IIOPプロトコルを使用するRMIのバージョンの1つです。 |
JavaIDL |
インタフェース仕様の標準言語で、CORBAオブジェクトのインタフェース定義に主に使用されます。 |
JDBC |
データベースとJ2EEプラットフォーム間の接続を確立するためのAPI。 |
Java Message Service(JMS) |
エンタープライズ・メッセージ・システムを使用するためのAPI。 |
Java Naming and Directory Interface(JNDI) |
ディレクトリおよびネーミング・サービスを提供するAPI。 |
JavaMail |
電子メールを送受信する機能を提供するAPI。 |
JavaBeans Activation Framework(JAF) |
JavaMail APIで必要なAPI。 |
アプリケーション・サーバーは、Webベースのクライアント・プログラムとバックエンドのデータベースまたはレガシー・アプリケーションの間で実行されるソフトウェアです。アプリケーション・サーバーを使用すると、ビジネス・ロジックからシステムの複雑さを切り離すことができるため、開発者はビジネス上の問題解決に専念できます。また、アプリケーション・サーバーを使用すると、系統立った効率的な方法で機能およびリソースがクライアント・プログラムによって共有されるため、クライアント・プログラムのサイズおよび複雑さを抑制できます。
Oracle Application Serverは、E-Businessの実行に必要なすべてのインフラストラクチャおよび機能を提供する包括的な統合アプリケーション・サーバーです。すべての開発チームが一連の類似した問題に直面しています。つまり、操業調整および戦略的意思決定を支援するビジネス・インテリジェンスを提供する一方で、すべてのネットワークおよびデバイスで高速に動作するWebサイトやアプリケーションを迅速に配布する必要があるという問題です。Oracle Application Serverによって、開発チームは、E-Businessに関するこれらすべての問題に対処できます。
Oracle Application Serverはアプリケーション・サーバー市場で高い関心を集めており、現在では多くの組織がWebベースのエンタープライズ・アプリケーションをデプロイする目的でOracle Application Serverを採用しています。
Oracle Application Serverは、Webサイトおよびアプリケーションを開発およびデプロイするための唯一の統合インフラストラクチャです。Oracle Application Serverによって、エンタープライズJavaアプリケーションを開発するための完全なJ2EEプラットフォームが提供されます。開発者は、Java、Perl、PL/SQL、XML、Oracle Formsなどの任意の言語でWebアプリケーションを開発できます。また、Java、XMLおよびSQLに対応した単一の統合プラットフォームによって、開発およびデプロイのコストを削減できます。
Oracle Application ServerでのJ2EEサーバー実装は、Oracle Containers for J2EE(OC4J)と呼ばれます。OC4Jは、J2EE 1.3に準拠しており、製品とともにインストールされる標準のJDKバージョン1.4で動作します(JDK 1.3でもサポートされています)。OC4Jは、軽量でパフォーマンスおよびスケーラビリティに優れ、簡単にデプロイおよび管理できます。OC4Jは、開発環境として最適なスタンドアロン・モードでデプロイするか、またはエンタープライズ・レベルの監視および管理機能を備えたApplication Server Controlコンソールを使用してデプロイすることができます。
J2EE規格への準拠の度合いが異なるため、アプリケーション・サーバー間でのアプリケーションの移行が煩雑な作業になる場合があります。アプリケーション・サーバー間でJ2EEアプリケーションを移行する場合の問題には、次のようなものがあります。
理論上は、すべてのJ2EEアプリケーションをすべてのJ2EE準拠のアプリケーション・サーバーにデプロイできますが、実際にはできない場合もあります。
対象となっているJ2EEアプリケーションの実装に関する詳細な知識の不足。
「J2EE準拠」という言葉の定義があいまいです(通常は、J2EEに準拠した機能がアプリケーション・サーバーにあるという意味であり、コード・レベルでJ2EE仕様と互換性があるという意味ではありません)。
ベンダー提供のJ2EE規格に対する拡張機能のうち、使用されている機能の数がデプロイ方法によって異なるため、アプリケーション・サーバー間でのJavaコードの移植性が低下します。(たとえば、サーブレット・エンジン、EJBコンテナ、JDBCインタフェースおよびJNDIインタフェースに、WebSphere固有のライブラリが関連付けられています)。
クラスタリング、ロード・バランシングおよびフェイルオーバーについてのアプリケーション・サーバー間での実装の違い。これらの違いについてはほとんど記述されていないため、移行プロセスではより大きな問題となります。
これらの問題によって、移行作業の予測ができなくなり、信頼性のある計画およびスケジュールの作成が困難になります。このドキュメントでは、WebSphereからOracle Application Serverにアプリケーションを移行する際の問題について説明します。また、J2EEバージョン1.3仕様に基づいた移行方法および解決方法を示します。
J2EEプラットフォームでは、分散された多層アプリケーション・モデルが提供されています。J2EEコンポーネント・ベースの開発モデルの中心には、コンテナの概念があります。コンテナは、コンポーネントに特定のサービスを提供する、標準化されたランタイム環境です。したがって、いずれの組織の特定の目的のために開発されたEnterprise JavaBeans(EJB)の場合でも、トランザクションやEJBライフ・サイクル管理などの汎用サービスを、任意のベンダーの任意のJ2EEプラットフォームで使用できます。
コンテナでは、企業の情報システムに対する標準化されたアクセス(JDBC APIを介したデータベース・アクセスなど)も提供されています。また、アセンブリ時またはデプロイ時のアプリケーションの動作を選択するためのメカニズムも提供されています。
図1-1に示すとおり、J2EEアプリケーション・アーキテクチャは多層アプリケーション・モデルです。中間層では、コンテナによってコンポーネントが管理されます。たとえば、J2EE Webコンテナによってサーブレットの動作が起動され、EJBコンテナによってEJBのライフ・サイクルおよびトランザクションが管理されます。このコンテナ・ベースのモデルによって、ビジネス・ロジックがシステム・インフラストラクチャから分離されます。
前述した問題が内在しているため、移行作業の工数を見積もる前に、次の問題を念頭に置いて移行対象のアプリケーションを調べると有効です。
J2EE仕様に対するベンダー固有の拡張機能への参照が埋め込まれているため、コードを移植できない場合があります。この場合、J2EE準拠のアプリケーション・サーバー間でアプリケーションを移行して実行すると、ランタイム例外(「クラスが見つかりません」など)が発生する場合があります。また、J2EEアプリケーション・サーバーには、非推奨のAPIがサポートされているものも、J2EE仕様に厳密に準拠しているものもあります。WebSphereには、サーブレット、JSP、EJB、JNDIおよびJDBCに対する拡張機能があります。この場合、コードの評価およびコード変更の計画が、移行作業で重要な役割を果たすことがあります。
WebSphere固有のサービスが使用中の場合は、そうしたコンポーネントの移行は困難または実現不可能となります。これらのコンポーネントは、移行対象として指定せず、再設計および再実装を行う必要がある場合があります。このドキュメントでは、J2EE仕様の再設計全体については説明していません。たとえば、Component Broker(IBM社の ORB)サービス、CICSまたはEncinaによるトランザクション・モニター、MQSeriesライブラリ、DB2ライブラリなどを使用するアプリケーションは、このガイドで定義している移行対象ではありません。
アプリケーション・サーバーのベンダーごとにJ2EE標準のサポート・レベルは異なっており、動作にもいくつかの違いがあります。たとえば、WebSphere Advanced Edition 3.5.3では1.3より前のJ2EE仕様をサポートしており、Oracle Application ServerではJ2EE 1.3を全面的にサポートしています。このため、サーブレット、EJB、JNDIおよびセキュリティを移行する際に問題が発生します。このドキュメントでは、これらの問題に対処し、大幅なコード変更を行わずにOracle Application Serverに移行する方法について説明します。
このドキュメントを作成するにあたって、コンポーネントまたはサンプル・アプリケーション(あるいはその両方)をWebSphere Advanced Edition 3.5.3からOracle Application Server 10g リリース3(10.1.3.1.0)に移行する場合に行った作業を文書化しました。WebSphere Advanced Edition 4.0からOracle Application Server 10gリリース 3(10.1.3.1.0)に移行する場合のガイドラインについては、付録A「WebSphere 4.0からの移行」を参照してください。
この移行の演習課題として、WebSphereに同梱されているサンプルをいくつか選択しました。このサンプルをWebSphereでテストしてからOracle Application Serverに移行しました。この移行作業中に、製品のドキュメントには記載されていない特定の問題点が見つかり、それを記録しました。「J2EEアプリケーション移行時の問題」で説明しているように、WebSphere Advanced Edition 3.5.3でJ2EE 1.3仕様がサポートされておらず、WebSphere固有のAPI拡張機能が使用されているため、このような問題が存在します。
Oracle JDeveloper Application Migration Assistant(AMA)は、Oracleプラットフォームにアプリケーションを移行するプロセスを簡略化するためにオラクル社が開発したツールです。このツールを使用すると、コードのナビゲーションおよび進捗状況のレポートに従って、WebSphereからOracle Application Serverへの移行を実行できます。
AMAツールは、Oracle JDeveloperのプラグインとしてインストールされます。このツールでは、アプリケーション・ファイル内のコードのうち、Oracleプラットフォームで実行するために変更が必要なコードを識別するために、正規表現が使用されます。これらの正規表現は、検索ルール・ファイルと呼ばれるXMLファイルに含まれています。AMAでは、WebSphereアプリケーションを分析して分析レポートを生成できます。このレポートによって、プロジェクトの統計が収集され、確認項目間のナビゲーションが可能になり、移行時の変更に関する包括的なステータスの追跡記録が提供されます。AMAは、拡張可能なAPIを使用してカスタマイズできます。このAPIによって、追加の検索ルール・ファイルを特定のアプリケーション用に作成および調整できます。
オラクル社では、AMA Search Rules Exchange(http://otn.oracle.com/tech/migration/exchange.html)によって、多数の検索ルール・ファイルを提供しています。独自に記述する他に、これらの検索ルール・ファイルのいずれかをダウンロードして使用できます。
このツールの詳細およびダウンロード方法については、http://otn.oracle.com/tech/migration/amaを参照してください。
このドキュメントでは、WebSphere Advanced Edition 3.5.3からOracle Application Serverにコンポーネントを移行する場合の詳細を示しています。すべての構成に対する解決方法が網羅されているわけではありませんが、前述した(移行作業時に他の問題とともに表面化する)移行上の問題の一部に対する解決方法について説明しています。このドキュメントに記載されている内容は、WebSphereアプリケーションの評価、Oracle Application Serverへの移行の計画および実行を行う場合に有効です。このドキュメントでは、次の高度な作業について説明しています。
前述の問題に応じたコンポーネントの調査
移行対象の識別
移行環境および移行ツールの準備
対象コンポーネントの移行およびテスト
注意: このドキュメントでは、特に指定されていないかぎり、WebSphereがリリース番号なしで記載されている場合、WebSphere Advanced Edition 3.5.3を示しています。 |