Fusion Middleware Oracle WebLogic Server JCOMのプログラミング

11gリリース1 (10.3.6)

B61628-04(原本部品番号:E13725-05)

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- 新機能と変更点

2 WebLogic jCOMについて

- WebLogic jCOMとは

- 用語に関する重要な注意

- jCOMアーキテクチャ

- WebLogic jCOMを使用する理由

- WebLogic jCOMの機能

- WebLogic jCOMアプリケーションのプランニング

- ゼロ・クライアントのデプロイメント

- ゼロ・クライアント・デプロイメントのメリットとデメリット

- アーリー・バインディングとレイト・バインディング

- 各バインディング・モデルのメリットとデメリット

- DCOMモードとネイティブ・モード

- ネイティブ・モードのメリットとデメリット

- このリリースでのjCOM機能と変更点

3 COMクライアント・アプリケーションからWebLogic Serverへの呼出し

- ネイティブ・モードの特別な要件

- COMクライアントからWebLogic Serverを呼び出す主な手順

- WebLogic Serverの準備

- JavaラッパーおよびIDLファイルの生成 - アーリー・バインディングのみ

- アクセス制御の構成

- java.util.Collectionおよびjava.util.Iteratorへのアクセスの許可

- ejb20.basic.beanManagedへのアクセスの許可

- COMクライアントの準備

- 必要なファイルのインストール

- jCOMツール・ファイル

- WebLogic Serverクラス・ファイル - ネイティブ・モードのみ

- WebLogic Serverサーブレットからのオブジェクト参照モニカーの取得 - ゼロ・クライアントのみ

- JavaラッパーおよびIDLファイルの生成 - アーリー・バインディングのみ

- ラッパー・ファイルに関する注意

- クライアント・マシン・レジストリへのWebLogic Server JVMの登録

- JVMの登録解除

- ネイティブ・モードを選択している場合

- COMクライアント・アプリケーションのコード化

- レイト・バインド・アプリケーション

- アーリー・バインド・アプリケーション

- COMクライアントの起動

- ネイティブ・モードでのCOM-to-WLSアプリケーションの実行

- アウト・オブ・プロセスでJVMを実行するネイティブ・モード

- イン・プロセスでJVMを実行するネイティブ・モード

4 WebLogic ServerからCOMアプリケーションへの呼出し

- ネイティブ・モードの特別な要件

- WebLogic ServerからCOMアプリケーションを呼び出す主な手順

- COMアプリケーションの準備

- COMアプリケーションのコード化

- com2java GUIツールでのJavaクラスの生成

- WebLogic Server用のJavaクラスのパッケージ化

- COMアプリケーションの起動

- com2javaにより生成されたJavaクラスの使い方

- COMインタフェースからcom2javaにより生成されたJavaインタフェースの使い方

5 jCOMツールの詳細

- com2java

- com2javaの使い方

- 型ライブラリの選択

- Javaパッケージ名の指定

- オプション

- プロキシの生成

- com2javaにより生成されたファイル

- 列挙値

- COMインタフェース

- COMクラス

- java2com

- regjvm

- JVMモード

- DCOMモード

- ネイティブ・モード(アウト・オブ・プロセス)

- ネイティブ・モード(イン・プロセス)

- regjvm GUIツールのユーザー・インタフェース

- regjvm GUIツールのDCOMモード・オプション

- regjvm GUIツールのネイティブ・モード・オプション

- regjvm GUIツールのネイティブ・モード・イン・プロセス・オプション

- regjvmcmd

- regtlb

Oracle® Fusion Middleware

Oracle WebLogic Server JCOMのプログラミング

11gリリース1 (10.3.6)

B61628-04(原本部品番号:E13725-05)

2011年11月

このドキュメントでは、WebLogic Server Java Component Object (jCOM)を利用したアプリケーションを開発および構成する方法について説明します。

Oracle Fusion Middleware Oracle WebLogic Server JCOMのプログラミング, 11gリリース1 (10.3.6)

B61628-04

Copyright © 2007, 2011, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

「はじめに」では、このガイド『Oracle WebLogic Server JCOMのプログラミング』に使用されるドキュメント・アクセシビリティ機能および規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、このガイド(Oracle WebLogic Server JCOMのプログラミング)の内容と構成について説明します。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- 新機能と変更点

ドキュメントのスコープと対象読者

このドキュメントは、WebLogic Server Java Component Object (jCOM)を利用したアプリケーションを開発および構成するソフトウェア開発者を対象としています。また、WebLogic Serverを評価するビジネス・アナリストや、特定のアプリケーション用にWebLogic Server jCOMの使用を考えているシステム設計者にとって便利な情報も掲載しています。

このドキュメントのトピックでは、ソフトウェア・プロジェクトの設計および開発段階に関連する情報を提供します。また、プロジェクトのテストおよび本番前の段階で見つかるアプリケーションの問題を解決するうえで便利なトピックもあります。

このドキュメントでは、本番段階でのjCOMの管理、モニター、パフォーマンス・チューニングについては扱いません。これらのトピックに関するWebLogic Serverのドキュメントとリソースへのリンクについては、「関連ドキュメント」を参照してください。

このドキュメントは、Java EEおよびjCOMの概念に精通している読者を対象としています。このドキュメントでは、WebLogic Server jCOMが提供する付加価値機能と、jCOMアプリケーションを実行するWebLogic Server機能の使い方に関する主要な情報が重点的に扱われています。

このドキュメントの手引き

- この章「1概要とロードマップ」では、このマニュアルの構成を紹介します。

- 第2章「WebLogic jCOMについて」では、JavaからCOMへのサービスの概要を示します。また、WebLogic jCOMコンポーネントと機能についても説明します。

- 第3章「COMクライアント・アプリケーションからWebLogic Serverへの呼出し」では、WebLogic Server jCOMを使用して、COMクライアント・アプリケーションからWebLogic Serverにアクセスする方法を説明します。

- 第4章「WebLogic ServerからCOMアプリケーションへの呼出し」では、WebLogic Server jCOMを使用して、WebLogic ServerからCOMクライアント・アプリケーションにアクセスする方法を説明します。

- 第5章「jCOMツールの詳細」では、付加価値を提供するWebLogic jCOMツールを使用してjCOMアプリケーションをプログラム的に管理する方法について説明します。

関連ドキュメント

このドキュメントには、jCOMリソースの構成および管理に関する情報を掲載しています。

WebLogic Server関連でのjCOM情報については、次のドキュメントを参照してください。

- COMリソースの詳細は、『WebLogicリソースのセキュリティ』を参照してください。

新機能と変更点

このリリースで導入されたWebLogic Serverの新機能の一覧については、『Oracle WebLogic Serverの新機能』を参照してください。

2 WebLogic jCOMについて

この章では、WebLogic jCOMの概要を示します。WebLogic jCOMは、WebLogic ServerでデプロイされるJava/Java EEオブジェクトと、Microsoft Office製品ファミリ、Visual BasicオブジェクトおよびC++オブジェクト、その他のコンポーネント・オブジェクト・モデル/分散コンポーネント・オブジェクト・モデル(COM/DCOM準拠)環境で使用できるMicrosoft ActiveXコンポーネントとの間で双方向アクセスを可能にするソフトウェア・ブリッジです。

- WebLogic jCOMとは

- WebLogic jCOMを使用する理由

- WebLogic jCOMの機能

- WebLogic jCOMアプリケーションのプランニング

- このリリースでのjCOM機能と変更点

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間プロトコル上の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を使用する理由

WebLogic jCOMを使用する主な理由は以下のとおりです。

- 多様なハードウェアおよびソフトウェア・プラットフォームにわたる分散アプリケーション間の相互運用性を実現するため。

- Microsoftの開発ツールや開発スタッフの訓練に多額の投資をしてきたことから、Javaクライアント・ソフトウェアを記述せずにクライアント・アプリケーションをWebLogic Server上のビジネス・ロジックへアクセスさせたいと考える人を援助するため。

- 完全に統合されたアプリケーションの構築と既存コンポーネントの再利用のために、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マシンのWL_HOME\binディレクトリからjCOM固有のツールをいくつかコピーする必要があります。

レイト・バインディングを使用するので(「アーリー・バインディングとレイト・バインディング」を参照)、Javaコンポーネントの変更に関してレイト・バインディングと同じ柔軟性が得られます。

