OracleAS Forms Services アプリケーションのチューニング アプリケーションのチューニング アプリケーションのチューニング アプリケーションのチューニング

アプリケーションの開発者は、Forms Serverの組込みアーキテクチャの最適化機能により最大 の利益を得ることができます。この章の後半では、多くのアプリケーションに影響を与える主 要なパフォーマンスの問題、および開発者がアプリケーションをチューニングしてパフォーマ ンスを改善し、Forms Server機能を活用するための方法について説明します。

10.2.1 データ・サーバーに対する データ・サーバーに対する データ・サーバーに対する データ・サーバーに対する Oracle Application Server Forms Services の の の の 位置

位置 位置 位置

Forms Javaクライアントは、GUIオブジェクトを表示する役割のみを担います。Oracle Forms

のすべてのロジックは、中間層のOracle Application Server Forms Servicesで実行されます。

これには、データベースへのデータの挿入や更新、データベースからのデータの問合せ、デー タベースでのストアド・プロシージャの実行などが含まれます。そのため、アプリケーショ ン・サーバーとデータベース・サーバー間の高速接続が重要になります。

このサーバー間の対話はすべて、Forms Javaクライアントと通信することなく行われます。画 面に変更があった場合のみ、クライアントとForms Services間で通信が行われます。これによ

り、Oracle Formsアプリケーションは、モデムや衛星を介した低速ネットワークで実行するこ

とが可能です。

図10-1の構成では、Forms Servicesとデータベース・サーバーがデータ・センター内で並存す る仕組みを示しています。

図 図 図

図10-1 OracleAS Forms Servicesとデータベース・サーバーの並存とデータベース・サーバーの並存とデータベース・サーバーの並存とデータベース・サーバーの並存

10.2.2 アプリケーションの起動時間の最小化 アプリケーションの起動時間の最小化 アプリケーションの起動時間の最小化 アプリケーションの起動時間の最小化

アプリケーションをロードするためにかかる時間は、第一印象として重要であり、またどの ユーザーにとっても主要な基準となります。起動時間は、オーバーヘッドと見なされます。ま た起動時間は、今後のパフォーマンスを期待させるものでもあります。業務でクライアント・

テクノロジを使用する場合、クライアント・コードのロードに必要な追加のオーバーヘッドは、

ユーザーにあまりよい影響を与えません。したがって、可能なかぎりロード時間を最小化する ことが重要です。

Oracle Formsアプリケーションを要求した後、アプリケーションを使用できる状態にするまで

にはいくつかの手順を実行する必要があります。

1. Java仮想マシン（JVM）を起動します。

2. すべての初期Javaクライアント・クラスをロードし、クラスのセキュリティを認証しま す。

3. スプラッシュ画面を表示します。

4. フォームを次に示す方法で初期化します。

a. 必要に応じて、追加のJavaクラスをロードします。

b. クラスのセキュリティを認証します。

c. ボイラープレート・オブジェクトとイメージをレンダリングします。

d. 初期画面ですべての要素をレンダリングします。

5. スプラッシュ画面を削除します。

6. フォームを使用できます。

アプリケーション開発者は、JVMの起動にかかる時間についてほとんど何も行うことができま せん。ただし、Java配置モデルおよびOracle Forms Developer Javaクライアントの構造では、

開発者はどのJavaクラスをどのようにロードするかを決定できます。これにより、Javaクラス に必要なロード時間を最小化します。

Javaクライアントには、基本機能のクラス（ウィンドウを開くなど）と特定の表示オブジェク トの追加クラス（LOV項目など）のコア集合が必要です。これらのクラスはサーバーに始めか ら常駐している必要がありますが、次の方法を使用すると、これらのクラスをクライアントの JVMにロードするために必要な時間を短縮できます。

■ Javaファイルの使用

■ キャッシュの使用

10.2.2.1 Java ファイルの使用 ファイルの使用 ファイルの使用 ファイルの使用

JavaはJavaアーカイブ（JAR）メカニズムを提供して、クライアントにネットワークを介して 効率的な配布を行うために、クラスをまとめてグループ化し、圧縮（Zip形式）することがで きるファイルを作成します。このファイルがクライアントで使用されると、今後の使用のため にキャッシュされます。

Oracle Application Server Forms Servicesでは、通常の配布例をサポートするために、次に示す

構成済のJARファイルが提供されます。

10.2.2.1.1 Oracle JInitiator

Oracle JInitiatorで使用する次のJARファイルが提供されています。

■ frmall.jar : 必要なクラスがすべて含まれています。

