Sun ONE ロゴ     前へ      目次      索引      次へ     
Sun ONE Application Server 7 サーバーアプリケーションの移行および再配備



NetDynamics から Sun ONE AS 7 への移行

NetDynamics のアプリケーションは、iPlanet Migration Toolkit (iMT 1.2.3) で J2EE Web モジュールに移行できます。結果として生成される Web モジュールは任意の J2EE Web コンテナに配備し、実行できます。

はじめに

先に進む前に、%MIGTBX_HOME%/bin/readme.txt を読んで、それぞれの環境に関連する最新情報と問題点を把握してください。この readme ファイルには Migration Toolbox の正しいインストール方法と設定方法、および動作環境についての情報も記載されています。このマニュアルに記載されている移行プロセスを開始する前に、これらのインストールおよび設定を完了し、環境を整備しておく必要があります。

%MIGTBX_HOME% は iPlanet Migration Toolbox (iMT) をインストールまたは解凍したディレクトリを表します。

このマニュアルでは、NetDynamics アプリケーションを J2EE に移行するための、最低限のプロセスだけを説明します。移行プロセスの完全なリファレンスとしては作成されていません。この理由は主に、移行プロセスがそれぞれの環境によって大きく異なるためです。代わりに、このマニュアルでは iPlanet Migration Toolbox (iMT) による基本的な移行プロセスを理解するために必要な情報を提供します。

移行準備

移行プロセスの概要

NetDynamics で作成されたプロジェクトを同等の J2EE プロジェクトに完全に移行するための主要なフェーズは 2 種類あります。1 つは自動移行フェーズ、もう 1 つは手動移行フェーズです。自動移行には抽出および変換の 2 つの手順があります。

自動移行フェーズ

このフェーズでは、手動による NetDynamics プロジェクトの移行準備、および iMT による自動抽出および変換を行います。このフェーズでは、NetDynamics で作成されたプロジェクトを部分的に、場合によっては完全に移行し、全く形態の異なるサーブレットや JSP などの J2EE に準拠するコンポーネントで構成されるアプリケーションを生成します。

変換プロセスでは、元の NetDynamics プロジェクトのコンポーネント構造を完全に複製します。このプロセスではまた、プロジェクトの INTRP ファイルにある宣言型プロパティ情報を使用し、移行アプリケーションに同等の機能を生成します。ただし、現在の変換フェーズでは、NetDynamics Spider API で書かれたコードの J2EE への自動移行は行いません。この移行が手動移行フェーズの主要な作業になります。変換フェーズでは、元のソースコードを移行先の適切な場所にそのままコピーします。たとえば NetDynamics onBeforeDisplay イベントハンドラは、移行アプリケーションのイベントハンドラメソッドが配備される場所にコピーされます。

手動移行フェーズ

自動フェーズでアプリケーションがどの程度移行されるかは、元のアプリケーションの宣言型の機能と API 機能の割合によって決定されます。まれに、機能がすべてプロジェクト内で宣言されている場合があります。このようなプロジェクトは完全に自動移行できる場合が多く、手動の操作を全く行わなくてもすぐに J2EE コンテナに配備し、実行することができます。これに対して、内部で宣言されている機能が少ないプロジェクトは、J2EE アプリケーションとして動作させるためには多くの手作業が必要になります。

一般に手動移行フェーズでは、自動移行されたアプリケーションの出力内容の確認、および Spider API 固有のコードの J2EE 固有のコードへの移行を行います。通常、このプロセスではアプリケーションまたはそのアーキテクチャの再設計は不要です。主な作業は API コールを 1 対 1 でマッピングすることです。これが可能になるのは、自動変換プロセスをターゲットにした J2EE に準拠する強力な Web アプリケーションをベースとしている JATO を使用しているためです。

作業環境の準備