WebLogic Serverの位置とポート番号をCOMクライアントにコード化する必要があるため、サーバーの位置が変更された場合、ソース・コード内の参照を再生成し変更する必要があります。

アプリケーションでアーリー・バインディングの利点が得られなくなる(「アーリー・バインディングとレイト・バインディング」を参照)。

WebLogic jCOMデプロイメントで多数のCOMクライアント・マシンが必要な場合は、ゼロ・クライアント・モデルのプログラミング・モデルが適しています。

アーリー・バインディングとレイト・バインディング

バインディングでは、ルーチンまたはモジュールのシンボリック・アドレスを物理的アドレスに置換します。アーリー・バインディングとレイト・バインディングは、ともに別のアプリケーションのオブジェクトへのアクセスを提供します。

アーリー・バインド・アクセスでは、アクセスするオブジェクトに関する情報はプログラムのコンパイル中に提供され、それらのオブジェクトはコンパイル時に評価されます。この方法では、サーバー・アプリケーションは型ライブラリを提供し、クライアント・アプリケーションはクライアント・システムにロードするためにそのライブラリを識別する必要があります。

レイト・バインド・アクセスでは、アクセスするオブジェクトに関する情報はコンパイル時に提供されず、これらのオブジェクトは実行時に動的に評価されます。このため、アクセスするメソッドとプロパティが実際に存在するかどうかは、プログラムを実行してみて初めて分かります。

各バインディング・モデルのメリットとデメリット

次の表に、アーリー・バインディング・モデルのメリットとデメリットを示します。

アーリー・バインディングのメリット

アーリー・バインディングのデメリット

- レイト・バインド実装よりも信頼できます。

- コンパイル時の型チェックにより、デバッグが容易です。

- アプリケーションのエンド・ユーザーが型ライブラリを参照できます。

- レイト・バインドの実装に比べ、実行時のトランザクション・パフォーマンスが向上します。

- 型ライブラリとラッパーを生成する必要があるため、実装が複雑になります。

- クライアント側で型ライブラリ、サーバー側でラッパーが必要です。クライアントとサーバーが別個のマシンで動作している場合、型ライブラリとラッパーは同じマシン上で生成して、必要とされているシステムにコピーする必要があります。

- Javaコンポーネントに変更を加えた場合にラッパーとライブラリを再生成する必要があるため、レイト・バインド・アクセスが備えている柔軟性に欠けます。

- レイト・バインド実装に比べ、実行時の初期化が低速になります。

次の表に、レイト・バインディング・モデルのメリットとデメリットを示します。

レイト・バインディングのメリット

レイト・バインディングのデメリット

- 実装が容易です。

- 参照するオブジェクトが実行時にのみ評価されるので、実装に柔軟性があります。

- アーリー・バインド実装に比べ、実行時の初期化が高速になります。

- コンパイル時に型チェックが行われないので、エラーが発生しやすくなります。

- アクセスするメソッドとプロパティが実際に存在するかどうかは、プログラムを実行するまでわかりません。

- アーリー・バインド実行に比べ、実行時のトランザクション・パフォーマンスが劣ります。

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アプリケーションでは、呼出しがネットワーク上で行われないので、パフォーマンスが向上します。

このリリースでのjCOM機能と変更点

WebLogic jCOMでは、次のCOMの型の2次元配列をCOMからJavaへ渡せるようになりました。

表2-1 jCOMの2次元配列のサポート

COMの型

Visual Basicの型

Javaの型

I1、UI1

Byte

Byte

BOOL

Boolean

Boolean

I2、UI2

Integer

Short

CY、I8、UI8

Currency

Long

R8

Double

Double

DATE

Date

Date

I4、UI3、INT、UINT

Long

Int

3 COMクライアント・アプリケーションからWebLogic Serverへの呼出し

この章では、COMクライアントからWebLogic Serverオブジェクト上のメソッドを呼び出すためにWebLogic jCOMを使用する方法について説明します。

- ネイティブ・モードの特別な要件

- COMクライアントからWebLogic Serverを呼び出す主な手順

- WebLogic Serverの準備

- COMクライアントの準備

- ネイティブ・モードでのCOM-to-WLSアプリケーションの実行

ネイティブ・モードの特別な要件

COM-to-WLSアプリケーションをネイティブ・モードで実行するためには、WebLogic ServerをCOMクライアント・マシンにインストールする必要があります。

ネイティブ・モードの詳細は、「ネイティブ・モードでのCOM-to-WLSアプリケーションの実行」を参照してください。

COMクライアントからWebLogic Serverを呼び出す主な手順

この節では、COMクライアントからWebLogic Serverへの呼出しを行うための主な手順を簡単に説明します。詳細については、以降の節で説明します。

WebLogic Server側

1. アーリー・バインディングを使用している場合、java2comツールを実行してJavaラッパー・クラスとインタフェース定義言語(Interface Definition Language : IDL)ファイルを生成し、これらのファイルをコンパイルします。「JavaラッパーおよびIDLファイルの生成 - アーリー・バインディングのみ」を参照してください。

2. サーバー・リスニング・ポート上でCOM呼出しを有効化します。Oracle WebLogic Server管理コンソール・ヘルプのjCOMの有効化に関する項を参照してください。

3. COMクライアントにサーバー・クラスへのアクセスを許可します。「アクセス制御の構成」を参照してください。

4. 他の関連するコンソール・プロパティを構成します。Oracle WebLogic Server管理コンソール・ヘルプのサーバー: プロトコル: jCOMに関する項を参照してください。

COMクライアント側

1. jCOMツール・ファイルおよびWebLogic Serverクラス・ファイル(ネイティブ・モードの場合のみ)をインストールします。「必要なファイルのインストール」を参照してください。

2. ゼロ・クライアント・インストールの場合

- オブジェクト参照モニカー(object reference moniker: ORM)をWebLogic Server ORMサーブレットからプログラムとして取得するか、アプリケーションに貼りつけることで取得します。「WebLogic Serverサーブレットからのオブジェクト参照モニカーの取得 - ゼロ・クライアントのみ」を参照してください。

3. アーリー・バインディングを使用している場合

- WebLogic Serverマシン上で生成されたIDLファイルを取得して、型ライブラリにコンパイルします。

- 型ライブラリとサービス提供の対象となるWebLogic Serverを登録します。

上記の手順については、「JavaラッパーおよびIDLファイルの生成 - アーリー・バインディングのみ」を参照してください。

4. レジストリにWebLogic Server JVMを登録します。ネイティブ・モードでWebLogic Serverと通信する場合、ここで設定します。「クライアント・マシン・レジストリへのWebLogic Server JVMの登録」を参照してください。

5. COMクライアント・アプリケーションをコード化します。「COMクライアント・アプリケーションのコード化」を参照してください。

6. COMクライアントを起動します。「COMクライアントの起動」を参照してください。

WebLogic Serverの準備

以下の節では、COMクライアントがWebLogic Serverオブジェクト上のメソッドを呼び出せるように、WebLogic Serverを準備する方法について説明します。

JavaラッパーおよびIDLファイルの生成 - アーリー・バインディングのみ

1. JDKライブラリへのパスとweblogic.jarへのパスをCLASSPATHに追加します。例:

set CLASSPATH=%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic.jar;%CLASSPATH%

JAVA_HOMEは、JDKがインストールされているルート・フォルダ(デフォルトはc:\Oracle\Middleware\jdk160またはc:\Oracle\Middleware\jrockit_160)で、WL_HOMEは、WebLogic Platformソフトウェアがインストールされているルート・ディレクトリ(デフォルトはc:\Oracle\Middleware\wlserver_10.3)です。

2. java2comツールでjavaラッパー・ファイルとIDLファイルを生成します。

java com.bea.java2com.Main

java2com GUIが表示されます。

3. 次のように入力します。
Java Classes & Interfaces :変換するラッパー・クラスのリスト

Name of generated IDL File : IDLファイルの名前

Output Directory :ドライブ文字とルート・ディレクトリ\TLB

TLBはOLE型ライブラリです。

java2comツールは、指定されたクラスとメソッド・パラメータで使用される他のすべてのクラスを参照します。この作業は再帰的に行われます。ここでは、複数のクラスまたはインタフェースをスペースで区切って指定できます。