■ frmall_jinit.jar : frmall.jarと同じですが、Oracle JInitiatorで使用できるように最適化されて います（デフォルト）。

■ frmmain.jar : frmall.jarよりもクラスの数が減らされています。その他のクラスは、必要に

応じて遅延メカニズムを使用してダウンロードできます。そのため、ダウンロード量が少 なくて済み、起動時間も短縮されます。

OracleAS Forms Servicesアプリケーションのチューニング

1つ以上のJARファイルを指定するには、Forms構成ファイル（formsweb.cfg）で指定する構 成セクションのarchive_jini設定を使用します。これは、次のように記述します。

[MyApp]

archive_jini=frmall_jinit.jar, icons.jar

archive_jini設定では、前述の3つのJARファイルから1つのみを使用する必要があります。ま

た、アプリケーションで使用する別のカスタムJARファイルも含めることができます（たとえ ば、前述の例に示したicons.jarなど）。どのアプリケーションもそれぞれのarchive_jini設定を 使用できます。

次に示すJARファイルには、frmmain.jarにはない遅延クラスが含まれています。これらの ファイルは、必要に応じて自動的にダウンロードされるため、archive_jini設定で参照する必要 はありません。また、すでにfrmall.jarとfrmall_jinit.jar内には存在するため、frmmain.jarを 利用する場合のみ使用します。

■ frmoracle_laf.jar : Oracleのルック・アンド・フィールのクラス

■ frmgeneric_laf.jar : 汎用（標準）ルック・アンド・フィールのクラス

■ frmresources.jar : 英語以外の言語のリソース・クラス

英語のリソース・クラスはfrmall.jar、frmall_jinit.jarおよびfrmmain.jarに 含まれています。frmresources.jarは英語以外の言語が使用される場合にロードされ ます。ただし、このJARファイルには英語以外のすべての言語のリソースが含まれていま す。そのため、英語のリソース・クラスか、すべての言語のリソース・クラスのどちらか を持つことになります。

Oracle JInitiatorの詳細は、付録B「JInitiator」を参照してください。

10.2.2.1.2 その他のすべての場合（その他のすべての場合（その他のすべての場合（その他のすべての場合（Sun社の社の社の社のJava Plug-inなど）など）など）など）

JInitiatorまたはIEネイティブJVM以外のJava仮想マシン（JVM）には、次のJARファイル

が提供されています。

■ frmall.jar : 必要なクラスがすべて含まれています。

1つ以上のJARファイルを指定するには、Forms構成ファイル（formsweb.cfg）で指定する構 成セクションのarchive設定を使用します。これは、次のように記述します。

[MyApp]

archive=frmall.jar

10.2.2.2 キャッシュの使用 キャッシュの使用 キャッシュの使用 キャッシュの使用

Oracle Application Server Forms ServicesでサポートされているJVM（Oracle JInitiatorおよび

Oracle JDK）は、どちらもJARファイルのキャッシュをサポートします。JVMがクラスを参照

する場合、最初にローカルのクライアント・キャッシュにあるキャッシュ済JARファイル内に クラスが存在するかどうかを確認します。クラスがキャッシュ内に存在する場合、JVMはサー バーのJARファイルをチェックして、キャッシュ内のJARファイルより新しいバージョンが存 在するかどうかを確認します。新しいバージョンが存在しない場合は、サーバーからではなく ローカルのクライアント・キャッシュからクラスはロードされます。

キャッシュは、効率性を最大化するために適切なサイズにします。キャッシュ・サイズが小さ すぎると、有効なJARファイルが上書きされてしまう場合があります。その結果、アプリケー ションを再度起動すると、別のJARファイルのダウンロードが必要になります。デフォルトの キャッシュ・サイズは20MBです。このサイズは、アプリケーションを正常に実行した後の キャッシュ容量のサイズと比較する必要があります。

JARファイルはロード元のホストに関連してキャッシュされます。このため、ロード・バラン シング・アーキテクチャを使用している場合、異なるサーバーからの同一のJARファイルが キャッシュされる可能性があります。JARファイルを中央に置き、ロード・バランシング構成 の各サーバーでそれらを参照することで、開発者は各JARファイルの1つのコピーのみがクラ イアントのキャッシュでメンテナンスされていることを確認できます。この方法を使用すると、

JARファイル内の特定のクラスに署名して、ロード元のサーバー以外のサーバーに接続を戻せ るようにする必要があります。Oracleが提供するJARファイルでは、事前にクラスに署名して あります。