Oracle® Fusion Middleware Oracle WebLogic Server JCOM プログラマーズ ガイド 11g リリース 1 (10.3.1) B55534-01 |
|
戻る |
次へ |
以下の節では、WebLogic jCOM の概要を説明します。
WebLogic jCOM は、WebLogic Server でデプロイされる Java/Java EE オブジェクトと、Microsoft Office 製品ファミリ、Visual Basic オブジェクトおよび C++ オブジェクト、その他のコンポーネント オブジェクト モデル/分散コンポーネント オブジェクト モデル (COM/DCOM 準拠) 環境で使用できる Microsoft ActiveX コンポーネントとの間で双方向アクセスを可能にするソフトウェア ブリッジです。
一般に、Oracle では、Microsoft アプリケーションとの推奨される通信方法として Web サービスを想定しています。レガシー COM アプリケーションを .NET に移行し、このタイプの通信をご利用になることをお勧めします。jCOM は、Java と COM の統合が必要な中間ソリューションへの移行手段として提供されています。これは、小規模なプロジェクトやブリッジ ソリューションに適しています。
市販されている他の Java と COM のブリッジとは異なり、jCOM は特に、Java 側の WebLogic Server に使用できるように設計されています。jCOM を使用して、COM オブジェクトと任意の Java 仮想マシン (Java Virtual Machine: JVM) を通信させることはできません。また、jCOM では WebLogic Server スレッドを直接使用し、COM オブジェクトにサービスを公開する極めて堅牢な方法が提供されます。
WebLogic jCOM では、オブジェクト タイプの違いは意識されなくなります。つまり、COM クライアントには WebLogic Server オブジェクトが COM オブジェクトのように見え、WebLogic Server アプリケーションには COM コンポーネントが Java オブジェクトのように見えます。
WebLogic jCOM では、次のような双方向アクセスが可能です。
Microsoft COM クライアントが、それ自体 COM コンポーネントであるかのように WebLogic Server 内のオブジェクトにアクセスできます。
WebLogic Server 内のアプリケーションが、それ自体 Java オブジェクトであるかのように COM コンポーネントにアクセスできます。
このプログラミング ガイドでは、アクセスの方向によってアプリケーションを次の 2 つのタイプに分けています。
アプリケーション内で COM クライアントが WebLogic Server オブジェクトにアクセスする場合は、「COM-to-WLS」アプリケーション。
アプリケーション内で WebLogic Server が COM オブジェクトにアクセスする場合は、「WLS-to-COM」アプリケーション。
WebLogic jCOM は、Distributed Computing Environment Remote Procedure Call (DCE RPC) 上の COM/DCOM 分散コンポーネント インフラストラクチャと Java Remote Method Protocol/Internet Inter-ORB Protocol (JRMP/IIOP) 上の Remote Method Invocation (RMI) 分散コンポーネント インフラストラクチャの両方を実装する実行時コンポーネントを提供します。これにより、反対側のオブジェクトも、各環境のネイティブ オブジェクトのように見えます。
また、WebLogic jCOM は、両タイプのインタフェース間で変換を行う自動ツールも提供します。これは、前述のプロトコルで双方が通信するために必要な COM/DCOM プロキシと RMI スタブを自動的に構築します。
WebLogic jCOM は、DCOM 技術と RMI 技術の間で必要な変換をすべて行い、RMI クライアントとして WebLogic Server に接続します。それから、WebLogic Server にデプロイされているエンタープライズ Java Bean (Enterprise Java Bean: EJB) に、通常の EJB クライアントからの要求と同じように、要求を伝えます。
同様に、WebLogic Server にデプロイされているコンポーネントが DCOM オブジェクトによって提供されるサービスを要求すると、その要求は jCOM コンポーネントによって、WebLogic Server により発行される通常の RMI クライアント要求から DCOM 準拠要求に変換され、DCOM 環境内の該当するオブジェクトへ伝えられます。
また、WebLogic jCOM には、実行時ファイルのほかに、クライアントおよびサーバ環境をコンフィグレーションするための各種のツールとコンポーネントも用意されています。
WebLogic jCOM を使用する主な理由は以下のとおりです。
多様なハードウェアおよびソフトウェア プラットフォームにわたる分散アプリケーション間の相互運用性を実現するため。
Microsoft の開発ツールや開発スタッフの訓練に多額の投資をしてきたことから、Java クライアント ソフトウェアを記述せずにクライアント アプリケーションを WebLogic Server 上のビジネス ロジックへアクセスさせたいと考える人を援助するため。
完全に統合されたアプリケーションの構築と既存コンポーネントの再利用のために、COM/DCOM と Java 環境の両方で利用できるスキルを活用したいと考える e ビジネス アプリケーション構築者のニーズに応えるため。各環境の詳細は、別の環境に慣れた開発者にまったく意識させないようにすることができます。
WebLogic jCOM は、異種の環境およびアプリケーションの透過的な相互運用というソフトウェア業界の動向に従っています。
WebLogic jCOM サブシステムの主要な機能は以下のとおりです。
WebLogic jCOM はクライアントによってアクセスされるデータ型の存在を隠すので、最も適切な Java オブジェクトと COM コンポーネントが動的にマップされます。
WebLogic jCOM は、オブジェクト タイプのレイト バインディングとアーリー バインディングの両方をサポートしています。
COM コンポーネントをホストするマシン上にネイティブ コードは必要ありません。内部的には、WebLogic jCOM は Windows DCOM ネットワーク プロトコルを使用してローカルおよびリモート COM コンポーネントと pure Java 環境間の通信を実現します。
WebLogic jCOM は、Windows プラットフォームで動作するときのパフォーマンスを最大限に高めるオプションの「ネイティブ モード」をサポートしています。「DCOM モードとネイティブ モード」を参照してください。
WebLogic jCOM はイベント処理をサポートしています。たとえば、標準 COM イベント メカニズムを使用して Visual Basic から Java イベントにアクセスすることや、Java オブジェクトが COM コンポーネント イベントをサブスクライブすることができます。
jCOM アプリケーションの設計と構築の前に、いくつか重要な決定をする必要があります。決定すべきことは、次のとおりです。
アプリケーションにゼロ クライアント アーキテクチャを採用するかどうか (COM-to-WLS のみ)
アーリー バインディング モデルとレイト バインディング モデルのどちらを採用するか (COM-to-WLS のみ)
ネイティブ モードと DCOM モードのどちらで jCOM アプリケーションを実行するか (COM-to-WLS と WLS-to-COM の両方)
以下の節では、これらを決定する上で役立つ情報を提供します。
jCOM ゼロ クライアント デプロイメントは実装が簡単です。クライアント マシンには WebLogic jCOM 固有のソフトウェアは必要ありません。
オブジェクト参照モニカ (objref
) モニカ文字列を使用して、WebLogic Server の位置を COM クライアントにコード化します。objref
モニカを生成します。このモニカによって、WebLogic Server の IP アドレスとポートがエンコーディングされます。COM クライアント コードのモニカ文字列はプログラムで取得するか、コピーして貼り付けるか、あるいは WebLogic Server サーブレットから取得します。サーバの接続が確立されると、COM クライアントは COM オブジェクトを Java コンポーネント内のインタフェースにリンクできます。
次の表に、ゼロ クライアント実装のメリットとデメリットを示します。
メリット | デメリット |
---|---|
クライアント マシンのレジストリに WebLogic 固有のソフトウェアをロードする必要がない。 | WebLogic Server マシンの WL_HOME \bin ディレクトリから jCOM 固有のツールをいくつかコピーする必要がある。 |
レイト バインディングを使用するので (「アーリー バインディングとレイト バインディング」を参照)、Java コンポーネントの変更に関してレイト バインディングと同じ柔軟性が得られる。 | WebLogic Server の位置とポート番号を COM クライアントにコード化する必要があるため、サーバの位置が変更された場合、ソース コード内の参照を再生成し変更する必要がある。 |
アプリケーションでアーリー バインディングの利点が得られなくなる (「アーリー バインディングとレイト バインディング」を参照)。 |
WebLogic jCOM デプロイメントで多数の COM クライアント マシンが必要な場合は、ゼロ クライアント モデルのプログラミング モデルが適しています。
バインディングでは、ルーチンまたはモジュールのシンボリック アドレスを物理的アドレスに置換します。アーリー バインディングとレイト バインディングは、ともに別のアプリケーションのオブジェクトへのアクセスを提供します。
アーリー バインド アクセスでは、アクセスするオブジェクトに関する情報はプログラムのコンパイル中に提供され、それらのオブジェクトはコンパイル時に評価されます。この方法では、サーバ アプリケーションは型ライブラリを提供し、クライアント アプリケーションはクライアント システムにロードするためにそのライブラリを識別する必要があります。
レイト バインド アクセスでは、アクセスするオブジェクトに関する情報はコンパイル時に提供されず、これらのオブジェクトは実行時に動的に評価されます。このため、アクセスするメソッドとプロパティが実際に存在するかどうかは、プログラムを実行してみて初めて分かります。
次の表に、アーリー バインディング モデルのメリットとデメリットを示します。
アーリー バインディングのメリット | アーリー バインディングのデメリット |
---|---|
|
|
次の表に、レイト バインディング モデルのメリットとデメリットを示します。
レイト バインディングのメリット | レイト バインディングのデメリット |
---|---|
|
|
分散コンポーネント オブジェクト モデル (Distributed Component Object Model: DCOM) モードは、コンポーネント オブジェクト モデル (Component Object Model: COM) を使用して異なるコンピュータ上のオブジェクト間の通信をサポートします。WebLogic jCOM アプリケーションが DCOM モードで動作している場合、COM クライアントは WebLogic Server と DCOM プロトコルで通信します。
ネイティブ モードの場合、COM クライアントは WebLogic Server にネイティブ呼び出しを行い (COM-to-WLS)、WebLogic Server は COM アプリケーションにネイティブ呼び出しを行います。
ネイティブ モードではローカルのオペレーティング システムと CPU に対して個別にコンパイルおよび最適化された、ネイティブ コードの動的にロードされるライブラリ (DLL) が使用されるので、COM-to-WLS アプリケーションでも WLS-to-COM アプリケーションでも、ネイティブ モードを使用するとパフォーマンスが向上します。
また、ネイティブ モードで動作している COM-to-WLS アプリケーションは、COM クライアントと WebLogic Server との通信に WebLogic の T3/Internet InterORB (IIOP) プロトコルを使用します。これにより、以下の利点が得られます。
ネットワークの呼び出しが減るので、DCOM 呼び出しを使用した場合に比べてパフォーマンスが向上する。
たとえば、COM アプリケーションで、WebLogic Server への呼び出しによって値が返される 100 のデータ要素を含むベクトルを作成するとします。これを DCOM モードで行うと、サーバに対する往復のネットワーク呼び出しが 100 回必要です。ネイティブ モードでは、1 回の往復の呼び出しで済みます。
WebLogic Server のフェイルオーバ機能とロード バランシング機能を利用できる。
ただし、どちらのタイプのアプリケーションでも、作成されているネイティブ ライブラリは Windows 専用なので、ネイティブ レイト バインド アクセスの実装では、すべての COM クライアント マシンに WebLogic Server をインストールする必要があります。
また、WLS-to-COM アプリケーションの場合、ネイティブ モードで実行するには、WebLogic Server が Windows マシンで動作している必要があります。
次の表に、ネイティブ モード実装のメリットとデメリットを示します。
メリット | デメリット |
---|---|
COM-to-WLS アプリケーションでは、呼び出しがネットワーク上で行われないので、DCOM モードの場合に比べてパフォーマンスが向上する。 | COM-to-WLS アプリケーションでも WLS-to-COM アプリケーションでも、作成されているネイティブ ライブラリは Windows 専用なので、ネイティブ モードの実装では WebLogic Server をすべての COM マシンにインストールする必要がある。 |
COM-to-WLS アプリケーションの場合、WebLogic Server のロード バランシング機能とフェイルオーバ機能を利用できる。 | WLS-to-COM アプリケーションの場合、ネイティブ モードで動作するには、WebLogic Server が Windows マシンで実行されている必要がある。 |
WLS-to-COM アプリケーションの場合、COM オブジェクトを WebLogic Server と同じマシンにインストールすると、WebLogic Server でネットワーク呼び出しが不要になるので、パフォーマンスが向上する。 |