抽象クラスではなく、パラメータ・コンストラクタを持たないJavaのパブリック・クラスはすべて、COMクラスとしてアクセス可能になります。他のパブリック・クラス、およびすべてのパブリック・インタフェースは、COMインタフェースとしてアクセス可能になります。

この時点で「Generate」ボタンをクリックしてラッパーとIDLを作成すると、エラーが生成されます。これは、java2comツールのデフォルトで特定のクラスが省略されているためです。コンパイル中に生成されたエラーを参照することで、どのクラスで問題が発生しているか判別できます。

この問題を修正するには、java2comツールで「Names」ボタンをクリックして、必要なクラス・ファイルへのあらゆる参照を削除します。この例では、次の参照を削除する必要があります。

*.toString > ''''
class java.lang.Class > ''''

4. これらの参照が削除されると、ラッパーとIDLを生成できます。java2com GUIで「Generate」をクリックします。
java2comツールでは、Javaオブジェクトへのアクセスに使用されるDCOMマーシャリング・コードを含むJavaクラスが生成されます。これらの生成されたクラスは、WebLogic jCOMランタイムによって背後で使用されます。必要なのはこれらのクラスをコンパイルすることだけです。また、これらのクラスがCLASSPATHに含まれていることを確認してください。

アクセス制御の構成

COMクライアント・アプリケーションがアクセスする必要のあるクラスへのアクセス権をCOMクライアント・ユーザーに付与します。特定のアプリケーションによって、どのクラスを公開するかが決まります。

たとえば、COMクライアントが次の3つのクラスにアクセスする必要があるとします。

- java.util.Collection

- java.util.Iterator

- ejb20.basic.beanManaged

java.util.Collectionおよびjava.util.Iteratorへのアクセスの許可

1. WebLogic Server管理コンソールの左ペインで「サービス」ノードをクリックしてから、その下の「jCOM」ノードをクリックします。

2. 右ペインで、次のように入力します。

java.util.*

3. 「セキュリティ・ポリシーを定義」をクリックします。

4. 「ポリシー条件」ボックスで、「呼出し側をメンバーとするグループは」をダブルクリックします。

5. 「グループ名の入力」フィールドに、アクセスを許可するユーザー・グループの名前を入力します。

6. 「追加」をクリックします。

7. 「OK」をクリックします。

8. ウィンドウの右下にある「適用」をクリックします。

ejb20.basic.beanManagedへのアクセスの許可

ejb20.basic.beanManagedへのアクセスを許可するには、ステップ3のjava.util.*をejb20.basic.beanmanagedに置き換えて、「java.util.Collectionおよびjava.util.Iteratorへのアクセスの許可」の手順を繰り返します。

COMクライアントの準備

以下の節では、WebLogic Serverオブジェクト上のメソッドを呼び出せるようにCOMクライアントを準備する方法について説明します。

必要なファイルのインストール

WebLogic Serverオブジェクト上のメソッドを呼び出すために、クライアント・マシンにインストールしておく必要のあるファイルが多数あります。以下に示すように、このうち一部のファイルは、ネイティブ・モードでメソッドを呼び出す場合にのみ必要です。

jCOMツール・ファイル

jCOMツールを実行するために必要な5つのファイルと3つのフォルダ(全サブフォルダおよびファイルを含む)があります。これらのファイルは、WebLogic ServerがインストールされているマシンのWL_HOME\server\binディレクトリに格納されています。ファイルは次のとおりです。

- JintMk.dll

- ntvinv.dll

- regjvm.exe

- regjvmcmd.exe

- regtlb.exe

- regjvm (全サブフォルダおよびファイルを含む)

- regjvmcmd (全サブフォルダおよびファイルを含む)

- regtlb (全サブフォルダおよびファイルを含む)

jCOMツールの詳細は、第5章「jCOMツールの詳細」を参照してください。

WebLogic Serverクラス・ファイル - ネイティブ・モードのみ

ネイティブ・モードでCOM-to-WLSアプリケーションを実行するには、COMクライアント・マシンが特定のWebLogic Serverクラス・ファイルにアクセスできる必要があります。これらのファイルを取得するには、各COMクライアント・マシンにWebLogic Serverをインストールします。

WebLogic Serverサーブレットからのオブジェクト参照モニカーの取得 - ゼロ・クライアントのみ

オブジェクト参照モニカー(ORM)は、WebLogic Serverから取得できます。COMクライアント・アプリケーションからモニカーを使用できるので、regjvmcmdを実行する必要がなくなります。新規サーバーを作成しても、サーバーのホストとポートが同じであるかぎりモニカーは有効なままです。

COMクライアント・コードに対してORMを取得する方法が2つあります。

- WebLogic Server上で実行しているサーブレットを通じて、それを取得します。WebLogic Server上でWebブラウザを開き、http://[wlshost]:[wlsport]/bea_wls_internal/comに移動します。
ここでwlshostはWebLogic Serverマシンを示し、wlsportはサーバーのポート番号を示します。

- WebLogic Serverマシンの完全な名前またはTCP/IPアドレスと、ポート番号をパラメータとして指定して、com.bea.jcom.GetJvmMoniker Javaクラスを実行します。
java com.bea.jcom.GetJvmMoniker [wlshost] [wlsport]

objrefモニカーを示し、その使用方法を説明する長いメッセージが表示されます。また、表示されるテキストは自動的にクリップボードにコピーされるので、ソースに直接貼付けできます。戻されたobjrefモニカーを使用すれば、指定したマシンおよびポート上のWebLogic Serverインスタンスにアクセスできます。

JavaラッパーおよびIDLファイルの生成 - アーリー・バインディングのみ

クライアント側に割り当てられたラッパー・ファイルおよびインタフェース定義言語(Interface Definition Language: IDL)ファイルの生成を実行します。

1. IDLをクライアント・マシンにコピーします。
WebLogic Server上でjava2comツールの実行(「WebLogic Serverの準備」を参照)に成功した場合、IDLファイルがサーバー・マシン上に作成されています。このIDLファイルをクライアント・マシンにコピーして、このCOMアプリケーションの\TLBサブディレクトリに配置します。

注意:
同じマシン上でクライアントとサーバーを実行している場合、この手順は必要ありません。java2comツールの出力は、サンプルの\TLBサブディレクトリに書き込まれます。

2. IDLファイルをコンパイルして、型ライブラリを作成します。

midl containerManagedTLB.idl

このコマンドでMicrosoft IDLコンパイラMIDL.EXEを呼び出して、コンパイルを実行します。コンパイルの結果、containerManagedTLB.tlbという型ライブラリが作成されます。

3. 型ライブラリを登録し、サービスの対象となるJVMを設定します。

regtlb /unregisterall
regtlb containerManagedTLB.tlb registered_jvm

1行目は、登録済みの型ライブラリ・バージョンの登録を解除するためにregtlb.exeを呼び出します。2行目は、新しくコンパイルされた型ライブラリを登録します。

regtlbに渡される2番目のパラメータregistered_jvmは重要です。これは、型ライブラリにリンクされるJVMの名前を指定します。WebLogic jCOMランタイムでは、型ライブラリで定義されたオブジェクト呼出しを適切なラッパー・クラスにリンクするために、この情報が必要です。

WebLogic Server JVMは、regjvmツールを通じてクライアント・マシンのレジストリに登録されます。詳細は、「クライアント・マシン・レジストリへのWebLogic Server JVMの登録」を参照してください。

ラッパー・ファイルに関する注意

- 一般にラッパー・ファイルはサーバー上に配置し、コンパイルしておく必要があります。IDLファイルはクライアント上に配置し、コンパイルしておく必要があります。サーバーとクライアントが別々のマシンに存在するときに、クライアント側でラッパーとIDLを作成した場合、コンパイルしたラッパー・ファイルをサーバーに配布する必要があります。サーバー側でラッパーとIDLを作成した場合、IDLファイルをコンパイルして型ライブラリを作成することが可能なクライアントにIDLファイルを移動する必要があります。

- ラッパー・ファイルとIDLファイルは、java2comツールを1回実行することで作成する必要があります。サーバー上とクライアント上の両方でjava2comツールを別々に実行しようとすると、作成されたラッパー・ファイルとIDLファイルが通信できなくなります。IDLとラッパーは識別のために一意なスタンプを持ちます。ラッパーはjava2comツールの共通呼出しから作成されるIDLファイルとのみ通信できます。IDLファイルも、通信できるのは同じ条件で作成されたラッパーだけです。その結果、java2comツールを1回実行する必要があり、作成されるファイルは後で分散されます。Javaソース・コードに間違いがある場合や変更を加えるために、java2comツールを再度実行する必要がある場合は、すべてのラッパー・ファイル、IDLファイル、およびTLBファイルを削除し、手順をすべてやり直す必要があります。