先に進む前に次の事項を確認します。

  1. iPlanet Migration Toolbox がインストール済みかどうかの確認

      • バージョンアーカイブのターゲットディレクトリへの解凍。方法は readme.txt ファイルを参照してください。

      • Toolbox アプリケーション起動によるインストールのテスト。%MIGTBX_HOME%/bin ディレクトリで toolbox.bat を実行してください。空の Toolbox が表示されます。何も表示されない場合は、Migration Toolbox が正常にインストールされているかどうか、%MIGTBX_HOME%/bin/setenv.bat の環境設定がすべて適切かどうかを確認してください。

  2. クラスのバージョン問題を回避するため、Toolbox アプリケーションを実行する時にはすべての JAR ファイルを JDK の拡張ディレクトリ、%JAVA_HOME%/jre/lib/ext から必ず削除することをお勧めします。Toolbox 実行に必要なクラスはすべてバージョンに含まれています。拡張ディレクトリの JAR ファイルの名称を変更するだけでは不十分であり、別の場所に移動する必要があります。

  3. 移行する NetDynamics プロジェクトを %MIGTBX_HOME%/work/NDProjects ディレクトリ、または他の適切なディレクトリにコピーします。このディレクトリは NetDynamics プロジェクトディレクトリとして以下で参照されます。このディレクトリは、同じマシンの NetDynamics インストールで使用される実際のプロジェクトディレクトリをそのまま指定できますが、別のディレクトリを指定しても構いません。代わりに指定できるのは移行対象の NetDynamics プロジェクトを配置するディレクトリです。NetDynamics を Migration Toolbox が稼働するマシンにインストールする必要はありません。NetDynamics を iMT が稼働するマシンにインストールする場合は、iMT の動作が NetDynamics のインストールによって影響を受けないことを確認してください。インストールされる NetDynamics のクラスパスがシステム環境変数 CLASSPATH で参照されていると、影響を受ける場合があります。iMT が起動される時には、iMT が必要とするクラスパスがシステムクラスパスの最後に追加されます。インストールされている NetDynamics のクラスパスがシステムクラスパスの一部である場合は、iMT は正常に動作しません。

  4. ここで、Sun ONE Application Server 7 または他の J2EE に準拠するサーブレットまたは JSP コンテナをインストールできます。

      • サーバーまたはコンテナのインストール手順に従ってインストールを行います。

      • サーバーまたはコンテナを起動し、デフォルトのホームまたはインデックスページを読み込んでインストール状況をテストします。エラーがある場合は、インストールプロセスの問題を解決してから先に進みます。

自動移行プロジェクトの準備

NetDynamics による開発は自由度が大きくなっています。これには利点と欠点があり、欠点としては、すべてのプロジェクトの置き換えを iMT で把握できないということが挙げられます。特に標準外の NetDynamics Spider API を使用している場合、またはマニュアルに記載されていない標準外の方法でこの API を使用している場合がこれに当てはまります。したがって、アプリケーションによっては iMT によって移行される前に手動の準備が必要になります。特別な問題の発生しやすい機能がプロジェクト、または一連のプロジェクト全体で使用されている場合は、この準備が重要になります。

自動移行の 2 つのフェーズの中では、プロジェクトの抽出で最初に問題が発生しやすくなっています。これは単に前述の問題の結果であり、珍しいことではありません。抽出時に問題が発生しないプロジェクトのほうが多く、プロジェクトからのアプリケーション記述の抽出が終了すれば、変換ではほとんど問題は発生しません。

プロジェクト抽出ランタイムと NetDynamics 実行時環境の違い

iMT は組み込み型の NetDynamics Connection Processor (CP) を使用し、プロジェクトからの情報のインスタンス化および抽出を行います。プロジェクト側から見た場合、通常の NetDynamics 5.x サーバー環境内でインスタンス化が行われます。ただし、抽出の実行時環境は NetDynamics サーバーの環境とは大きく異なります。特に JDBC サービス、PE サービス、および PAC は iMT の組み込み型ランタイムでインスタンス化された環境では利用できません。ただしそれでも問題なく必要な情報を抽出できます。

プロジェクトオブジェクトによっては、コンストラクタ、静的イニシャライザ、初期化イベント、または Spider 以外のスレッドでこれらのランタイムの機能に依存したタスクを実行する場合があります。iMT では、NetDynamics 4/5.x の onBeforeInit および onAfterInit イベントを開始しないようにし、これらのイベントのカスタマコードを初期化時に実行しないようにしています。ただし、静的イニシャライザ、オーバーライドされる init() メソッド、NetDynamics 3.x の onBeforeInit および onAfterInit イベントなど、初期化時の他のメソッドは実行されます。これらのメソッドのコードが、iMT ランタイム内で正常終了できない動作を実行しようとする場合は、その箇所のコードをコメントアウトする必要があります。コードは元の場所にそのまま置いておくことができます。このコードは変換時に正しい場所に自動的に移動されます。このような問題の発生するケースを最も簡単に特定する方法は、エラーメッセージまたは Extraction Tool で生成される例外を参照することです。

NetDynamics Extraction Tool 実行前の注意点

