WebLogic jCOM プログラマーズ ガイド
|
 |
 |
|
以下の節では、WebLogic jCOM の概要を説明します。
WebLogic jCOM は、WebLogic Server でデプロイされる Java/J2EE オブジェクトと、Microsoft Office 製品ファミリ、Visual Basic オブジェクトおよび C++ オブジェクト、その他のコンポーネント オブジェクト モデル/分散コンポーネント オブジェクト モデル (COM/DCOM 準拠) 環境で使用できる Microsoft ActiveX コンポーネントとの間で双方向アクセスを可能にするソフトウェア ブリッジです。
一般に、BEA では、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 では、次のような双方向アクセスが可能です。
このプログラミング ガイドでは、アクセスの方向によってアプリケーションを次の 2 つのタイプに分けています。
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 環境内の該当するオブジェクトへ伝えられます。
分散環境において、リモート マシン上の COM オブジェクトにアクセスできるようにするには、dcomcnfg を使って、使用しているマシン上の DCOM をコンフィグレーションします。DCOM のコンフィグレーションの詳細については、『Configuring DCOM for Remote Access』 「http://j-integra.intrinsyc.com/support/com/doc/index.htm」を参照してください。
また、WebLogic jCOM には、実行時ファイルのほかに、クライアントおよびサーバ環境をコンフィグレーションするための各種のツールとコンポーネントも用意されています。
WebLogic jCOM を使用する主な理由は以下のとおりです。
WebLogic jCOM は、異種の環境およびアプリケーションの透過的な相互運用というソフトウェア業界の動向に従っています。
WebLogic jCOM サブシステムの主要な機能は以下のとおりです。
WebLogic Server には、ゼロ クライアント インストールを使用して、WebLogic Server 上にデプロイされている EJB に Excel Visual Basic アプリケーション (Visual Basic Application: VBA) クライアントからアクセスする方法を示すサンプルが含まれています。
ゼロ クライアント インストールでは、Windows クライアント マシンに WebLogic jCOM ソフトウェアが必要ありません。ただし、これを実現するには、サーブレットから「オブジェクト参照モニカ」を取り出して COM クライアント コードに配置する必要があります。
このサンプルを作成して実行する方法の詳細については、Web ページ WL_HOME\samples\server\examples\src\examples\jcom\package_summary.html を呼び出してください。
jCOM アプリケーションの設計と構築の前に、いくつか重要な決定をする必要があります。決定すべきことは、次のとおりです。
この節では、これらを決定する上で役立つ情報を提供します。JCOM の詳細については、J-Integra の Web サイトで提供されている COM のドキュメント 「http://j-integra.intrinsyc.com/support/com/doc/index.htm」を参照してください。
jCOM ゼロ クライアント デプロイメントは実装が簡単です。クライアント マシンには WebLogic jCOM 固有のソフトウェアは必要ありません。
オブジェクト参照モニカ (objref) モニカ文字列を使用して、WebLogic Server の位置を COM クライアントにコード化します。objref モニカを生成します。このモニカによって、WebLogic Server の IP アドレスとポートがエンコーディングされます。COM クライアント コードのモニカ文字列はプログラムで取得するか、コピーして貼り付けるか、あるいは WebLogic Server サーブレットから取得します。サーバの接続が確立されると、COM クライアントは COM オブジェクトを Java コンポーネント内のインタフェースにリンクできます。
次の表に、ゼロ クライアント実装のメリットとデメリットを示します。
|
|
|
|
|
|
|
|
WebLogic jCOM デプロイメントで多数の COM クライアント マシンが必要な場合は、ゼロ クライアント モデルのプログラミング モデルが適しています。
ゼロ クライアント実装の例については、インストールされている WebLogic Server の WL_HOME\samples\server\examples\src\examples\jcom\zeroclient ディレクトリにあるサンプルを参照してください。
バインディングでは、ルーチンまたはモジュールのシンボリック アドレスを物理的アドレスに置換します。アーリー バインディングとレイト バインディングは、ともに別のアプリケーションのオブジェクトへのアクセスを提供します。
アーリー バインド アクセスでは、アクセスするオブジェクトに関する情報はプログラムのコンパイル中に提供され、それらのオブジェクトはコンパイル時に評価されます。この方法では、サーバ アプリケーションは型ライブラリを提供し、クライアント アプリケーションはクライアント システムにロードするためにそのライブラリを識別する必要があります。
レイト バインド アクセスでは、アクセスするオブジェクトに関する情報はコンパイル時に提供されず、これらのオブジェクトは実行時に動的に評価されます。このため、アクセスするメソッドとプロパティが実際に存在するかどうかは、プログラムを実行してみて初めて分かります。
次の表に、アーリー バインディング モデルのメリットとデメリットを示します。
次の表に、レイト バインディング モデルのメリットとデメリットを示します。
分散コンポーネント オブジェクト モデル (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) プロトコルを使用します。これにより、以下の利点が得られます。
たとえば、COM アプリケーションで、WebLogic Server への呼び出しによって値が返される 100 のデータ要素を含むベクトルを作成するとします。これを DCOM モードで行うと、サーバに対する往復のネットワーク呼び出しが 100 回必要です。ネイティブ モードでは、1 回の往復の呼び出しで済みます。
ただし、どちらのタイプのアプリケーションでも、作成されているネイティブ ライブラリは Windows 専用なので、ネイティブ レイト バインド アクセスの実装では、すべての COM クライアント マシンに WebLogic Server をインストールする必要があります。ただし、COM アプリケーションを実行するマシンごとに別個の WebLogic Server ライセンスが必要というわけではありません。
また、WLS-to-COM アプリケーションの場合、ネイティブ モードで実行するには、WebLogic Server が Windows マシンで動作している必要があります。
次の表に、ネイティブ モード実装のメリットとデメリットを示します。
WebLogic jCOM では、次の COM の型の 2 次元配列を COM から Java へ渡せるようになりました。
|
|
|