>
インストール ガイド > ALDSP 3.0 または 2.5 から
ALDSP 3.2 へのアップグレード
インストール ガイド
ALDSP 3.0 または 2.5 から
ALDSP 3.2 へのアップグレード
ALDSP 3.0 アプリケーションは Data Services Studio 環境で作成され、WebLogic Server 9.2 にデプロイされます。
ALDSP 2.5 アプリケーションは WebLogic Workshop 8.x 環境で作成され、WebLogic Server 8.1 にデプロイされます。
ALDSP 3.2 アプリケーションは WorkSpace Studio フレームワーク内に作成して WebLogic Server 10.0 MP1 にデプロイされます。
ALDSP 2.5 アプリケーションを ALDSP 3.2 にアップグレードする場合、データ サービス アプリケーション内のデータ サービス プロジェクトが単一のデータスペース プロジェクトにアップグレードされます。データスペース プロジェクトには、WebLogic 10.0 MP1 にデプロイする必要がある該当アーティファクトとともにすべてのデータ サービスが含まれます。
この章では、ALDSP 2.5 アプリケーションを ALDSP 3.2 データスペースにアップグレードする手順について説明します。この章の内容は以下のとおりです。
ALDSP 3.0 から 3.2 へのアップグレード
ALDSP 3.0 から 3.2 へのアップグレード パスは単純です。
開発環境。ALDSP 3.2 開発環境にアップグレードするには、「ALDSP インストールの準備」で示すように ALDSP 3.0 をアンインストールして ALDSP 3.2 をインストールします。インストール後、既存の ALDSP 作業領域を使用し、または新しい作業領域を作成して、3.0 レベル作業領域の内容をインポートすることができます。
デプロイメント環境。ALDSP 3.2 Workspace Studio を使用して、ALDSP 3.0 で作成したプロジェクトをビルドし、デプロイできます。または、ALDSP 3.0 で作成した JAR ファイルを ALDSP 対応 WebLogic 10.0 MP1 サーバにデプロイできます。
ALDSP 2.5 前提条件からのアップグレード
ALDSP 2.5 データ サービス アプリケーションを ALDSP 3.2 にアップグレードする前に、Workshop 8.1 環境で [ビルド|アプリケーションのクリーンアップ] を実行する必要があります。これにより、アプリケーションのアップグレードが成功したことを確認し、後でファイルを手動でクリーンアップする必要はありません。
ALDSP 2.5 アーティファクトの ALDSP 3.2 へのアップグレード
ALDSP ソース アップグレードでは、ALDSP 2.5 データ サービス プロジェクトをアップグレードすることができ、データスペース プロジェクトとして ALDSP 3.2 WorkSpace Studio に取り込むことができます。データ サービスに関連するアーティファクト (スキーマ、モデル ダイアグラム、.java ファイルおよび WSDL ファイルなど) もアップグレードします。
この節では、以下のアーティファクトの ALDSP 2.5 から ALDSP 3.2 へのアップグレードについて説明します。
アプリケーション
プロジェクト
スキーマ
ALDSP プロジェクト内の Java ファイル
JAR データ サービス プロジェクト
シュレッダー ベースのアーティファクト
他のアーティファクト
Eclipse WTP で Portal および Java web サービスのような非データのサービス プロジェクトをアップグレードするには、Data Services Studio を使用することができません。非データのサービス プロジェクトをアップグレードするには、『Workshop for WebLogic Platform プログラマのガイド』の章「WebLogic Workshop 8.1 アプリケーションのアップグレード」を参照してください。
データ サービス プロジェクトが依存する Java プロジェクトとスキーマ プロジェクトをデータ サービス プロジェクトとともにアップグレードできます。
ALDSP コントロールを 3.2 にアップグレードする手順については、「ALDSP 2.5 から 3.2 への ALDSP コントロールのアップグレード」を参照してください。
ALDSP 2.5 アプリケーションのアップグレード
WorkSpace Studio を使用してアップグレードをするには、次の手順に従います。
WorkSpace Studio を起動します。
[プロジェクト エクスプローラ] で右クリックして [インポート|インポート] を選択します。これにより、図 6-1 に示すように、[インポート] ダイアログ ボックスが表示されます。
![[インポート] ダイアログ](wwimages/workspace_import.gif)
[その他] オプションを展開し、[Workshop 8.1 アプリケーション] を選択し、[次へ] をクリックします。Workshop 8.1 アプリケーション アップグレード : [アプリケーション インポート] ダイアログが表示されます。
図 6-2 に示すように、[アプリケーション インポート] ダイアログ ボックスからアップグレードする 2.5 アプリケーションを選択します。
| 注意 : |
依存スキーマと Java プロジェクトとともに ALDSP 2.5 アプリケーション内のすべてのプロジェクトが ALDSP 3.2 内の同じデータスペースにアップグレードされます。Java プロジェクトやスキーマ プロジェクトなど依存するすべてのデータ サービス プロジェクトがあれば選択します。アプリケーション内のすべてのプロジェクトを同じデータスペースにアップグレードしたくない場合、アップグレードするプロジェクトのみ選択してください。 |
![[Workshop 8.1 アプリケーション アップグレード] : [アプリケーション インポート] ダイアログ](wwimages/workspace_app_import.gif)
アップグレードするプロジェクトにプレフィックスを指定したい場合、[プロジェクト名にプレフィックスを追加] オプションを選択します。
| 注意 : |
ALDSP 2.5 からアップグレードしたすべてのプロジェクト ファイルにはデータ サービス プロジェクトから作成した Java とスキーマ プロジェクトに対する指定されたプレフィックスも含まれます。デプロイメント名のプロパティにもプレフィックスがあります。ただし、データスペース名内の ALDSP 2.5 データ サービス プロジェクト フォルダはプレフィックスを持ちません。そのため、LD ネームスペースの URI を変更する必要がありません。 |
ランタイム環境がALDSP 3.2 用の BEA WebLogic Server v10.0 に設定されていることを確認します。
[次へ] をクリックします。図 6-3 に示すように、Workshop 8.1 アプリケーション アップグレード : [ソース アップグレード] ダイアログが表示されます。
![[Workshop 8.1 アプリケーション アップグレード] : [ソース アップグレード] ダイアログ](wwimages/workspace_source_upgrade.gif)
[ソース アップグレード] ダイアログ ボックスでは、次の手順に従います。
以下の要素を含む、[エラー処理] オプションを選択します。
エラーを記録してアップグレードを続けます。
エラーを記録してアップグレードを中止します。
エラーのダイアログを表示します。
リストから [メッセージの冗長] オプションを選択します。このオプションは以下の要素を含めます。
情報コメントを含める
警告コメントを含める
エラー コメントを含める
データスペース名のサフィックスを変更するには、[データスペース名のサフィックスの変更] オプションを選択します。デフォルトでは、データスペースのプロジェクト名は <application_name>_DS です。チェックボックスを選択すると、選択したデータ サービス プロジェクトから <Application_Name>_
Schema という名前のスキーマ プロジェクトを作成できます。たとえば、作成されたスキーマまたは Xmlbeans をプロジェクト外に使用する場合には、このオプションを使用することができます。
[次へ] をクリックします。Workshop 8.1 アプリケーション アップグレード : [DSP 依存関係選択] ダイアログが表示されます。
![[Workshop 8.1 アプリケーション アップグレード] : [DSP 依存関係選択] ダイアログ](wwimages/workspace_dep_selection.gif)
このダイアログでは、カタログ サービス プロジェクトを含むプロジェクトの JAR とともにアップグレード用に選択したデータ サービス プロジェクトを示します (利用可能な場合)。デフォルトでは、データ サービス JAR プロジェクトがアップグレード用に選択されています。アップグレードしたくない場合は、確認して選択解除にする必要があります。データ サービス プロジェクトが既に選択されているので、ここの選択を編集することはできません。
このダイアログはデータスペース依存関係 (スキーマ、Java プロジェクトとライブラリ JAR など) も示します。Java プロジェクト、スキーマ プロジェクトまたは任意のライブラリ JAR がアップグレードする 1 つまたは複数のデータ サービス プロジェクトによって使用されている場合、それらを選択する必要があります。ただし、内部 JAR ファイル、ldclient.jar および ld-server-app.jar はリストされていません。
[次へ] をクリックします。これによって、アップグレード プロセスが完了し図 6-5 に示すように、アップグレード プレビューにアップグレードしたファイルの概要が表示されます。
![[アプリケーション アップグレード] : [アップグレード プレビュー] ダイアログ](wwimages/workspace_upgrade_preview.gif)
アップグレード プレビューでは、以下の詳細が表示されます。
アップグレード中に実行されていたアクションのリスト
追加および削除したファイルのリスト
アップグレードの必要がないファイルのリスト
[完了] をクリックします。インポートされたデータスペースが [プロジェクト エクスプローラ] で表示されます。
| 注意 : |
アップグレードを完了した後、空 EAR プロジェクト フォルダも作成されます。この EAR プロジェクトはアップグレードしたデータスペースに関係なく、後で使用する予定がない場合は削除できます。 |
ALDSP 2.5 から 3.2 への ALDSP コントロールのアップグレード
Workshop for WebLogic 8.1 で作成した ALDSP 2.5 コントロールを WorkSpace Studio 1.1 で使用するためにアップグレードする必要があります。この節では、ALDSP 2.5 LD コントロール (.jcx) でプロジェクトをアップグレードする手順について説明します。
アップグレード後、すべての古いアノテーションが新しいアノテーションにアップグレードされます。アップグレードした ALDSP コントロールは WorkSpace Studio 1.1 に利用できるようになります。
アップグレード プロセスを開始する前に、コントロールのプラグインおよびコントロールのアップグレード プラグインをインストールする必要があります。
次のコントロールのプラグイン ファイルをコピーします。
<aldsp_home>\eclipse-plugins\workshop9\com.bea.aldsp32.eclipse.plugins.workshop9.link
または
<aldsp_home>\eclipse-plugins\workshop102\com.bea.aldsp32.eclipse.plugins.workshop102.link
<aldsp_home> は ALDSP インストールのホーム ディレクトリです。たとえば、C:\bea\aldsp_3.2
以下の場所にこのファイルを貼り付けます。
<bea_home>\tools\eclipse_pkgs\1.1\eclipse_3.2.2\eclipse\links
コントロールをアップグレードするには、以下の手順に従います。
WorkSpace Studio を起動します。
[プロジェクト エクスプローラ] で右クリックして [インポート|インポート] を選択します。これにより、図 6-6 に示すように、[インポート] ダイアログ ボックスが表示されます。
![[インポート] ダイアログ](wwimages/workspace_import.gif)
[その他] オプションを展開し、[Workshop 8.1 アプリケーション] を選択し、[次へ] をクリックします。Workshop 8.1 アプリケーション アップグレード : [アプリケーション インポート] ダイアログが表示されます。
![[Workshop 8.1 アプリケーション アップグレード] : [アプリケーション インポート] ダイアログ](wwimages/workspace_app_import.gif)
アプリケーション インポート ダイアログでは、次の手順に従います。
参照して、アップグレードするアプリケーションを選択します。
プロジェクトにプレフィックスを入力したい場合、[プロジェクト名にプレフィックスを追加] オプションを選択して、プレフィックスを入力します。
[次へ] をクリックします。図 6-8 に示すように、Workshop 8.1 アプリケーション アップグレード : [ソース アップグレード] ダイアログ ボックスが表示されます。
![[Workshop 8.1 アプリケーション アップグレード] : [ソース アップグレード] ダイアログ ボックス](wwimages/workspace_source_upgrade.gif)
[ソース アップグレード] ダイアログ ボックスでは、次の手順に従います。
[エラー処理] オプションを選択します。オプションは「ALDSP 2.5 アプリケーションのアップグレード」の手順 a に前述したオプションと同じです。
[メッセージの冗長] オプションを選択します。オプションは「ALDSP 2.5 アプリケーションのアップグレード」の手順 b に前述したオプションと同じです。
[次へ] をクリックします。これによって、プロジェクト フォルダのためのコンフィグレーション インポートおよびアップグレードするファイルのレポート生成のプロセスが開始されます。
レポートが生成された後、図 6-9 に示すように、[アップグレード プレビュー] ダイアログ ボックスが表示されます。
![[アプリケーション アップグレード] : [アップグレード プレビュー] ダイアログ](wwimages/workspace_upgrade_preview_control.png)
コントロール ElecDB.jcx がリストされ、アップグレード ユーティリティによって関連付けられるファイルで実行されるアクションが表示されます。
[完了] をクリックします。アップグレード プロセスを完了します。[プロジェクト エクスプローラ] で WorkSpace Studio 内の新しいコントロールが表示されます。アップグレードの後、コントロールは .java ファイルに変換されます。
| 注意 : |
コントロールの戻り値型が複合である場合、アップグレードしたコントロールの [WebContent\WEB-INF\lib] フォルダには、関連するスキーマ JAR または XMLBeans JAR があることを確認します。コントロール用に XMLBeans JAR ファイルの詳細については、WebLogic Workshop ドキュメントの「WebLogic Workshop 8.1 ユーザに対する主な相違点」を参照してください。 |
ALDSP 2.5 コンフィグレーションの ALDSP 3.2 へのインポート
ALDSP 2.5 アプリケーションを 3.2 にアップグレードした後、既存の管理またはプロジェクト コンフィグレーションを新しい ALDSP 環境にインポートしなければならない場合もあります。ALDSP 2.5 コンフィグレーション ファイルをインポートするには、ALDSP 3.2 の ALDSP Administration Console を使用します。ALDSP 2.5 コンフィグレーション ファイルは以下の場所にあります。
<domain_dir>\liquiddata\<applicationname>config.xml
<domain_dir> は通常 <bea_home>\weblogic81\samples\domains\ にあります。
| 注意 : |
ALDSP 2.5 の [デフォルトの匿名アクセスを許可] オプションは ALDSP 3.2 にインポートされません。ALDSP 3.2 におけるデフォルト匿名アクセスの設定の詳細については、「ALDSP リソースの保護」の「匿名アクセスの許可」セクションを参照してください。 |
ALDSP コンフィグレーション インポートは ALDSP 2.5 データ サービス プロジェクトを ALDSP 3.2 データスペース プロジェクトにアップグレードし、ALDSP 3.2 ランタイム環境でデプロイする必要があります。
ALDSP 2.5 コンフィグレーションをインポートするには、次の手順に従います。
以下の URL を使用して ALDSP Administration Console を起動して、ログインしてください。
http://localhost:7001/dspconsole
[アップグレードしたデータスペース プロジェクト] を選択します。
[システム管理] カテゴリを選択し、[インポート] タブをクリックします。
ロックを取得するには [ロックして編集] をクリックします。
図 6-10 に示すように、[2.5 コンフィグレーションのインポート] リンクをクリックします。
![[インポート] タブ](wwimages/import-25config.gif)
図 6-11 に示すように、[2.5 コンフィグレーションのインポート] セクションを参照して 2.5 コンフィグレーション ファイルがあるパスを指定します。

