|
|
|
|
|
|
| | | |
WebLogic jCOM プログラミング モデル
以下の節では、WebLogic jCOM を使用して Java と COM 間の通信を実装するいくつかの方法、および各実装の長所と短所について説明します。
WebLogic jCOM コンポーネント
BEA WebLogic jCOM を使用すると、Microsoft Windows 上で動作する COM クライアントから任意のオペレーティング システム上で動作する Java オブジェクト（Java コンポーネントなど）にアクセスできます。
つまり、WebLogic jCOM は、Java COM と Java を結ぶブリッジを作成するための実行時環境と必要なコンポーネントを提供するキットです。これから見ていくすべての例では、このブリッジは WebLogic Server マシン上に存在します。
jCOM.jar ランタイムは、ブリッジをコンパイルおよび実行するために必要です。ブリッジ自体はユーザによって作成される Java プロセスで、クライアントとサーバ間での COM と Java 間の通信を処理するためにバックグラウンドで動作します。以下の例に示す JCOMBridge.java ブリッジは、それらの例のためのブリッジとしてだけでなく、独自のブリッジを作成するための土台としても役立ちます。
実行時ファイルの他にも、WebLogic jCOM にはクライアントおよびサーバ環境をコンフィグレーションするためのツールとコンポーネントが用意されています。
Java 仮想マシンは、常に VB プロセスへの独立したプロセスとして（場合によっては別のマシン上で）実行されることに注意してください。WebLogic jCOM は、VB ウィンドウ内部に JavaBean を配置するために使用できません。これらは独立したプロセスに属するからです。しかし、Visual Basic プログラミングからパブリック Java クラスのすべてのパブリック メソッドおよびフィールドにアクセスできます。
COM とJava 間の通信は、以下のプログラミング モデルを使用して実現できます。
用語の定義
DCOM モード
DCOM（Distributed Component Object Model）モードは、Component Object Model（COM）を使用して異なるコンピュータ上のオブジェクト間の通信をサポートします。
ネイティブ モード
ネイティブ モードは、ネイティブ コード（DLL）を使用します。これらの DLL はローカルのオペレーティング システムと CPU 向けにコンパイルおよび最適化されているので、パフォーマンスが向上します。
ゼロ クライアント インストール
ゼロ クライアント インストールとは、Windows クライアント マシンにソフトウェアをインストールする必要がないことを意味します。デプロイメントのオーバーヘッドは存在しません。
レイト バインディング
レイト バインディングは、別のアプリケーションのオブジェクトへのアクセスを提供する手段です。レイト バインド アクセスでは、アクセスするオブジェクトに関する情報はコンパイル時に提供されず、これらのオブジェクトは実行時に動的に評価されます。このため、アクセスするメソッドとプロパティが実際に存在するかどうかは、プログラムを実行してみて初めて分かります。
アーリー バインディング
アーリー バインディングは、別のアプリケーションのオブジェクトへのアクセスを提供する手段です。アーリー バインド アクセスでは、アクセスするオブジェクトに関する情報はプログラムのコンパイル中に提供され、それらのオブジェクトはコンパイル時に評価されます。この方法では、サーバ アプリケーションは型ライブラリを提供し、クライアント アプリケーションはクライアント システムにロードするためにそのライブラリを識別する必要があります。
WebLogic jCOM プログラミング モデル
COM と Java 間の通信は、DCOM モードかネイティブ モードを使用して実装できます。どちらの方法でも、プログラミング モデルを選択できます。
すべての実装では、COM クライアントは Microsoft Windows プラットフォームで動作します。Java コンポーネントは、Java 2 Platform, Enterprise Edition 1.3 および WebLogic Server 6.1 上で動作します。クライアントとサーバ/ブリッジは、1 つのシステム実装の同じシステムで動作します。
DCOM ゼロ クライアント プログラミング モデル
DCOM ゼロ クライアント インストールは実装が簡単です。クライアント サイドには WebLogic jCOM 固有のソフトウェアは必要ありません。
ゼロ クライアント インストールではレイト バインディングが使用されるので、Java コンポーネントの変更に関してレイト バインディングと同じ柔軟性が得られます。ただし、この実装ではブリッジの位置とポート番号を COM クライアントにハード コード化する必要があります。このため、ブリッジの位置が変更された場合、ソース コード内の参照を再生成して変更する必要があります。
DCOM ゼロ クライアント インストールは、DCOM アーリー バインディング実装に比べてエラーが発生しやすくなります。
DCOM レイト バインド実装に比べ、DCOM ゼロ クライアント インストールでは実行時の初期化パフォーマンスが向上します。
図2-1 一般的な DCOM ゼロ クライアント実装の実行時インストール
クライアントが Java コンポーネントにアクセスするには、以下のことを行います。
objref モニカ文字列を使用して、WebLogic jCOM ブリッジの位置をクライアントにハード コード化します。objref モニカを生成します。このモニカによって、WebLogic jCOM ブリッジの IP アドレスとポートがエンコーディングされます。ブリッジ接続が確立されると、クライアントは COM オブジェクトを Java コンポーネント内のインタフェースにリンクできます。
ゼロ クライアント インストール実装の例については、インストールした WebLogic jCOM の samples\examples ディレクトリにある Zero Client Installation サンプルを参照してください。
DCOM レイト バインド プログラミング モデル
DCOM レイト バインド アクセスは実装が簡単です。また、オブジェクト参照が実行時にのみ評価されるので実装に柔軟性があります。しかし、コンパイル時に型チェックを実行できないので、エラーが発生しやすくなります。
図2-2 一般的な DCOM レイト バインド実装の実行時インストール
クライアントが Java コンポーネントにアクセスするために、以下のことが行われます。
DCOM レイト バインド実装の例については、インストールされている WebLogic jCOM のsamples\examples ディレクトリにある Late Bound Implementation サンプルを参照してください。
DCOM アーリー バインド プログラミング モデル
DCOM アーリー バインド アクセスは、実装が複雑です。これは、型ライブラリとラッパーを生成する必要があるからです。型ライブラリはクライアント サイドで、ラッパーはサーバ サイドで必要となります。クライアントとユーザが別個のマシンで動作している場合、型ライブラリとラッパーは同じマシン上で生成して、必要とされているシステムにコピーしなければなりません。
アーリー バインド アクセスは、レイト バインド アクセスが備えている柔軟性に欠けます。Java コンポーネントに変更を加えた場合、ラッパーと型ライブラリを再生成する必要があるからです。これに代わるハイブリッドな方法については、レイト バインド カプセル化プログラミング モデルを参照してください。
アーリー バインド アクセスでは、信頼性が向上します。コンパイル時の型チェックによりデバッグが容易になり、ユーザは型ライブラリを参照することができます。
DCOM レイト バインド実装に比べ、DCOM アーリー バインド実装では実行時のトランザクション パフォーマンスが向上しますが、実行時の初期化は低速化します。
図2-3 一般的な DCOM アーリー バインド実装の実行時インストール
クライアントが Java コンポーネントにアクセスするには、以下のことを行います。
DCOM アーリー バインド実装の例については、インストールされている WebLogic jCOM の samples\examples ディレクトリにある Early Bound Implementation サンプルを参照してください。
DCOM レイト バインド カプセル化プログラミング モデル
アーリー バインディングを使用済みで、Java コンポーネント インタフェースを変更するか、または単に将来の可能性に備えたい場合は、レイト バインド カプセル化を採用することをお勧めします。Java コンポーネントを変更すると、ラッパーの再コンパイルに加え、クライアント サイドで新しい型ライブラリを作成する必要があります。ラッパーと型ライブラリは相互に依存し合っており、バージョン固有のものだからです。こうした状況は、Java コンポーネント インタフェースの変更が特定のクライアント プログラムと無関係な場合にも起こり得ます。このため、この Java コンポーネントにアクセスするすべてのクライアント システムに新しい型ライブラリを再配布しなければならない場合もあります。
レイト バインド カプセル化方法を使用すると、アーリー バインド プログラミングの主要なメリットはそのままに、ラッパーと型ライブラリを必要としない柔軟なレイト バインド設計を実装できます。
次に説明する基本手順は Visual Basic クライアント向けのものですが、どのようなプログラミング言語にも適用することができます。
ネイティブ レイト バインド プログラミング モデル
ネイティブ レイト バインド アクセスは実装が簡単です。また、オブジェクト参照が実行時にのみ評価されるので実装に柔軟性があります。しかし、コンパイル時に型チェックを実行できないので、エラーが発生しやすくなります。
作成されているネイティブ ライブラリは Windows 専用なので、ネイティブ レイト バインド アクセスでは WebLogic jCOM ブリッジをクライアント マシンにインストールする必要があります。
DCOM レイト バインド実装に比べ、ネイティブ レイト バインド実装では実行時の初期化パフォーマンスが大幅に向上します。
図2-4 一般的なネイティブ レイト バインド実装の実行時インストール
ネイティブ モードの実装の詳細については、『WebLogic jCOM リファレンス』の「ネイティブ モード」を参照してください。
ネイティブ アーリー バインド プログラミング モデル
ネイティブ アーリー バインド アクセスは、実装が複雑です。これは、型ライブラリとラッパーを生成する必要があるからです。型ライブラリはクライアント サイドで、ラッパーはサーバ サイドで必要となります。クライアントとユーザが別個のマシンで動作している場合、型ライブラリとラッパーは同じマシン上で生成して、必要とされているシステムにコピーしなければなりません。
アーリー バインド アクセスは、レイト バインド アクセスが備えている柔軟性に欠けます。Java コンポーネントに変更を加えた場合、ラッパーと型ライブラリを再生成する必要があるからです。
アーリー バインド アクセスでは、信頼性が向上します。コンパイル時の型チェックによりデバッグが容易になり、ユーザは型ライブラリを参照することができます。
作成されているネイティブ ライブラリは Windows 専用なので、ネイティブ アーリー バインド アクセスでは WebLogic jCOM ブリッジをクライアント マシンにインストールする必要があります。
DCOM アーリー バインド実装に比べ、ネイティブ レイト バインド実装では実行時の初期化パフォーマンスが大幅に向上します。
ネイティブ レイト バインド実装に比べ、ネイティブ アーリー バインド実装では実行時の初期化が低速になりますが、トランザクション パフォーマンスが若干向上します。
図2-5 一般的なネイティブ アーリー バインド実装の実行時インストール
ネイティブ モードの実装の詳細については、『WebLogic jCOM リファレンス』の「ネイティブ モード」を参照してください。
|
|
|