- java2comツールを使用して非推奨のメソッドを含む(または参照する)クラスのラッパーを作成する場合、コンパイル時に非推奨の警告が表示されます。これらの警告は無視できます。WebLogic jCOMは、メソッドをCOMからアクセス可能にします。

- 生成されたラッパー・クラスは、CLASSPATHに含める必要があります。単にEJB jarに含めることはできません。

クライアント・マシン・レジストリへのWebLogic Server JVMの登録

サーバー名をWindowsレジストリに追加し、その名前をTCP/IPアドレスおよびWebLogicが受信するCOMリクエストをリスニングするクライアント・サーバー間の通信ポートに関連付けることで、ローカルJava仮想マシンに登録します。デフォルトは、localhost:7001です。

1. regjvm GUIツールを呼び出すと、次の画面が表示されます。

2. WebLogic Serverがローカル・ホスト以外で実行しており、7001以外のポートをリスニングしている場合、ホスト名(またはIPアドレス)およびポート番号を入力します。
regjvmのコマンド・ライン・バージョンを使用することもできます。

regjvmcmd servername localhost[7001]

JVMの登録解除

regjvm(またはregjvmcmd)ツールでは、古いエントリと同名の新しいエントリが入力されても、古いエントリは上書きされません。したがって、通信するマシンのホスト名またはポートを変更する必要がある場合は、古いエントリの登録を解除して新しいエントリを作成します。

Regjvmツール・ウィンドウでJVMを登録解除するには、登録を解除するJVMを選択して、「Delete」を選択します。

別の方法として、コマンド・ライン・ツールregjvmcmdからJVMの登録を解除します。

regjvmcmd /unregister servername

ネイティブ・モードを選択している場合

COMクライアントをネイティブ・モードで実行している場合、「regjvm」ウィンドウで「native mode」または「Native Mode Out-of-Process」ラジオ・ボタンをクリックするか、または/nativeパラメータを使用してregjvmcmdを呼び出します。この手順に関する詳細については、「ネイティブ・モードでのCOM-to-WLSアプリケーションの実行」を参照してください。

COMクライアント・アプリケーションのコード化

これで、WebLogic Serverオブジェクト上のメソッドを呼び出すことができます。これをコード化する方法は、レイト・バインディングを選択するか、アーリー・バインディングを選択するかによって異なります。

レイト・バインド・アプリケーション

次に示すVisual Basicアプリケーションのサンプルからの抜粋では、Account EJBのホーム・インタフェースmobjHomeのCOMバージョンの宣言に注意してください。このCOMオブジェクトは、サーバー側にあるAccountHomeインタフェースのインスタンスにリンクされます。

Dim mobjHome As Object
Private Sub Form_Load()
'Handle errors
On Error GoTo ErrOut '
Bind the EJB AccountHome object through JNDI
Set mobjHome = CreateObject("examplesServer:jndi:ejb20-containerManaged-AccountHome")

レイト・バインド・クライアントの確認済みの問題と回避策

オーバーロードされていながらパラメータの数が同じメソッドを処理する場合、WebLogic jCOMには問題があります。オーバーロードされたメソッド内のパラメータ数が異なる場合、そのような問題はありません。

パラメータ数が同じ場合には、呼出しに失敗します。

メソッドInitialContext.lookupはオーバーロードされています。

public Object lookup(String)
public Object lookup(javax.naming.Name)

ルックアップを実行するには、オブジェクトを作成するために特別なJNDIモニカーを使用する必要があります。

Set o = CreateObject("servername:jndi:objectname")

アーリー・バインド・アプリケーション

アーリー・バインド・コードの特徴は、オブジェクトとして宣言される変数の数が少ないことです。以前生成した型ライブラリを使用することにより、ここでオブジェクトを宣言できます。

「JavaラッパーおよびIDLファイルの生成 - アーリー・バインディングのみ」で生成した型ライブラリを使用してオブジェクトを宣言します。このVisual Basicコードからの抜粋では、IDLファイルはcontainerManagedTLBと呼ばれ、EJBはExamplesEjb20BasicContainerManagedAccountHomeと呼ばれます。

Dim objNarrow As New containerManagedTLB.JCOMHelper

ここで、オブジェクトのメソッドを呼び出すことができます。

Set mobjHome = objNarrow.narrow(objTemp, "examples.ejb20.basic.containerManaged.AccountHome")

COMクライアントの起動

COMクライアント・アプリケーションを起動します。

ネイティブ・モードでのCOM-to-WLSアプリケーションの実行

COM-to-WLSアプリケーションでは、ネイティブ・モードに「イン・プロセス」と「アウト・オブ・プロセス」の区別があります。

- アウト・オブ・プロセス - JVMは独自のプロセス内で作成され、COMプロセスとWebLogic Server JVMプロセスの間でプロセス間通信が発生します。

- イン・プロセス - WebLogic Server JVM全体がCOMプロセスに取り込まれます。つまり、COMクライアントのアドレス空間にロードされます。WebLogic Serverクライアント側クラスはこのJVM内に配置されています。

アプリケーションで使用するプロセスを指定するには、regjvm GUIツール・インタフェースで「Native mode in process」または「Native mode」ラジオ・ボタンを選択します。

アウト・オブ・プロセスでJVMを実行するネイティブ・モード

JVMをアウト・オブ・プロセスで実行する(ただし、ネイティブ・コードを使用してCOMクライアントに中のJavaオブジェクトへのアクセスを許可する)場合、次の手順に従います。

1. regjvm GUIツールを呼び出して、JVMをネイティブとして登録します。regjvmでは、WebLogic jCOMのCOM-to-WLSメカニズムの動作を円滑化にするために、様々なレジストリ・エントリが登録されます。JVMを登録する場合には、「JVM id」フィールドにサーバーの名前を指定する必要があります。たとえば、exampleServerでJCOMネイティブ・モードが有効になっている場合は、regjvmを使用して登録する際に、「JVM id」ボックスにexampleServerと入力します。

2. JVMが実行されていない場合は、「Advanced」ラジオ・ボタンをクリックして、「Launch Command」フィールドにJVMのパスを入力します。
regjvmツールの詳細は、第5章「jCOMツールの詳細」を参照してください。

3. アプリケーション・コードのmainセクションに次のコードを挿入して、WebLogic jCOMランタイムにJVMが呼出しを受け取る準備ができていることを知らせます。