コンフィグレーション ファイルのアップグレードを完了するには、[保存|変更のアクティブ化] をクリックします。
ALDSP 3.2 内のアップグレード後のアーティファクト マッピング
この章では、ALDSP 2.5 から 3.2 へのアップグレードの結果が表示され、ALDSP 2.5 と ALDSP 3.2 の間のアーティファクトのマッピングの情報が提供されます。
| 注意 : |
アップグレードの後、ALDSP 対応サーバと通信するには ALDSP 2.5 の 静的なクライアントを使用することができます。アップグレードしたデータスペースを ALDSP 2.5 クライアントを使用するように変更するには、元の ALDSP 2.5 アプリケーションに変更を適用し、2.5 の静的なクライアントを生成してそのクライアントを ALDSP 3.2 に使用する必要があります。 |
表 6-1 では、ALDSP 3.2 にアップグレードした後のアップグレードとアーティファクトのマッピングの詳細を示します。
表 6-1 更新機能およびアーティファクト マッピング
|
|
|
|
|
|
|
データスペース名は _DS サフィックスがある 2.5 アプリケーション名。例えば、RTLApp_DS。アップグレード プロセス中にサフィックスを変更することができる。詳細については、「 ALDSP 2.5 アプリケーションのアップグレード」を参照してください。
|
|
|
アップグレードしたデータスペース内のデータスペース プロジェクト。
|
複数のデータ サービス プロジェクトが単一のデータスペースにアップグレードされる。データ サービス プロジェクトはデータスペース内のフォルダになる。
プロジェクトはデータ サービスおよびスキーマに対する URI を保持する。
データスペース プロジェクトは、ALDSP 2.5 Mediator API のアップグレードしたアプリケーションへのアクセスを許可するために、アプリケーション名 (EAR プロジェクト名) を使用する。
|
|
|
JAR ファイル、スキーマ プロジェクトおよび Java プロジェクト
|
依存プロジェクトとしてマークしたスキーマ プロジェクトがデータスペース内でコピーされる。プロジェクト依存関係のマーキングまたは選択の詳細については、「ALDSP 2.5 アプリケーションのアップグレード」内の手順 9 を参照。
依存としてマークされているライブラリ ファイルはデータスペース プロジェクトの DSP-INF\lib フォルダにコピーされる。
データスペース プロジェクトは作成した Java プロジェクトおよび依存の Java プロジェクトに基づく。すべての作成した Java プロジェクトおよび依存の Java プロジェクトはスキーマ プロジェクト (作成している場合) に基づく。
|
|
|
|
アップグレードしたデータスペース内のプロジェクトから個別の index.xml ファイルが削除される。代わりに、プロジェクトをビルドする場合、データスペース全体に対して単一の index.xml ファイルが作成される。
データスペース内の異なるプロジェクトの場合は、sdo.xsdconfig.xml ファイルをルート レベルで削除する。
個々のプロジェクト用の xquery-types.xsd ファイルを削除し、データスペース用の 1 つのファイルを作成する。
データスペース内の各プロジェクトの SQL インデックス ファイルが結合され、データスペース用の DSP-INF/sql/sql-index.xml に格納される。
|
|
|
<dataservice_ project_name>_ java
|
ALDSP 3.2 では、データスペース プロジェクトでは Java ファイルを保存することができない。したがって、ALDSP 2.5 データ サービス プロジェクトのアップグレード時、これらのファイルは各データ サービス プロジェクト用の新しい Java プロジェクトに移動される。このプロジェクトは <dataservice_project_name>_java という名前になる。
データ サービス プロジェクトから作成した Java プロジェクトの場合、依存関係をデータスペース レベルで設定する。
データスペース プロジェクトをビルドする時に、依存 JAR またはバイナリ ファイルが DSP-INF/lib フォルダにコピーされる。
|
|
|
|
フォルダ構造およびスキーマの名はアップグレード後にも変更されない。
ALDSP 2.5 アプリケーションのスキーマファイルを ALDSP 3.2 サーバ環境で実行するには、XMLBeans v2 と再コンパイルする必要があります。これは、XMLBeans ビルダ ファセットを使用して行うことができます。
別のスキーマ プロジェクトの作成を選択すると、選択した異なるデータ サービス プロジェクトからのすべてのスキーマ ファイルが別のスキーマ プロジェクトに <dataspace_name>_Schema という名前で格納される。別のスキーマ プロジェクトの選択の詳細については、「 ALDSP 2.5 アプリケーションのアップグレード」内の 手順 c を参照。
|
|
|
データスペース プロジェクト内で _catalogservices フォルダとして開く。
|
ALDSP 2.5 の APP-INF/lib 内のカタログ サービス JAR がデータスペース内に展開された形式でアップグレードされる。
すべてのカタログ サービスは他のデータ サービスと同様にアップグレードされる。
すべてのクラス ファイルはフィルタされ、アップグレードの後に削除されます。新しい catalogservicelib.jar が [DSP-INF/lib] フォルダに追加される。
|
表 6-2 に表示されている、データ サービス、xfl および Java ファイル、スキーマ、および WSDL ファイルのような他のアーティファクトもあります。
表 6-2 アップグレード後のマッピングおよび他のアーティファクトの機能
|
|
|
|
|
.ds ファイルは .ds 拡張子を付けてエンティティ データ サービスとしてアップグレードされる。
データ サービス ネームスペースは変更されない。
バージョン番号があるプラグマ情報は 3.2 スタンプを含むように変更される。
すべての読み取り関数は [visibility=public, kind=retrieve] でアップグレードされる。
すべてのナビゲーション関数は [visibility=public, kind=navigate] に保持される。
すべてのプロシージャ (副作用関数) には、[visibility=public, kind=library] がある。また、
外部の関数に対して、関数宣言では以下を使用する。
外部の関数の場合、[procedure declare procedure]
外部の関数ではなく、本文を持つ場合、関数宣言では以下を使用する。
function (declare function)
| 注意 : |
アップグレード後に、libraryProcedure からの関数である場合は副作用関数に対して [kind] を CUD としてマークします。 |
すべての関数は、新しい検証ルールで [primary = false] としてマークされる。
重要な要素はデータ サービス プラグマに存在する場合、キー スキーマ ファイルが作成され、追加される。
このキー スキーマは [TargetTypeSchemaName_KEY]。対象タイプ スキーマ (XML または他の戻り値型スキーマなど) と同じネームスペースを共有する。
|
|
|
|
|
|
これらのファイルを他の Java プロジェクトに移動する。
|
|
|
WSDL ファイルは自動的にアップグレードされる。ただし、場合によっては、WSDL を手動でアップグレードする必要がある。
|
|
|
アップグレードの後、これらのファイルは変更されない。
|
|
|
モデル ダイアグラムはそのままでアップグレードされる。
|
| 注意 : |
ALDSP2.5 では、ALDSP Administration Console を使用して [アプリケーションごとの最大スレッド] プロパティをコンフィグレーションした場合、このコンフィグレーションは ALDSP 3.2 にアップグレードされません。 |
Java Web サービス用のアップグレード後のタスク
Java Web サービス (JWS) のアップグレードを完了した後、動的 JWS クライアントから値を取得するには、以下の手順に従います。
JWS に対する WSDL ファイルをローカルに保存して、オペレーション タグから [parameterOrder] 属性を削除します。
サービスを作成するには、保存した WSDL を使用するようにクライアント コードを変更します。ALDSP 2.5 コンフィグレーションの例と変更したバージョンをコード リスト 6-1 およびコード リスト 6-2 に示します。
コード リスト 6-1 ALDSP 2.5 クライアント
コード リスト 6-2 変更した ALDSP 2.5 クライアント
| 注意 : |
クライアントを変更する時、ポート名が移動した JWS のポート名と一致することを確認します。 |
再コンパイルして ALDSP 2.5 クラスパスでクライアントを実行します。これによって、JWS を正常に実行することができます。
ALDSP 2.5 のアップグレード : 確認済みの問題点と回避策
表 6-3 は、さまざまなコンポーネントを ALDSP 2.5 環境から 3.2 にアップグレードした後のいくつかの確認済みの問題点を示します。
表 6-3 確認済みの問題点と回避策
|
|
|
カスタム Java 関数からシュレッダーした読み取り関数を呼び出す時に、XQueryTypeException が発生します。
|
XMLBeans v2 および以下のコマンドを使用して、スキーマ (.xsd) ファイルを再コンパイルする必要があります。
${WL_HOME}/common/lib/javax.xml.stream_1.0.0.0.jar;${WL_HOME}/server/lib/xbean.jar
com.bea.xbean.tool.SchemaCompiler *.xsd -d testbin -src testsrc -out <jarfilename>.jar
<WL_HOME>はルート ディレクトリであり、WebLogic Server 10.0 MP1 インストールが含まれます。<jarfilename> はスキーマ JAR ファイルの名前です。
|
WorkSpace Studio のプロパティ ビューでは、ALDSP 2.5 更新プロパティが表示されません。例えば、DS プラグマ要素が表示されていません。
|
|
SDO を JWS でエクスポーズすると、ALDSP 2.5 コントロールを実行できますが、アップグレードした 2.5 アプリケーションでは JWS による SDO のエクスポーズがサポートされていません。
|
|
ALDSP 2.5 内の [アプリケーションごとの最大スレッド] プロパティが ALDSP 3.2 コンフィグレーションにインポートされません。
|
データスペース Work Manager のコンフィグレーションによって同一の結果を取得することができます。ただし、スレッドのプールは async/timeout の発生したスレッドおよび最上位レベルの EJB スレッド間で共有されているので、値は同じではありません。
さらに、Work Manager は自己調整であるため、要件を持っていない限り、最小スレッド数および最大スレッド数のみ指定しないことをお勧めします。
WLS 10.0 Work Manager の詳細については、以下の URL を参照してください。
|
ライブラリ フォルダ内の JAR 形式のみに存在するスキーマ プロジェクトがデータスペース プロジェクトでスキーマを作成するようにアップグレードされていません。
|
元の展開されているスキーマ プロジェクトを取得して、アップグレードを開始する前にアプリケーションに含めます。
|