| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic jCOM プログラマーズ ガイド > WebLogic jCOM の概要 |
|
WebLogic jCOM プログラマーズ ガイド
|
以下の節では、WebLogic jCOM の概要を説明します。
WebLogic jCOM は、WebLogic Server でデプロイされる Java/J2EE オブジェクトと、Microsoft Office 製品ファミリ、Visual Basic オブジェクトおよび C++ オブジェクト、その他のコンポーネント オブジェクト モデル/分散コンポーネント オブジェクト モデル (COM/DCOM 準拠) 環境で使用できる Microsoft ActiveX コンポーネントとの間で双方向アクセスを可能にするソフトウェア ブリッジです。
通常 Microsoft のアプリケーションとの通信には、Web サービスを使用する方法が推奨されます。 この種の通信を利用するため、従来の COM アプリケーションから .NET へ移行する計画を立てることをお薦めします。 jCOM は、Java - COM 間の統合を必要とする暫定的なソリューションへの移行経路として提供され、 小規模なプロジェクトやブリッジ ソリューションに適しています。
市販されている他の Java - COM ブリッジとは異なり、jCOM は WebLogic Server において Java サイドで動作するように特別に設計されています。 jCOM を任意の Java 仮想マシン (JVM) と COM オブジェクトとの通信に使用することはできません。 なお、jCOM は WebLogic Server スレッドを直接使用するため、サービスを COM オブジェクトに対して公開するための非常に堅牢な手段となります。
注意: WebLogic jCOM 7.0 は、WebLogic Server の一部として動作します。以前のバージョンでは、スタンドアロンのソフトウェア ブリッジとして動作していました。WebLogic jCOM をスタンドアロンで実行しないでください。
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 (EJB) に、通常の EJB クライアントからの要求と同じように、要求を伝えます。
同様に、WebLogic Server にデプロイされているコンポーネントが DCOM オブジェクトによって提供されるサービスを要求すると、その要求は jCOM コンポーネントによって、WebLogic Server により発行される通常の RMI クライアント要求から DCOM 準拠要求に変換され、DCOM 環境内の該当するオブジェクトへ伝えられます。
実行時ファイルの他にも、WebLogic jCOM にはクライアントおよびサーバ環境をコンフィグレーションするためのツールとコンポーネントが用意されています。
WebLogic jCOM を使用する主な理由は以下のとおりです。
WebLogic jCOM は、異種の環境およびアプリケーションの透過的な相互運用というソフトウェア業界の動向に従っています。
WebLogic jCOM サブシステムの主要な機能は以下のとおりです。
WebLogic Server には、RPC スタイル Web サービスおよびメッセージスタイル Web サービスを作成する両方の例と、Web サービスを呼び出す Java および Microsoft VisualBasic クライアント アプリケーションの両方の例があります。
WebLogic Server には、次の各 jCOM サンプルが付属しています。
WL_HOME¥samples¥server¥src¥examples¥jcom ディレクトリにサンプルがあります。WL_HOME は、WebLogic Platform の最上位のインストール ディレクトリです。
サンプルを作成して実行する方法の詳細については、ブラウザで Web ページ WL_HOME¥samples¥server¥src¥examples¥jcom¥package_summary.html を呼び出してください。
jCOM アプリケーションの設計と構築の前に、いくつか重要な決定をする必要があります。決定すべきことは、次のとおりです。
jCOM ゼロ クライアント デプロイメントは実装が簡単です。クライアント マシンには WebLogic jCOM 固有のソフトウェアは必要ありません。
オブジェクト参照モニカ (objref) モニカ文字列を使用して、WebLogic Server の位置を COM クライアントにコード化します。objref モニカを生成します。このモニカによって、WebLogic Server の IP アドレスとポートがエンコーディングされます。COM クライアント コードのモニカ文字列はプログラムで取得するか、コピーして貼り付けるか、あるいは WebLogic Server サーブレットから取得します。サーバ接続が確立されると、COM クライアントは COM オブジェクトを Java コンポーネント内のインタフェースにリンクできます。
次の表に、ゼロ クライアント実装のメリットとデメリットを示します。
|
WebLogic Server マシンの WL_HOME¥bin ディレクトリから jCOM 固有のツールをいくつかコピーする必要がある。 |
|
|
レイト バインディングを使用するので (アーリー バインディングとレイト バインディングを参照)、Java コンポーネントの変更に関してレイト バインディングと同じ柔軟性が得られる。 |
WebLogic Server の位置とポート番号を COM クライアントにコード化する必要があるため、サーバの位置が変更された場合、ソース コード内の参照を再生成して変更しなければならない。 |
|
アプリケーションでアーリー バインディングの利点が得られなくなる (アーリー バインディングとレイト バインディングを参照)。 |
WebLogic jCOM デプロイメントで多数の COM クライアント マシンが必要な場合は、ゼロ クライアント モデルのプログラミング モデルが適しています。
ゼロ クライアント実装の例として、インストールされている WebLogic Server の WL_HOME¥samples¥server¥src¥examples¥jcom¥zeroclient ディレクトリにあるサンプルを参照してください。
バインディングでは、ルーチンまたはモジュールのシンボリック アドレスを物理的アドレスに置換します。アーリー バインディングとレイト バインディングは、ともに別のアプリケーションのオブジェクトへのアクセスを提供します。
アーリー バインド アクセスでは、アクセスするオブジェクトに関する情報はプログラムのコンパイル中に提供され、それらのオブジェクトはコンパイル時に評価されます。この方法では、サーバ アプリケーションは型ライブラリを提供し、クライアント アプリケーションはクライアント システムにロードするためにそのライブラリを識別する必要があります。
レイト バインド アクセスでは、アクセスするオブジェクトに関する情報はコンパイル時に提供されず、これらのオブジェクトは実行時に動的に評価されます。このため、アクセスするメソッドとプロパティが実際に存在するかどうかは、プログラムを実行してみて初めて分かります。
次の表に、アーリー バインディング モデルのメリットとデメリットを示します。
次の表に、レイト バインディング モデルのメリットとデメリットを示します。
アーリー バインディング実装の例として、インストールされている WebLogic Server の WL_HOME¥samples¥server¥src¥examples¥jcom¥earlybound ディレクトリにあるアーリー バインドのサンプルを参照してください。
レイト バインディング実装の例として、インストールされている WebLogic Server の WL_HOME¥samples¥server¥src¥examples¥jcom¥latebound ディレクトリにあるレイト バインドのサンプルを参照してください。
DCOM (Distributed Component Object Model) モードは、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/IIOP プロトコルを使用します。これにより、以下の利点が得られます。
ただし、どちらのタイプのアプリケーションでも、作成されているネイティブ ライブラリは Windows 専用なので、ネイティブ レイト バインド アクセスの実装では、すべての COM クライアント マシンに WebLogic Server をインストールする必要があります。ただし、COM アプリケーションを実行するマシンごとに別個の WebLogic Server ライセンスが必要というわけではありません。
また、WLS-to-COM アプリケーションの場合、ネイティブ モードで実行するには、WebLogic Server が Windows マシンで動作している必要があります。
次の表に、ネイティブ モード実装のメリットとデメリットを示します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