上記の理由から、通常 Extraction Tool をプロジェクトに対して実行する場合は最小限の準備だけを行うことをお勧めしています。この場合、抽出処理でエラーが発生し、失敗する可能性は高くなりますが、移行プロセス全体の時間は通常短縮されます。これはツールのエラー情報を使用して問題を特定し、修正するほうが、潜在的な問題をあらかじめ検出して修正するよりも簡単であり、また短期間で修正を行えるためです。ただし潜在的な問題がよく知られている場合はあらかじめ対応する方法が有効です。

ただし、抽出時に発生する問題は他にもいくつかあるため、それを避けるために次の処理を NetDynamics Extraction Tool 実行前に行うことをお勧めします。

  • NetDynamics プロジェクトのインスタンスの中には、Studio で開いた場合、または NetDynamics サーバーで実行した場合に、一見正常に見えても、詳しく見ると壊れている参照やプロジェクトオブジェクトを含んでいるものがあることがわかっています。また、壊れたクラスファイルの中には、組み込み型 NetDynamics ランタイムによる対応するオブジェクトの読み込みを妨げ、一見関連がないように見える例外をスローする原因があることがわかっています。したがって、トラブルを防ぐために次の手順を移行前に実行することを強くお勧めします。

    • プロジェクトがクライアントや同僚などの別のソースにある場合は、プロジェクトの links ディレクトリが存在し、複数の.sid ファイルを含みます。これらのファイルのいくつかをテキストエディタで開き、その中でプロジェクトオブジェクトの名前を指定します。また、必要な外部クラスをプロジェクトに格納します。

    • Studio の自動変換機能でプロジェクトを NetDynamics 5 に変換しておく必要があります。この処理を行うと NetDynamics 5 Studio でプロジェクトが開き、アップグレード確認のメッセージが表示されます。変換時には、Studio はオブジェクトのプロパティをアップグレードし、DataObjects を NetDynamics 5.x 互換のバージョンに変換します。
      重要 : プロジェクトを実際に NetDynamics 5.x で実行する必要はありません。Studio でプロジェクトを変換するだけで十分です。

    • 移行するプロジェクトを NetDynamics 5.x Studio で開き、不足はないか、また移行して問題はないかどうかを確認します。プロジェクトディレクトリ自体もチェックします。たとえば、1 つの NetDynamics ページには、1 つの <project>.spj または <project>Project.spj および <project>.class ファイル、1 つの <page>.spg、<page>.class、および <page>.html ファイルが必要です。また、1 つの DataObject には、1 つの <dataobject>.sdo および <dataobject>.class ファイルが必要です。

    • すべての .class および .ser ファイルをプロジェクトディレクトリから削除し、プロジェクト全体を再コンパイルします。プロジェクトは NetDynamics 5.x バイナリに対応した形式でコンパイルする必要があります。この場合、最も簡単な方法は Studio の「すべてをコンパイル」コマンドを使用することです。Migration Toolbox アプリケーションの Java Compilation Tool で、NetDynamics 5 バイナリを使用してコンパイルすることもできます。ただしこれはさらに多くの設定処理が必要になるためお勧めしません。

  • 可能な場合は、プロジェクトを NetDynamics 5.x でテスト実行します。プロジェクトをサーバーで正常に実行できれば、問題なく移行できる確率はより高くなります。稼働している NetDynamics のコピーがある場合は、CP を設定して移行するプロジェクトをあらかじめ読み込みます。現在の設定から JDBC サービス、PE サービス、およびすべての PAC を削除するためには Command Center を使用します。CP を再起動します。CP が正常に起動した後、NetDynamics および Service Manager (SM) のログをチェックし、例外がスローされていないかどうかを確認します。この時点で例外をスローしているプロジェクトは、抽出時にも例外をスローする可能性があります。

ToolBox サンプルアプリケーションの移行

この節では、ToolBox のサンプルアプリケーションの自動および手動移行処理について説明します。

Migration Toolbox の実行

Toolbox アプリケーションが稼働していない場合は、「作業環境の準備」の説明に従ってツールボックスの設定を行います。

Toolbox Builder の作成

  1. ツールボックスを起動し、最初のダイアログで「Migrate an application」オプションを選択し、「OK」をクリックします。Toolbox を起動すると空の (New) ツールボックスが表示されます。メニューオプション「Add-In」->「Migration」->「NetDynamics Migration Toolbox Builder」を選択します。


NetDynamics Migration Toolbox Builder の呼び出し方法を示す図

モーダルダイアログウィザードが表示されます。


NetDynamics Migration Toolbox Builder を紹介するダイアログボックスの図

「OK」をクリックしてウィザードの最初の手順に進みます。


