2 WebLogic jCOMの理解
注意:
WebLogic Server 12.2.1.4.0でWebLogic jCOMは非推奨になりました。jCOMは、JavaとCOMの統合が必要な中間ソリューションのための移行手段として提供されています。Oracleでは、Microsoftアプリケーションとの推奨される通信方法としてWebサービスおよびRESTを想定しています。このタイプの通信を使用するには、レガシーCOMアプリケーションを.NETに移行することをお薦めします。
この章の内容は以下のとおりです。
WebLogic jCOMとは
一般に、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"アプリケーション。
jCOMアーキテクチャ
WebLogic jCOMは、分散コンピューティング環境リモート・プロシージャ・コール上のCOM/DCOMの分散コンポーネント・インフラストラクチャと、Java リモートメソッドプロトコル/インターネットORB間プロトコル上のリモート・メソッド呼出し(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を使用する理由
WebLogic jCOMを使用する主な理由は以下のとおりです:
-
多様なハードウェアおよびソフトウェア・プラットフォームにわたる分散アプリケーション間の相互運用性を実現するため
-
Microsoftの開発ツールや開発スタッフの訓練に多額の投資をしており、クライアント・アプリケーションがWebLogic Serverのビジネス・ロジックにアクセスするようにJavaクライアント・ソフトウェアを記述することを望まない人々を援助するため
-
完全に統合されたアプリケーションの構築と既存コンポーネントの再利用のために、COM/DCOMとJava環境の両方で利用できるスキルを活用したいと考えるeビジネス・アプリケーション構築者のニーズに応えるため。各環境の詳細は、別の環境に慣れた開発者にまったく意識させないようにすることができます。
WebLogic jCOMは、異種の環境およびアプリケーションの透過的な相互運用というソフトウェア業界の動向に従っています。
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コンポーネント・イベントをサブスクライブすることができます。
WebLogic jCOMアプリケーションのプランニング
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マシンの |
|
レイト・バインディングを使用するので(「アーリー・バインディングとレイト・バインディング」を参照)、Javaコンポーネントの変更に関してレイト・バインディングと同じ柔軟性が得られます。 |
WebLogic Serverの位置とポート番号をCOMクライアントにコード化する必要があるため、サーバーの位置が変更された場合、ソース・コード内の参照を再生成し変更する必要があります。 アプリケーションでアーリー・バインディングの利点が得られなくなる(「アーリー・バインディングとレイト・バインディング」を参照)。 |
WebLogic jCOMデプロイメントで多数のCOMクライアント・マシンが必要な場合は、ゼロ・クライアント・モデルのプログラミング・モデルが適しています。
アーリー・バインディングとレイト・バインディング
バインディングでは、ルーチンまたはモジュールのシンボリック・アドレスを物理的アドレスに置換します。アーリー・バインディングとレイト・バインディングは、ともに別のアプリケーションのオブジェクトへのアクセスを提供します。
アーリー・バインド・アクセスでは、アクセスするオブジェクトに関する情報はプログラムのコンパイル中に提供され、それらのオブジェクトはコンパイル時に評価されます。この方法では、サーバー・アプリケーションはタイプ・ライブラリを提供し、クライアント・アプリケーションはクライアント・システムにロードするためにそのライブラリを識別する必要があります。
レイト・バインド・アクセスでは、アクセスするオブジェクトに関する情報はコンパイル時に提供されず、これらのオブジェクトは実行時に動的に評価されます。このため、アクセスするメソッドとプロパティが実際に存在するかどうかは、プログラムを実行してみて初めて分かります。
各バインディング・モデルのメリットとデメリット
次の表に、アーリー・バインディング・モデルのメリットとデメリットを示します。
| アーリー・バインディングのメリット | アーリー・バインディングのデメリット |
|---|---|
|
|
次の表に、レイト・バインディング・モデルのメリットとデメリットを示します。
| レイト・バインディングのメリット | レイト・バインディングのデメリット |
|---|---|
|
|
DCOMモードとネイティブ・モード
分散コンポーネント・オブジェクト・モデル(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アプリケーションでは、呼出しがネットワーク上で行われないので、パフォーマンスが向上します。 |