|
|
|
|
|
|
| | | |
アプリケーションのデプロイ
以下の節では、アプリケーションの実行前に行っておく必要がある手順について説明します。
デプロイメント オプション
WebLogic jCOM を使用して COM クライアントから Java オブジェクトにアクセスする場合、使用する実装に応じて以下の 5 つの異なるデプロイメント シナリオが存在します。
また、デプロイメントは、次の中で複数の WebLogic Server を使用することによって影響を受ける場合があります。
使用する実装に適したインストールを選択した場合、コンフィグレーション、デプロイメント、および実行時に必要なすべての WebLogic jCOM ファイルは既に適切な場所に格納されています。ユーザが作成したファイルは、適切な場所に手動でコピーする必要があります。
WebLogic jCOM を使用して Java クライアントから COM オブジェクトにアクセスするときのデプロイメントの詳細については、『WebLogic jCOM リファレンス』を参照してください。
アプリケーションのデプロイ
DCOM ゼロ クライアント実装のデプロイ
DCOM ゼロ クライアント実装では、クライアント システム上での実装は必要ありません。ただし、クライアントから WebLogic jCOM ブリッジには、サーバの場所（IP とポート）のハードコード化された参照を介してアクセスすることに注意してください。この参照は、クライアント ソース コードに存在します。サーバの場所が変更された場合、COM クライアントがこのサーバと通信するためには、この objref を再登録してクライアントのソース コードに挿入する必要があります。
サーバ インストール プロセス（通常 server install）は、必要な WebLogic jCOM コンポーネントを実行時にサーバにインストールします。
jcom.jar
EJB が WebLogic Server にデプロイされ、サーバがアクティブ化されたら、コンパイルされたブリッジをアクティブ化できます。サーバの TCP/IP アドレスとリスン ポートに対する変更は、必ずブリッジファイル自体に反映されなければなりません。
objref を生成し、ブリッジをアクティブ化する方法については、「プログラミング」の章のゼロ クライアント インストールの例を参照してください。
DCOM レイト バインド実装のデプロイ
DCOM レイト バインド実装の場合、クライアント インストール プロセス（通常 クライアント インストール）が必要なコンポーネントを実行時にサーバにインストールします。
JintMk.dll
クライアントのコンフィグレーションに必要なものの他に、次のものが必要です。
regjvm
アプリケーションの実行前に、regjvm または regjvmcmd を使用して JVM を登録しておく必要があります。regjvm と regjvmcmd の詳細については、「WebLogic jCOM ツール」を参照してください。
注意: サーバの場所を変更した場合、JVM を再登録する必要があります。これを行う前に、古いエントリの登録を解除する必要があります。regjvmcmd ツールは古いエントリを同名の新しいエントリで上書きしないからです。古いエントリの登録を解除するには、コマンド ライン ツールの regjvmcmd を使用するか、または GUI ツール regjvm（どちらも jCOM\bin ディレクトリに存在する）を使用します。
サーバ インストール プロセス（通常 server install）は、必要な WebLogic jCOM ブリッジ ファイルを実行時にサーバにインストールします。
jcom.jar
EJB が WebLogic Server にデプロイされ、サーバがアクティブ化されたら、コンパイルされたブリッジをアクティブ化できます。サーバの TCP/IP アドレスとリスン ポートに対する変更は、必ずブリッジファイル自体に反映されなければなりません。
JVM を登録してブリッジをアクティブ化する方法については、「プログラミング」の章のレイト バインド実装の例を参照してください。
DCOM アーリー バインド実装のデプロイ
DCOM アーリー バインド実装の場合、クライアント インストール プロセス（通常 client install）が必要な jCOM ツールを実行時にサーバにインストールします。
JintMk.dll
クライアントのコンフィグレーションに必要なものの他に、次のものが必要です。
java2com ツールによって生成された型ライブラリが実行時にクライアント システムに存在し、CLASSPATH 環境変数がその型ライブラリの格納先のディレクトリを指していることを確認する必要があります。型ライブラリは、WebLogic jCOM ブリッジから取得したリモート オブジェクトのアーリー バインディングで必要です。型ライブラリをクライアントに登録するには、regtlb ツールを使用します。java2com および regtlb ツールの詳細については、「WebLogic jCOM ツール」を参照してください。
アプリケーションの実行前に、regjvm または regjvmcmd を使用して JVM を登録しておく必要があります。regjvm と regjvmcmd の詳細については、「WebLogic jCOM ツール」を参照してください。
注意: サーバの場所を変更した場合、JVM を再登録する必要があります。これを行う前に、古いエントリの登録を解除する必要があります。regjvmcmd ツールは古いエントリを同名の新しいエントリで上書きしないからです。古いエントリの登録を解除するには、コマンド ライン ツールの regjvmcmd を使用するか、または GUI ツール regjvm（どちらも jCOM\bin ディレクトリに存在する）を使用します。
サーバ インストール プロセス（通常 server install）は、必要な WebLogic jCOM ブリッジ ファイルを実行時にサーバにインストールします。
jcom.jar
java2com ツールによって生成されたラッパー クラスが実行時にサーバ システムに存在し、CLASSPATH 環境変数がそれらの格納先ディレクトリを指していることを確認する必要があります。ラッパー クラスは、カプセル化するために作成した Java オブジェクトとアーリー バインド通信を可能にします。
EJB が WebLogic Server にデプロイされ、サーバがアクティブ化されたら、コンパイルされたブリッジをアクティブ化できます。サーバの TCP/IP アドレスとリスン ポートに対する変更は、必ずブリッジファイル自体に反映されなければなりません。
型ライブラリと JVM の登録、およびブリッジのアクティブ化についての詳細は、「プログラミング」の章のアーリー バインド実装の例を参照してください。
DCOM レイト バインドカプセル化実装のデプロイ
レイト バインド カプセル化は開発時にはアーリー バインディングを、実行時にはレイト バインディングを使用するので、レイト バインドカプセル化実装のデプロイはレイト バインド実装のデプロイとほぼ同じです。レイト バインディングが実行時に実装されるようにするには、開発時に参照される型ライブラリにクライアントからアクセスできないようにする必要があります。これにより、サーバ サイドのラッパーにもアクセスできなくなります。
DCOM レイト バインド実装の場合、クライアント インストール プロセス（通常 client install）が必要な WebLogic jCOM ツールを実行時にサーバにインストールします。
JintMk.dll
クライアントのコンフィグレーションに必要なものの他に、次のものが必要です。
regjvm
開発時に参照される型ライブラリが実行時にクライアントから見えないようにする必要があります。そのようにしない限り、実装はアーリー バインドのままです。
アプリケーションの実行前に、regjvm または regjvmcmd を使用して JVM を登録しておく必要があります。regjvm と regjvmcmd の詳細については、「WebLogic jCOM ツール」を参照してください。
注意: サーバの場所を変更した場合、JVM を再登録する必要があります。これを行う前に、古いエントリの登録を解除する必要があります。regjvmcmd ツールは古いエントリを同名の新しいエントリで上書きしないからです。古いエントリの登録を解除するには、コマンド ライン ツールの regjvmcmd を使用するか、または GUI ツール regjvm（どちらも jCOM\bin ディレクトリに存在する）を使用します。
サーバ インストール プロセス（通常 server install）は、必要な WebLogic jCOM ブリッジ ファイルを実行時にサーバにインストールします。
jcom.jar
EJB が WebLogic Server にデプロイされ、サーバがアクティブ化されたら、コンパイルされたブリッジをアクティブ化できます。サーバの TCP/IP アドレスとリスン ポートに対する変更は、必ずブリッジファイル自体に反映されなければなりません。
ネイティブ モード実装のデプロイ
ネイティブ モードでは、COM クライアントはクライアントと同じマシン上で動作している Java オブジェクトにアクセスします。WebLogic jCOM は、ネイティブ コードを使用してこの対話を容易にします。ネイティブ モードの詳細については、『WebLogic jCOM リファレンス』の「ネイティブ モード」を参照してください。
サーバのクラスタ化
サーバ クラスタ内で複数の WLS マシンを使用する場合、デプロイメント方法に影響が及ぶ場合があります。フェイルオーバー機能を保持するには、すべての WebLogic jCOM ファイルをクライアント システムにデプロイすること（上記のネイティブ モード デプロイメントとほぼ同じ）をお勧めします。クラスタ内の 1 台のマシンだけに WebLogic jCOM ブリッジを配置した場合、システムは障害の影響を受けやすくなります。ブリッジ マシンに障害が発生した場合、すべての WebLogic jCOM 機能を失うことになります。WebLogic jCOM ブリッジをクライアント システムに配置するとこの危険を回避され、クラスタはフェイルオーバ機能を通常どおり使用できます。WebLogic jCOM の将来のリリースは、WebLogic Server と緊密に統合される予定です。これにより、クラスタ化フェイルオーバ機能を自動的に保持できるようになります。
|
|
|