入力用アプリケーション名を入力するダイアログボックスの図

  1. 移行するアプリケーション名を「Input Application Name」ダイアログボックスに入力します。例では「MigtoolboxSample」と入力しています。「OK」をクリックして次の手順に進みます。


移行アプリケーションの出力ディレクトリを入力するダイアログボックスの図

  1. iMT で生成されるすべてのデータを格納するディレクトリを入力します。通常はデフォルトの値を変更する必要はありません。この例でもデフォルトの値を使用しています。「OK」をクリックしてウィザードの次の手順に進みます。


アプリケーション名を入力するダイアログボックスの図

  1. 自動 iMT 移行では新しい Java JATO ファイルを含む J2EE インフラストラクチャをいくつか生成します。これらの新しいファイルにパッケージを割り当てる必要があります。元のアプリケーションの既存の Java ソースがパッケージ化されて残る場合でも、これらの新しいファイルにパッケージを割り当てる必要があります。パッケージ名に関する制限はありません。MigtoolboxSample アプリケーションにはデフォルト値が提示されます。

パッケージを入力し、「OK」をクリックしてウィザードの次の手順に進みます。


移行する NetDynamics プロジェクト名を入力するダイアログボックスの図

  1. 移行するプロジェクト名を入力します。このプロジェクトは{MIGTBX_HOME}¥work¥NDProjects¥ フォルダに配置する必要があります。


WAR ファイルの生成先となるディレクトリ名を入力するダイアログボックスの図

  1. アプリケーションをパッケージ化する Web アプリケーションアーカイブ (WAR) ファイル名を入力します。このアプリケーションのデフォルト値が提示されます。「OK」をクリックして次の手順に進みます。


Sun ONE Application Server のアーキテクチャを示す図

  1. iMT による WAR ファイルの生成先となる出力ディレクトリ名を入力します。「OK」をダイアログボックスで選択すると、Toolbox builder がアプリケーションの自動移行に必要な一連のツールを生成します。


アプリケーションの自動移行に必要なツール生成を確認するダイアログボックスの図

  1. 「OK」を選択してNetDynamics Migration Toolbox Builder ウィザードを終了します。アドインの結果、抽出ツール、変換ツール、およびアプリケーション抽出アーカイブ自動生成とドキュメント自動変換で使用されるオプションツールが生成され、ツールボックスに必要なツールがすべて揃います。左側のフレームにある各ツールの分岐を選択すると、詳細なヘルプを右側のフレームに表示します。ヘルプにはツールの各プロパティの説明があります。ツールの各インスタンスをクリックすると、Bean プロパティパネルが右側のフレームに表示されます。基本プロパティおよび高度なプロパティを編集できます。

    2. Task Tool はリストに記載された他のツールを単純に順番どおりに実行します。ツールを個別に実行すれば、コンソールへの出力を注意深く確認することができ、より詳細な情報を得ることができます。抽出ツールのプロパティを以下に示します。


NetDynamics Extraction Tool のプロパティを示す図

Translation Toolのプロパティを以下に示します。


NetDynamics Application Translation Tool のプロパティを示す図

  1. Migrate MigtoolboxSample Application Task ツールを起動します。このツールは Extract-MigtoolboxSample、Translate-MigtoolboxSample、および MapSpider2JATO-MigtoolboxSample の各ツールを順番に呼び出し、移行コードおよびアプリケーション記述ファイル MigtoolboxSample.xml を生成します。

  2. Create MigtoolboxSample War File Task ツールを起動します。このツールは次に挙げるツールを起動して Web アプリケーションアーカイブ (WAR) ファイルを生成し、アプリケーションを J2EE コンテナに自動配備できるようにします。アプリケーションを J2EE コンテナに配備する場合は、この WAR ファイルだけが必要になります。

    3. CopyDeplDesc-MigtoolboxSample, CopyJatoJar-MigtoolboxSample, CopyJatoTLD-MigtoolboxSample, CopyJSP-MigtoolboxSample, CopyClasses-MigtoolboxSample, CopySource-MigtoolboxSample, JarWarFile-MigtoolboxSample

  3. Compile-MigtoolboxSample ツールを起動し、JATO Foundation classes と新しい J2EE アプリケーションコンポーネントをコンパイルします。実際には JDK で提供される javac コマンド行ツールの呼び出しだけを行います。

    4. 自動移行はこの時点で完了します。必要に応じて手動移行を開始します。

    手動移行を進めていく最も簡単な方法は、Web アプリケーションを J2EE IDE に実装することです。この例では Forte for Java EE (FFJ) を使用しています。

  4. FFJ 4.0 を起動し、OnlineBank という名前の新しいプロジェクトを生成します。新しいプロジェクトには既存のファイルシステムを置かないようにします。「プロジェクト」をメニューから選択し、「プロジェクトマネージャ」をクリックします。