com.bea.jcom.Jvm.register("MyJvm"):
public class MyJvm {
public static void main(String[] args) throws Exception {
// Register the JVM with the name "firstjvm"
com.bea.jcom.Jvm.register("firstjvm");
Thread.sleep(6000000); // Sleep for an hour
}

4. これで、Visual Basicからレイト・バインディングを使用して、JVMにロードできるJavaクラスのインスタンスをインスタンス化できます。

Set acctEJB = CreateObject("firstjvm.jndi.ejb20.beanManaged.AccountHome")

5. JVMを登録したら、標準WebLogic jCOM regtlbコマンドを使用してJavaオブジェクトにアーリー・バインド・アクセスします(regtlb はパラメータとして型ライブラリの名前とJVM名を取り、その型ライブラリに定義されているすべてのCOMオブジェクトをそのJVMに存在するものとして登録します)。
また、独自のインスタンシエータ(com.bea.jcom.Jvm.register(...)への追加パラメータ)をJVMに関連付けることによって、COMクライアントのかわりにJavaオブジェクトのインスタンス化を制御できます。これは、オブジェクト・ファクトリの一種です。

イン・プロセスでJVMを実行するネイティブ・モード

このテクニックを使用すると、実際にJVMをCOMクライアントのアドレス空間にロードできます。

再びregjvmコマンドを使用します。ただし、今度は追加パラメータを指定します。

注意:
JVMを登録する場合には、「JVM id」フィールドにサーバーの名前を指定する必要があります。たとえば、exampleServerでJCOMネイティブ・モードが有効になっているときに、regjvmを使用して登録する場合には、「JV id」ボックスにexampleServerと入力します。

最も単純な例は、Visual Basicを使用してJavaオブジェクトにレイト・バインド・アクセスすることです。まず、JVMを登録します。SunのJDK 1.3.1 (デフォルトでc:\Oracle\Middleware\jdk160にインストールされています)を使用し、WebLogic Serverがc:\Oracle\Middleware\wlserver_10.3\server\lib\weblogic.jarにインストールされており、Javaクラスがc:\pureに格納されている場合は、以下のregjvmツール画面のように設定します。

JVM名、CLASSPATH、およびJVM binディレクトリ・パスを指定します。

これで、Visual BasicからGetObjectメソッドを呼び出すことができるようになります。

MessageBox GetObject("MyJVM.jndi.ejb20.beanManaged.AccountHome")

regjvmツールの詳細は、第5章「jCOMツールの詳細」を参照してください。

4 WebLogic ServerからCOMアプリケーションへの呼出し

この章では、WLS-to-COMアプリケーションの1つである、WebLogic jCOMを使用してWebLogic ServerからCOMオブジェクト上にメソッドを呼び出すアプリケーションを準備およびデプロイする方法を説明します。

- ネイティブ・モードの特別な要件

- WebLogic ServerからCOMアプリケーションを呼び出す主な手順

- COMアプリケーションの準備

- com2javaにより生成されたJavaクラスの使い方

- COMインタフェースからcom2javaにより生成されたJavaインタフェースの使い方

ネイティブ・モードの特別な要件

ネイティブ・モードを使用するWLS-to-COMアプリケーションには、特別な要件が2つあります。

- COMアプリケーションをネイティブ・モードで実行するには、WebLogic ServerがCOMアプリケーション・マシンにインストールされている必要があります。

- ネイティブ・モードで実行するには、WebLogic ServerがWindowsマシンで動作している必要があります。

WebLogic ServerからCOMアプリケーションを呼び出す主な手順

この節では、WebLogic ServerからCOMアプリケーションへ呼び出す主な手順を簡単に説明します。詳細については、以降の節で説明します。

COM側

1. COMアプリケーションをコード化します。「COMアプリケーションのコード化」を参照してください。

2. com2javaツールでCOMオブジェクトからJavaクラスを生成します。「com2java GUIツールでのJavaクラスの生成」を参照してください。

3. WebLogic Server用にクラスをパッケージ化します。「WebLogic Server用のJavaクラスのパッケージ化」を参照してください。

4. COMアプリケーションを起動します。「COMアプリケーションの起動」を参照してください。

WebLogic Server側

1. サーバー・リスニング・ポート上でCOM呼出しを有効化します。Oracle WebLogic Server管理コンソール・ヘルプのjCOMの有効化に関する項を参照してください。

2. 他の関連するコンソール・プロパティを構成します。Oracle WebLogic Server管理コンソール・ヘルプのサーバー: プロトコル: jCOMに関する項を参照してください。
WebLogic ServerとCOMアプリケーションをネイティブ・モードで通信させる場合は、管理コンソールで有効化します。ネイティブ・モードを使用するかどうかを判断する際は、第2章「DCOMモードとネイティブ・モード」を参照してください。

3. 他のJavaオブジェクトと同じようにCOMオブジェクトを使用します。

COMアプリケーションの準備

以下の節では、WebLogic Serverがオブジェクトでメソッドを呼び出せるようCOMクライアントを準備する方法について説明します。

COMアプリケーションのコード化

必要に応じてCOMアプリケーションをコード化します。

com2java GUIツールでのJavaクラスの生成

COM型ライブラリに対してcom2java GUIツールを実行すると、COM型ライブラリ内のクラスとインタフェースに対応するJavaクラス・ファイルの集合が生成されます。

以降で、GUIツールでのJavaクラスの生成を示します。WebLogic jCOMツール全般の詳細は、第5章「jCOMツールの詳細」を参照してください。

1. com2java GUIツールを実行するには、次の手順に従います。

1. WEBLOGIC_HOME /server/binディレクトリに移動します(または、このディレクトリをCLASSPATHに追加します)。

2. COMマシンでコマンド・シェルを開き、com2java.exeファイルを起動します。

> com2java

2. 一番上のフィールドで適切な型ライブラリを選択し、「Java package」テキスト・ボックスに、生成されたファイルを格納するパッケージの名前を入力します。com2javaツールは、特定の型ライブラリに対して指定した直前のパッケージ名を記憶しています。

3. 「Generate Proxies」をクリックして、Javaクラス・ファイルを生成します。

WebLogic Server用のJavaクラスのパッケージ化

COMオブジェクトをEJBから呼び出す場合は、WebLogic Serverが検出できるように、com2javaで生成するクラス・ファイルをEJB .jarにパッケージ化する必要があります。生成したファイルは、特定のパッケージに格納します。たとえば、Excel型ライブラリのファイルをすべてexcelというJavaパッケージに格納できます。

EJB .jarファイルのパッケージ化の詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のEJBの実装に関する項を参照してください。

COMアプリケーションの起動

Javaクラス・ファイルを生成して適切にパッケージ化したら、COMアプリケーションを起動すれば、WebLogic Serverに公開するCOMオブジェクトをインスタンス化および実行できます。

com2javaにより生成されたJavaクラスの使い方

com2javaツールは、型ライブラリ内でCOMクラスを発見するたびにそのCOMクラスにアクセスするためのJavaクラスを生成します。生成されたJavaクラスは、複数のコンストラクタを持ちます。

- デフォルト・コンストラクタは、認証なしでローカル・ホスト上にCOMクラスのインスタンスを作成します。

- 2番目のコンストラクタは、認証なしで特定のホスト上にCOMクラスのインスタンスを作成します。

- 3番目のコンストラクタは、特定の認証でローカル・ホスト上にCOMクラスのインスタンスを作成します。

- 4番目のコンストラクタは、特定の認証で特定のホスト上にCOMクラスのインスタンスを作成します。

- 最後のコンストラクタは、戻されたオブジェクト参照をラップできます。これはCOMクラスのインスタンスを参照します。

以下にDataLabelProxyクラスから生成されたコンストラクタのサンプルを示します。

public DataLabelProxy() {}

public DataLabelProxy(Object obj) throws java.io.IOException {
super(obj, DataLabel.IID);
}
protected DataLabelProxy(Object obj, String iid) throws
java.io.IOException
{
super(obj, iid);
}
public DataLabelProxy(String CLSID, String host, boolean
deferred) throws java.net.UnknownHostException,
java.io.IOException{ super(CLSID, DataLabel.IID, host, null);
}
protected DataLabelProxy(String CLSID, String iid, String host,
AuthInfo authInfo) throws java.io.IOException { super(CLSID,
iid, host, authInfo);
}

COMインタフェースからcom2javaにより生成されたJavaインタフェースの使い方

COMインタフェースのメソッドは、特定のインタフェースを介してオブジェクトの参照を戻すことができます。

たとえば、Excel型ライブラリ(Excel8.olb)は、_Application COMインタフェースを定義し、そのメソッドAddはCOM IDLで次のように定義されます。

[id(0x0000023c), propget, helpcontext(0x0001023c)]
HRESULT Workbooks([out, retval] Workbooks** RHS);

このメソッドは、Workbooks COMインタフェースを実装するオブジェクトの参照を返します。Workbooksインタフェースは_Applicationインタフェースと同じ型ライブラリに定義されているので、com2javaツールは作成する_Application Javaインタフェースに次のメソッドを生成します。

/** * getWorkbooks.
*
* @return return value. An reference to a Workbooks
* @exception java.io.IOException If there are communications problems.
* @exception com.bea.jcom.AutomationException If the remote server throws an exception. */
public Workbooks getWorkbooks () throws java.io.IOException, com.bea.jcom.AutomationException;
It is revealing to look at the implementation of the method in the generated _ApplicationProxy Java class:
/**
* getWorkbooks.
*
* @return return value. An reference to a Workbooks
* @exception java.io.IOException If there are communications
problems.
* @exception com.bea.jcom.AutomationException If the remote
server throws an exception.
*/
public Workbooks getWorkbooks () throws java.io.IOException,
com.bea.jcom.AutomationException{ com.bea.jcom.MarshalStream
marshalStream = newMarshalStream("getWorkbooks");
marshalStream = invoke("getWorkbooks", 52, marshalStream);
Object res = marshalStream.readDISPATCH("return value");
Workbooks returnValue = res == null ? null : new
WorkbooksProxy(res);
checkException(marshalStream,
marshalStream.readERROR("HRESULT"));
return returnValue;
}

この例にもあるように、getWorkbooksメソッドは生成されたWorkbooksProxy Javaクラスを内部的に利用します。前述のとおり、com2javaツールは、Workbooks戻り値型を持つメソッドを生成します。Workbooksインタフェースは_Applicationと同じ型ライブラリに定義されているからです。

Workbooksインタフェースが異なる型ライブラリに定義されている場合、WebLogic jCOMは次のコードを生成します。

/**
* getWorkbooks.
*
* @return return value. An reference to a Workbooks
* @exception java.io.IOException If there are communications
problems.
* @exception com.bea.jcom.AutomationException If the remote server
throws an exception.
*/
public Object getWorkbooks () throws java.io.IOException,
com.bea.jcom.AutomationException;
In this case, you would have to explicitly use the generated proxy class to access the returned Workbooks:
Object wbksObj = app.getWorkbooks();
Workbooks workbooks = new WorkbooksProxy(wbObj);

5 jCOMツールの詳細

この章では、jCOMアプリケーションで使用されるツールの詳細を示します。これらのツールは、com2java、java2com、regjvm、regjvmcmd、regtlbなどです。

- com2java

- java2com

- regjvm

- regjvmcmd

- regtlb

com2java

WebLogic jCOMのcom2javaツールは、型ライブラリから情報を読み込み、その型ライブラリに定義されているCOMクラスおよびインタフェースにアクセスするためのJavaファイルを生成します。

型ライブラリには、COMクラス、インタフェース、およびその他のコンストラクトが登録されています。通常、これらはVisual C++やVisual BASICなどの開発ツールによって生成されます。

このため、一部の型ライブラリは簡単に識別できます。拡張子olbまたはtlbで終わるファイルは、確実に型ライブラリです。しかし、型ライブラリが実行ファイルなどの他のファイルに格納される場合は、把握しづらくなります。Visual BASICでは、生成した実行ファイルに型ライブラリを格納します。

com2javaの使い方

com2javaは、コマンド・シェルで入力するか、そのアイコンをダブルクリックして起動します。

com2javaを起動すると、次のダイアログが表示されます。

型ライブラリの選択

ツールで処理する型ライブラリを選択するには、「Select」ボタンをクリックします。

型ライブラリは、COMコンポーネントを含んでいる実行ファイルやダイナミック・リンク・ライブラリ(dynamic link library: DLL)ファイルなどの内部に隠されている場合もあります。

com2javaツールは、以前にオープンしてそのプロキシを生成した型ライブラリのリストを記憶しています。

Javaパッケージ名の指定

com2javaツールは、型ライブラリのCOMクラスおよびインタフェースに対応するJavaソース・ファイルを生成します。生成したファイルは、特定のパッケージに格納します。たとえば、Excel型ライブラリのファイルをすべてexcelというJavaパッケージに格納できます。

「Java package」テキスト・ボックスに、生成されたファイルを格納するパッケージの名前を指定します。

com2javaツールは、特定の型ライブラリに対して指定した直前のパッケージ名を記憶しています。

オプション

「Options」ボタンをクリックすると、以下で説明するcom2java用のオプションを選択するためのダイアログ・ボックスが表示されます。これらのオプションは、com2javaのセッション間で自動的に保存されます。特定のプロキシの生成処理でのみオプションが必要な場合は、プロキシの生成後にオプションをリセットします。

オプション

説明

Clash Prefix

型ライブラリに定義されているCOMインタフェースのメソッドがすでにJavaで使用されているメソッド(getClass()メソッドなど)と衝突する場合、com2javaは生成したメソッドの名前の先頭にzz_という文字列(デフォルト)を付けます。

Lower case method names

Javaメソッド名の命名規則では、メソッド名は小文字で開始する必要があります。com2javaツールはデフォルトでこの規則を採用し、それに応じてメソッド名を変更します。com2javaでこの規則を無視する場合は、「Options」ダイアログ・ボックスの「Lowercase method names」チェック・ボックスを選択解除します。

Only generate IDispatch

WebLogic jCOMは、IDispatchおよびvtableアクセスを使用したCOMオブジェクトの呼出しをサポートしています。このオプションを選択すると、すべての呼出しはIDispatchインタフェースを使用して行われます。

Generate retry code on '0x80010001 - Call was rejected by callee'

COMサーバーがビジーの場合、エラー・コードを受け取る場合があります。このオプションを選択すると、このエラー・コードを受け取るたびにコードが再試行されます。

Generate Arrays as Objects

SAFEARRAYのパラメータは、生成されるjava.lang.Object型の対応するJavaパラメータを持っています。これは、Variantの外部の2次元配列をJavaからCOMオブジェクトに受け渡す場合、またはCOMオブジェクトから受け渡す場合に必要です。
このオプションは、実際に渡されるものを変更しません - それは依然として配列であり、生成されたJavaインタフェースに存在します。生成されたメソッド・プロトタイプで配列型を生成せずに、「Object」を指定します。これは、2D配列を受け渡すときに役立ちます - COM IDLでは、次元の数はSAFEARRAYに対して指定されず、また、「Generate Arrays as Objects」オプションをチェックしなかった場合、WebLogic jCOMは単一要素配列を受け渡して対応するプロトタイプを生成するものと見なします。

このオプションを選択し、com2javaで、たとえば「String[]」のかわりに「Object」を生成することにより、自由に2D文字列配列を受け渡すことができます。

Prompt for names for imported tlbs

型ライブラリは、別の型ライブラリをインポートする場合があります。インポートされた型ライブラリのプロキシも生成する場合、このオプションを選択するとこれらのプロキシのパッケージ名を指定できます。

Don't generate dispinterfaces

このオプションを選択すると、ディスパッチ・インタフェースとして定義されているインタフェースのプロキシの生成が禁止されます。

Generate deprecated constructors

生成されるプロキシには、現在は非推奨のコンストラクタがいくつか含まれます。これら非推奨のコンストラクタを生成したいときは、このオプションを選択します。

Don't rename methods with same names

COMクラスで名前の競合が検出された場合、com2javaはそのメソッドの1つの名前を自動的に変更します。このオプションを選択すると、名前の自動変更が無効になります。

Ignore conflicting interfaces

COMクラスが同名のメソッドを定義する複数のインタフェースを実装する場合、このオプションを選択すると、対応するJavaクラスは余計なインタフェースを実装しません。生成されるgetAsXXXメソッドを使用すれば、これらのインタフェースに引続きアクセスできます。生成されるコメントを参照してください。。

Generate Java Abstract Window Toolkit (AWT) classes

JavaクラスをGUIクラスとして生成します。ActiveXコントロールをJavaフレームに埋め込むために使用します。

プロキシの生成

「Generate Proxies」ボタンをクリックすると、com2javaツールによって生成されるJavaファイルを格納するディレクトリを選択できます。

ディレクトリを選択すると、com2javaは型ライブラリを解析し、対応するファイルを指定したディレクトリに出力します。すでにディレクトリにJavaソース・ファイルが存在する場合、WebLogic jCOMは警告メッセージを発行し、操作を取り消すことができるようにします。

com2javaにより生成されたファイル

com2javaツールは、型ライブラリに含まれる以下の3種類のコンストラクトを扱います。

- 列挙値

- COMインタフェース

- COMクラス

この節では、これらのコンストラクトについて説明します。

生成されたJavaファイルを使用してCOMオブジェクトを操作する方法については、アクセスするCOMオブジェクトに関するドキュメントを参照してください。

たとえば、com2javaをExcel型ライブラリに対して実行する場合、生成されるJavaファイルはMicrosoft Excel COM APIに対応しています。このため、Microsoft Excelのプログラミング・ドキュメントを参照する必要があります。たとえば、Excel 2000 COM APIについては下記を参照します。

http://msdn.microsoft.com/library/default.asp?URL=/library/officedev/off2000/xltocobjectmodelapplication.htm

列挙値

Javaでは、列挙値はjava.util.Enumerationで表されるリストです。型ライブラリに列挙値が含まれている場合、WebLogic jCOMはその列挙中の要素ごとの定数定義を含んだJavaインタフェースを生成します。

COMインタフェース

WebLogic jCOMは、2種類のインタフェースを処理します。1つはディスパッチ・インタフェースです。このメソッドにはCOM IDispatchメカニズムを使用しないとアクセスできません。もう1つはデュアル・インタフェースです。このメソッドは直接呼び出すことができます(vtblアクセス)。

型ライブラリに定義されているCOMインタフェースごとに、com2javaツールはJavaインタフェースとJavaクラスの2つのJavaファイルを生成します。

生成されるJavaインタフェースの名前は、COMインタフェースの名前と同じです。たとえば、COMインタフェース名がIMyInterfaceの場合、com2javaツールはIMyInterfaceというJavaインタフェースをIMyInterface.javaファイルに生成します。

com2javaが生成するもう1つのファイルはJavaクラスです。このファイルには、インタフェースを実装するCOMオブジェクトにアクセスするためのコードと、インタフェースを実装するJavaクラスのメソッドをCOMオブジェクトが呼び出すためのコードが含まれます。生成されるJavaクラスの名前は、インタフェースの名前に「Proxy」を付加したものです。前項の例では、WebLogic jCOMはIMyInterfaceProxyというJavaクラスをIMyInterfaceProxy.javaというファイルに生成します。

COMインタフェースのメソッドごとに、WebLogic jCOMはJavaインタフェース内に対応するメソッドを生成します。インタフェース内に生成される一部の定数は、生成されるコメントが示すように無視して構いません。

WebLogic jCOMは、インタフェースとそのメソッドを記述した型ライブラリからコメントを取り出し、生成されるjavadocコメントで使用します。

COMクラス

COMクラスは、1つまたは複数のCOMインタフェースを実装します。これは、Javaクラスが1つまたは複数のJavaインタフェースを実装できるのと同じです。

型ライブラリのCOMクラスごとに、com2javaツールは、そのCOMクラスと同名の対応するJavaクラスを生成します。WebLogic jCOMは、複数のインタフェースを実装するクラスもサポートしています。

WebLogic jCOMが生成するJavaクラスを使用すると、対応するCOMクラスにアクセスできます。

特殊なケース - ソース・インタフェース(イベント)

COMクラスは、インタフェースをソース・インタフェースとして指定できます。このため、そのインタフェースを実装するCOMクラスのインスタンスは、そのインタフェースに定義されているイベントをサブスクライブできます。サブスクライブしたオブジェクトに対してインタフェース内のメソッドが呼び出されます。

注意:
com2javaツールが型ライブラリ内のインタフェースをイベント・インタフェースとして扱うには、そのインタフェースをソース・インタフェースとして使用するCOMクラスが少なくとも1つは型ライブラリに存在している必要があります。

COMイベントは接続ポイントとソース・インタフェースを使用して動作しますが、Javaのイベント・メカニズムはそれとは異なります。com2javaツールは、COMメカニズムをJavaプログラムから完全に隠し、標準のJavaテクニックを利用してイベントを提供します。

具体的には、com2javaはCOMクラスにアクセスするために生成したJavaクラスに2つのメソッドを追加します。

com2javaツールは、クラスがインタフェースをソース・インタフェースとして使用していることを検出すると、そのインタフェース用の特殊なコードを生成します。それは、Javaイベントの命名規則に従って、インタフェースをjava.util.EventListener Javaインタフェースから導出します。

もう1つのJavaイベントの規則は、インタフェースの各メソッドは単一のパラメータを持つ必要があるということです。これは、java.util.EventObject Javaクラスから派生したクラスのインスタンスです。

Javaイベント関連の規則の3つめは、アダプタ・クラスの使用です。このクラスは、イベント・インタフェースを実装し、インタフェースのメソッド用の空のデフォルト実装を提供します。イベントにサブスクライブされるクラスを作成する開発者は、インタフェースのすべてのメソッドを実装する必要がありません(特に大規模なインタフェースを使用するときに手間になります)。

イベント・インタフェースごとに、WebLogic jCOMはアダプタ・クラスを生成します。

java2com

java2comは、どのプラットフォームでも実行できます。WebLogic jCOMランタイムweblogic.jarがCLASSPATH環境変数に含まれていることを確認してください。

java2comツールは、Javaクラスを(Java reflectionメカニズムを使用して)解析し、以下のものを出力します。

- COMインタフェース定義言語(Interface Definition Language: IDL)ファイル。

- pure Java DCOMマーシャリング・コード(ラッパー)。これは、vtable (レイト・バインド)アクセスを使用してCOMからJavaオブジェクトへのアクセスを容易にするためにWebLogic jCOMランタイムによって使用されます。

これらのファイルを生成した後、MicrosoftのMIDLツールを使用してIDLファイルをコンパイルします。

IDLファイルとラッパーを生成するには、まず次のコマンドを使用してjava2comツールを起動します。

java com.bea.java2com.Main

java2comツールでは、次のダイアログ・ボックスを表示します。

このダイアログ・ボックスには、以下のフィールドが存在します(構成の変更は、ダイアログ・ボックスの終了時に自動的に保存されます)。

フィールド

説明

Java Classes and Interfaces

java2comが解析する「ルート」Javaクラスとインタフェースです。これらは、CLASSPATHでアクセスできる必要があります。WebLogic jCOMはこれらのクラスを解析し、COM IDL定義と、COMからJavaクラスにアクセスできるJava DCOMマーシャリング・コードを生成します。次に、そのクラスのパラメータまたはフィールドで使用されるクラスまたはインタフェースに対して同じ解析を再帰的に実行し、同様にアクセスできるすべてのJavaクラスとインタフェースを解析します。
クラス名はスペースで区切って入力します。「...」ボタンをクリックすると、ダイアログにクラスのリストが表示されるので、そのリストに対して追加または削除を実行できます。

Name of generated IDL File

生成されるCOMインタフェース定義言語(IDL)ファイルの名前。myjvmと指定した場合は、myjvm.idlが生成されます。この名前は、MicrosoftのMIDLコンパイラを使用してmyjvm.idlをコンパイルするときに生成される型ライブラリの名前にも使用されます。

Output Directory

java2comが生成したファイルを出力するディレクトリ。デフォルトはカレント・ディレクトリ(".")です。

Dump Analysis

java2comが発見したクラスをそのまま表示します。

「Save settings」と「Load settings」

「Save settings」ボタンをクリックすると、現在のjava2com設定が保存されます。この操作を行ってから、「Generate」をクリックします。
java2comは、起動時にカレント・ディレクトリにjava2com.ser設定ファイルが存在するかどうかをチェックします。存在する場合、そのファイルから設定を自動的にロードします。

Names

「Names」ボタンをクリックすると、次のダイアログ・ボックスが表示されます。
クラス/インタフェース名ドロップダウン・リストから「*」を選択すると、メンバー(フィールドまたはクラス)名の名前を入力するためのテキスト・ボックスが表示されます。生成するクラスまたはインタフェースでそのメンバー名が見つかったときに使用される対応COM名を指定できます。この名前を空白のままにした場合、JavaメンバーはCOMインタフェースで生成される対応メンバーを持ちません。

クラス/インタフェース名ドロップダウン・リストから特定のCOMクラス名またはインタフェースを選択すると、そのクラスまたはインタフェースのメンバーのセットがその下に表示されます。使用するCOM名を指定し、「Add this Class Name map」をクリックすることによって、選択したクラス/インタフェースを指定したCOM名にマップします。「Add this Member Name map」をクリックすると、選択したメンバーを指定したCOM名にマップできます。

「Generate」ボタン

このボタンをクリックすると、ラッパーおよびIDLファイルが生成されます。
java2comが発見するパブリックJavaインタフェースごとに、対応するCOMインタフェース定義が作成されます。Javaインタフェース名がcom.bea.finance.Bankableの場合、生成されるCOMインタフェースの名前は、「Names」ダイアログで異なる名前を指定しない限り、ComBeaFinanceBankableとなります。

java2comが発見するパブリックJavaクラスごとに、対応するCOMインタフェース定義が作成されます。Javaクラス名がcom.bea.finance.Accountの場合、生成されるCOMインタフェースの名前は、「Names」ダイアログで異なる名前を指定しない限り、IComBeaFinanceAccountとなります。また、Javaクラスがパブリック・デフォルト・コンストラクタを持つ場合、java2comでは、「Names」ダイアログで異なる名前を指定しない限り、COMクラスComBeaFinanceAccountを生成します。

JavaクラスがJavaイベントを生成する場合、生成されるCOMクラスは、Javaクラスがサポートするイベントに対応したソース・インタフェース(COMイベント)を持ちます。

生成されたIDLファイルは、MicrosoftのMIDLツールを使用してコンパイルします。このツールはVisual C++に付属しており、Microsoft Webサイトからダウンロードできます。次のコマンド、

midl procdServ.idl

は、prodServ.tlbという型ライブラリを生成します。このライブラリは、「regtlb」に記載されているように登録する必要があります。

regjvm

WebLogic jCOMを使用してCOMをサポートする言語で、あたかもCOMオブジェクトであるかのようにJavaオブジェクトにアクセスできるようにするには、Javaオブジェクトが実行されるJVMの参照を(COMクライアント・マシン上に)登録する必要があります。regjvmツールを使用すると、マシン上ですべてのJVM参照を作成および管理できます。

注意:
regjvmツールでは、古いエントリと同名の新しいエントリが入力されても、古いエントリは上書きされません。したがって、通信するマシンのホスト名またはポートを変更する必要がある場合は、古いエントリの登録を解除して新しいエントリを登録します。そのためには、コマンド・ライン・ツールのregjvmcmd.exe、またはGUIツールのregjvm.exeを使用します(どちらもWL_HOME\server\binディレクトリに格納されています)。

JVMモード

COMクライアントからJVMには、以下のモードでアクセスできます。

- DCOMモード

- ネイティブ・モード(アウト・オブ・プロセス)

- ネイティブ・モード(イン・プロセス)

DCOMモード

DCOMモードでは、Javaサーバー・サイド上にネイティブ・コードは不要です。このため、JavaコードをJava仮想マシンがインストールされているUnixマシンや他のマシン上に配置できます。Windowsクライアント・マシン上でJVMを登録する場合、サーバーのホスト・マシン名(ローカル・コンポーネント用のローカル・ホストの場合もあります)とポート番号を定義します。

JVM内のJavaコードは、com.bea.jcom.Jvm.register(<jvm id>)を呼び出す必要があります。ここで<jvm id>は、regjvmで定義したJVMのIDです。

ネイティブ・モード(アウト・オブ・プロセス)

ネイティブ・モードは現在、ローカル・マシン上でのみ動作します。JVM名以外にパラメータは必要ありません。

JVMは、com.bea.jcom.Jvm.register(<jvm id>)を呼び出す必要があります。ここで<jvm id>は、regjvmで定義したJVMのIDです。

ネイティブ・モード(イン・プロセス)

イン・プロセスのネイティブ・モードを使用すると、JavaオブジェクトをCOMクライアントと同じプロセスに実際にロードできます。もちろん、どちらのオブジェクトも同じマシン上に配置する必要があります。

JVMは、com.bea.jcom.Jvm.register()を呼び出す必要はなく、クライアントの追加プロセスとして開始する必要もありません。

regjvm GUIツールのユーザー・インタフェース

regjvmツールを実行すると、以下のダイアログ・ボックスが表示されます。

- 上部は、現在のマシン上のすべてのJVMを選択および管理するための部分です。JVMは変更、追加、または削除できます。異なるJVMに切り替える場合は、現在選択されているJVMに対する変更を保存する必要があります。また、JVMモードを選択します。その際、必要な情報がダイアログの下部に表示されます。

- ダイアログの下部には、それぞれのJVMで必要な詳細が、JVMのモードに従って表示されます。JVMの詳細のほかに、各JVMモードの詳細オプションを表示するためのチェック・ボックスも存在します。
これらのオプションについては、以下の節で説明します。

regjvm GUIツールのDCOMモード・オプション

標準オプション

- 「JVM id」(必須) - JVMを指定する必要があります。「Browse」ボタンをクリックすると、独自のJVMを選択できます。「Scan」ボタンをクリックすると、ローカル・マシンからJVMを探して(数分かかる場合があります)、それを選択用のリストボックスに挿入します。

- 「Hostname」 - JVMが存在するホスト名またはIPアドレスです。

- 「Port」 - JVMとの通信を開始するためのポート番号です。

詳細オプション

- 「Launch Command」(必須) - JVMが自動的に起動する場合に使用されるコマンドです。通常、このコマンドは次のようになります。

c:\Oracle\Middleware\jdk160\bin\java -classpath c:\Oracle\Middleware\wlserver_10.3\server\lib\weblogic.jar;c:\pure MyMainClass

weblogic.jarおよび該当するjdkファイルがCLASSPATHにあることが重要です。

- 「Generate Script」(オプション) - JVMの設定を選択するレジストリ・スクリプトを生成できます。

regjvm GUIツールのネイティブ・モード・オプション

標準オプション

- 「JVM id」(必須) - JVMを指定する必要があります。「Browse」ボタンをクリックすると、独自のJVMを選択できます。「Scan」ボタンをクリックすると、ローカル・マシンからJVMを探して(数分かかる場合があります)、それを選択用のリストボックスに挿入します。

詳細オプション

詳細オプションは、DCOMモードの詳細オプションと同じです。「regjvm GUIツールのDCOMモード・オプション」を参照してください。

regjvm GUIツールのネイティブ・モード・イン・プロセス・オプション

標準オプション

- 「JVM id」(必須) - JVMを指定する必要があります。「Browse」ボタンをクリックすると、独自のJVMを選択できます。「Scan」ボタンをクリックすると、ローカル・マシンからJVMを探して(数分かかる場合があります)、それを選択用のリストボックスに挿入します。

詳細オプション

- 「Classpath」(オプション) - JVMのCLASSPATHです。空白のままにすると、実行時のCLASSPATH環境変数が使用されます。空白以外の場合、内容がCLASSPATH環境変数に追加されます。

- 「Main Class」(オプション) - 呼び出すMainメソッドを含むクラスの名前です。

- 「Properties」(オプション) - 設定する必要があるプロパティです。次の構文が必要です。prop1=value1 prop2=value2...

- 「Java 2」(オプション) - プロパティを設定する場合、Java 2 (JDK 1.2.x、1.3.x)を使用するときはオンにし、1.1.xを使用するときはオフにする必要があります。

- 「Generate Script」(オプション) - DCOMモードの場合と同じです。「regjvm GUIツールのDCOMモード・オプション」を参照してください。

regjvmcmd

regjvmcmdは、regjvmで説明したGUIツール、regjvmのコマンド・ライン・バージョンです。このパラメータの一覧を参照するには、パラメータを指定せずに次のように実行します。

regjvmcmd

最も単純な形式のregjvmcmdでは、以下のものを指定します。

- jvm ID (com.bea.jcom.Jvm.register("JvmId"))で使用する名前に対応。

- バインディングはhostname[port]の形式でJVMにアクセスできます(ここで、hostnameはJVMを実行するマシンの名前、portはWebLogic Serverの起動時に指定するTCP/IPポートです)。

JVMを登録する必要がないか、またはその登録を変更する場合、最初に次のコマンドを使用してその登録を解除しておく必要があります。

regjvmcmd /unregister JvmId

regtlb

WebLogic jCOMのregtlbツールは、COMのアーリー・バインディング・メカニズムを使用してJavaオブジェクトにアクセスする必要のあるCOM Windowsクライアントに型ライブラリを登録します。regtlbは、2つのパラメータを取ります。最初のパラメータは、登録する型ライブラリ・ファイルの名前です。2番目は、型ライブラリに記述されているCOMクラスが存在するJVMのIDです。

WebLogic jCOM java2comツールで生成されたIDLファイルから型ライブラリが生成された場合、regtlbコマンドは、型ライブラリ内の各COMクラスに対応するJavaクラス名を自動的に調べます。型ライブラリのCOMクラス記述の形式は次のとおりです。

Java class java.util.Observable (through jCOM))

java2comで生成されたIDLファイルから型ライブラリが生成されなかった場合、各COMクラスに対してインスタンス化するJavaクラスの名前を指定する必要があります。

このため、ユーザーがAtldll.Appleのインスタンスを作成しようとした場合、WebLogic jCOMによってJVM MyJvm内のクラスがインスタンス化されます。MyAppleClassクラスは、COMクラスAtldll.Appleによって実装されるatldll.tlbからWebLogic jCOMのjava2comツールで生成されたJavaインタフェースを実装します。

Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved.