Java コンポーネントにアクセスする最適な方法は、Java 言語を使用することです。 プログラミングには、極力 Java 言語を使用し、COM 自動化コンテナー (例えば、Visual Basic) と Java コード間には、 小さくて単純なインターフェースを使用することをお勧めします。 このようなインターフェースを使用すると、 インターフェースを介した移動時に発生しがちなオーバーヘッドとパフォーマンス上の問題を回避することができます。
以下のガイドラインは、 Visual Basic を用いた ActiveX から EJB へのブリッジの使用の最適化に役立つことを目的としています。
Java 仮想マシン (JVM) コードが実行中のプロセスに付加されるため、 プログラムをデバッグする前に、Visual Basic エディターを終了する必要があります。 Visual Basic IDE 内でプロセスを実行してからプログラムを終了した場合には、 JVM コードの実行は続行され、XJBInit() がデバッガーによって呼び出されると、同じ JVM コードが再付加されます。 XJBInit() 引数 (例えば、クラスパス) を更新しようとする場合、 Visual Basic プログラムを再始動するまで変更が適用されないため、これは問題の原因となります。
JVM コードをアンロードしたり、再初期化したりすることはできないので、 結果として生じる XJB.JClassFactory オブジェクトをグローバル変数としてキャッシュします。 このオブジェクトをグローバル変数として処理したり、1 つの参照を受け渡したりする際に発生するオーバーヘッドは、 XJB.JClassFactory オブジェクトを新規に再作成したり、 XJBInit() 引数を複数回呼び出したりする場合のオーバーヘッドに比べ、はるかに小さいものです。
以下の ガイドラインは、Active Server Page ソフトウェアを用いた ActiveX から EJB へのブリッジの使用の最適化に役立つことを目的としています。
Active Server Page (ASP) コードは通常、VBScript を使用するので、 ユーザーは、どの VBScript 環境でも少し変更するだけで、組み込まれたヘルパー関数を使用できます。 これらのヘルパー関数の詳細については、データ型変換のヘルパー関数を参照してください。 ASP 環境の外側で実行するには、Server、Request、Response、Application、および Session オブジェクトへの参照をすべて除去または変更します。 例えば、Server.CreateObject を CreateObject に変更します。
XJB.JClassFactory オブジェクトは、 初期化の際に Java ランタイム・ダイナミック・リンク・ライブラリー (DLL) を検出できなければなりません。 Internet Information Server では、プロセス用のパスを個々に指定することはできません。 プロセス・パスをシステム PATH 変数で設定する必要があります。 ASP アプリケーションを使用しているマシン上では、JVM バージョンを 1 つしか使用できません。 また、システム PATH 変数を変更したら、Internet Information Server が変更を認識できるように、 Internet Information Server マシンをリブートする必要があることを覚えておいてください。
システム TEMP 環境変数が設定されていない場合は、 Internet Information Server はすべての一時ファイルを WINNT ディレクトリーに保管します。 これは通常、望ましいことではありません。
Active Server Page ソフトウェアを用いて ActiveX から Java へのブリッジを使用している場合は、 Web アプリケーションをそれ自身のプロセスで作成することをお勧めします。 1 つのプロセスでは JVM 命令を 1 つしかロードできません。 別の JVM 環境オプション (例えば、別のクラスパス) を使用して複数のアプリケーションを実行したい場合は、 別のプロセスが必要になります。
アプリケーションをデバッグするとき、 ASP アプリケーションのプロパティーを Internet Information Server 管理コンソールで表示する場合は、 Unload を使用してプロセスをメモリーからアンロードし、それによって、JVM コードをアンロードします。
ASP 環境では、J2EE アプリケーションまたは JVM 環境ごとに ASP アプリケーションを 1 つだけ使用します。 別のクラスパスまたは JVM 設定が必要な場合は、 別の ASP アプリケーション (高度に分離した仮想ディレクトリーまたは分離したプロセス) が必要になります。
JVM 命令とプロセスとの間には 1 対 1 の関係が要求され、 また、JVM コードは、プロセスから単独で切り離したり、シャットダウンしたりすることができないため、 XJB.JClassFactory オブジェクトをアプリケーションの有効範囲でキャッシュし、 XJBInit() メソッドを 1 度だけ呼び出します。
ActiveX から EJB へのブリッジはフリー・スレッド・マーシャラーを使用するので、 Internet Information Server と ASP 環境のマルチスレッドの性質を利用してください。 ページ有効範囲 (ローカル変数) で XJB.JClassFactory オブジェクトの再初期化を選択した場合、 XJBInit() メソッドはローカル XJB.JClassFactory 変数しか初期化できません。 XJBInit() メソッドを 1 度だけ使用すれば、効率がさらによくなります。
VBScript コードは、バリアント・データ型だけをサポートするので、 CStr()、CByte()、CBool()、CCur()、CInt()、Clng()、CSng()、および CDbl() 関数を使用して、 使用するデータ型を activeX から EJB へのブリッジに伝えます。 例えば、oMyObject.Foo(CDbl(1.234)) と入力します。
以下のガイドラインは、 J2EE 環境での ActiveX から EJB へのブリッジの使用の最適化に役立つことを目的としています。
ユーザーはプロセスごとに JVM 命令を 1 つしか持てず、 JVM 命令ごとに J2EE クライアント・コンテナー (com.ibm.websphere.client.applicationclient.launchClient) を 1 つしか持てないので、 J2EE クライアント・コンテナーを 1 度だけ初期化し、それを再利用します。 ASP アプリケーションの場合、J2EE クライアント・コンテナーをアプリケーション・レベルの変数に保管し、 それを 1 度だけ初期化します (global.asa ファイルの中の Application_OnStart() イベントによるか、 またはそれが IsEmpty() であるかどうかを調べることによって)。
クライアント・コンテナー・オブジェクトをグローバルに保管することの副次作用は、 クライアント・コンテナー・パラメーターを変更する場合に、 必ずオブジェクトを破棄して新規オブジェクトを作成しなければならないという点です。 これらのパラメーターとしては、EAR ファイル、BootstrapHost、クラスパスなどがあります。 Visual Basic アプリケーションを実行していて、クライアント・コンテナー・パラメーターを変更する場合は、 そのアプリケーションを終了して再始動する必要があります。 Active Server Page アプリケーションを実行している場合は、 最初に Internet Information Server からアプリケーションをアンロードしなければなりません (Active Server Page ガイドラインの中の『アプリケーション・アンロード・ボタンの使用』を参照)。 その後で、別のクライアント・コンテナー・パラメーターを用いて Active Server Page アプリケーションをロードします。 パラメーターは、Active Server Page アプリケーションが最初にロードされるときに設定されます。 クライアント・コンテナーが Internet Information Server に保管されるので、 すべてのブラウザー・クライアントは、Active Server Page アプリケーションの使用にパラメーターを共用します。 この動作は、Active Server Page コードにとっては正常ですが、 ユーザーが同じ Active Server Page アプリケーションを使用して、 別の WebSphere Application Server を実行しようとすると、 そのこと自体がサポートされていないので、混乱を招く可能性があります。
デフォルトでは、 クライアント・コンテナーは、アプリケーション .ear ファイルを立ち上げ、 そのファイルを temp ディレクトリーに抽出してから、 スレッド・クラス・ローダーをセットアップして、 抽出された EAR ファイル・ディレクトリー、およびクライアント JAR マニフェストに含まれている JAR ファイルを使用します。 このプロセスには時間がかかり、 Java Native Interface (JNI) およびファイル・ロックによる JVM シャットダウンの制約もあって、 これらのファイルは、決してクリーンアップされません。
すなわち、クライアント・コンテナー launch() メソッドは、呼び出されるたびに、 ランダム・ディレクトリー名に対する EAR ファイルをハード・ディスク上の一時ディレクトリーに抽出します。 この後、現行の Java スレッド・クラス・ローダーは、この抽出されたディレクトリーをポイントするように変更され、 このディレクトリーが内部のファイルをロックします。 標準の J2EE Java クライアントでは、これらのファイルは、アプリケーションが終了すると、 自動的にクリーンアップされます。 このクリーンアップは、クライアント・コンテナーのシャットダウン・フックが呼び出されたときに行われ (ActiveX から EJB へのブリッジでは決して行われません)、 一時ディレクトリーがそのままそこに残されます。
これらの問題を回避するには、クライアント・コンテナー launch() メソッドを呼び出す前に、 com.ibm.websphere.client.applicationclient.archivedir Java システム・プロパティーを設定することにより、 EAR ファイルを抽出するディレクトリーを指定することができます。 ディレクトリーが存在しないか、空である場合には、EAR ファイルを通常に抽出してください。 EAR ファイルが前もって抽出されている場合には、そのディレクトリーが再利用されます。 この機能は、サーバー・プロセス (例えば、ASP) の場合に特に重要です。 サーバー・プロセスでは、停止したり、再始動したりして、launchClient() メソッドを何回も呼び出す場合があります。
EAR ファイルを更新する必要がある場合は、最初に、一時ディレクトリーを削除します。 クライアント・コンテナー・オブジェクトが次に作成されるとき、 新規 EAR ファイルが一時ディレクトリーに抽出されます。 一時ディレクトリーを削除しないか、 または別の一時ディレクトリーをポイントするようシステム・プロパティー値を変更しない場合、 クライアント・コンテナーは現在抽出されている EAR ファイルを再利用し、 変更された EAR ファイルを使用することはありません。
このシステム・プロパティーを使用しないことにした場合は、 定期的に Windows の temp ディレクトリーを調べて、WSTMP* サブディレクトリーを削除します。 これらのサブディレクトリーは、比較的短期間に、 ハード・ディスク上のかなりのスペースを浪費する可能性があります。