Forte for Java 4 のプロジェクト生成手順を示す図

  1. 「プロジェクトマネージャ」ウィンドウで「新規」をクリックし、プロジェクト名を入力します。ここでは MigtoolboxSample を入力しています。


移行アプリケーションのプロジェクト名を入力するダイアログボックスの図

  1. 「ファイルシステム」アイコンを右クリックし、エクスプローラパネルで「マウント」「ローカルディレクトリ」を選択します。${migtbox_home}¥work¥output¥MigtoolboxSample¥war を選択し、「OK」をクリックします。Forte ではこのディレクトリを標準の WAR ディレクトリとして認識し、WAR ビューを画像の処理に表示します。


ローカルディレクトリからプロジェクトをマウントする方法を示す図

FFJ では、FILESYSTEM という用語を、プロジェクトの CLASSPATH のエントリを指す用語として使用します。WAR ディレクトリのマウント時に自動的に CLASSPATH の一部となるのは、./war/WEB-INF/classes に置かれている「war」ファイルだけではありません。./war/WEB-INF/lib に置かれている ZIP および JAR の各ライブラリも追加されます。

Java ソースをコンパイルする必要はありません。コンパイラの「非推奨 (deprecation)」フラグは必ず指定します。このフラグを指定して変換されたアプリケーションのコンパイルを実行すると、「自動移行対象外の」API を使用しているコードの各行についてレポートをコンパイル時に生成します。この目的は、できるだけ早くコンパイルを完了し、手動移行に必要なタスクのレポートを生成することです。

  1. 外部コンパイラをコンパイラとして指定してプロジェクトのプロパティを編集し、「非推奨 (deprecation)」を true に設定します。「ツール」をメニューから選択し、「オプション」をクリックします。最初に「構築」、次に「コンパイラの種類」ノードを展開し、「オプション」ウィンドウの「外部コンパイラ」の「非推奨」を true に設定します。以下にその図を示します。


Forte for Java 4 の「★deprecation★」フラグを設定する方法を示す図

  1. エクスプローラの「プロジェクト」でクラス分岐を選択し、右クリックしてメニューを開き、「すべてをコンパイル」を選択します。移行されたコードは次のディレクトリに置かれているものが処理対象になります。

    2. ${migtbox_home}¥work¥output¥MigtoolboxSample¥war¥WEB-INF¥classes¥

    新しく生成された JATO インフラストラクチャは次のディレクトリに置かれているものが処理対象になります。

    ${migtbox_home}¥work¥output¥MigtoolboxSample¥war¥WEB-INF¥classes¥

    コンパイルはただちに実行されます。


移行されたアプリケーションの Java ソースコードをコンパイルする方法を示す図

コンパイラが出す警告の例を以下に示します。


Sun ONE Application Server のアーキテクチャを示す図

  1. アプリケーションの手動移行を完了するためには、これらの警告内容を修正する必要があります。最終的に生成される Web アプリケーションは任意の J2EE Web コンテナに配備できます。FFJ では WAR ファイルをエクスポートし、Sun ONE Application Server 7 に配備できます。Web アプリケーションは FFJ に組み込まれた TomCat サーバーで直接実行することもできます。

  2. サーバーモジュールグループを FFJ に追加します。エクスプローラの「WEB-INF」分岐を右クリックし、「新規」->「JSP& サーブレット」->「Web モジュールグループ」を選択し、サーバーグループを追加します。ウィザード画面のデフォルト値をそのまま使用し、「完了」をクリックします。エクスプローラの「WEB-INF」に、ServerConfiguration という名前の新しい要素が表示されます。エクスプローラの「ServerConfiguration」分岐を右クリックし、「 Web モジュールを追加」を選択して現在の Web アプリケーションを追加します。「Web モジュールを追加」ウィンドウでサーブレットコンテキスト名を指定します。たとえば「Demo」という名前にします。


Web モジュールを生成する方法を示す図

  1. Explorer で「ServerConfiguration」分岐を右クリックし、「実行」を選択して FORTE で実行します。

前へ      目次      索引      次へ     
Copyright 2002 Sun Microsystems, Inc. All rights reserved.

最終更新日 2002 年 10 月 16 日