ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 8.1 ドキュメント > WebLogic RMI over IIOP プログラマーズ ガイド > WebLogic Server の RMI-IIOP 用コンフィグレーション

WebLogic RMI over IIOP プログラマーズ ガイド

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

WebLogic Server の RMI-IIOP 用コンフィグレーション

以下の各節では、WebLogic Server の RMI-IIOP 用コンフィグレーションに関する概念と手続きについて説明します。

 

リスン アドレスの設定

IIOP を使用するには、接続をリスンするように、コンフィグレーション ファイル (config.xml) のリスン アドレス属性に対して有効な IP アドレスまたは DNS 名を指定しておきます。

リスン アドレスがデフォルト値の null である場合は、コンフィグレーションされたネットワーク インタフェースのすべてをリスンできます。ただし、これは T3 プロトコルでのみ機能します。IIOP プロトコルで使用する複数のリスン アドレスをコンフィグレーションする必要がある場合は、ネットワーク チャネル機能を使用します。詳細については、『WebLogic Server のコンフィグレーションと管理』の「ネットワーク リソースのコンフィグレーション」を参照してください。

 

ネットワーク チャネル アドレスの設定

以下の節では、シン クライアント用に IIOP ネットワーク チャネルのアドレスを実装する場合に、考慮すべき事項を説明します。

プロキシおよびファイアウォールに関する考慮事項

典型的な環境ではファイアウォール、プロキシ、または他のデバイスを使用することが多く、その場合アプリケーション サーバの真の IP アドレスは隠蔽されます。IIOP は、ホストおよびポートを各オブジェクトに含むオブジェクトごとのアドレッシング方式に依存しているため、サーバの真の IP アドレスがマスクされると、外部クライアントとの接続を維持できなくなります。サーバの IIOP ネットワーク チャネルの PublicAddress に仮想 IP を設定し、クライアントがその仮想 IP を識別するようにすると、このような状況を回避できます。

複数の接続を持つクライアントに関する考慮事項

IIOP のクライアントは、アプリケーション サーバで使用されるアドレッシング情報をパブリッシュして接続を確立します。VPN の実行時でクライアントが複数の接続を持つ場合などには、クライアントからパブリッシュされた IP アドレスをサーバで識別できないことがあります。次の 2 つのうちどちらかの方法によって、こうした状況を回避できます。

 

RMI-IIOP と SSL および Java クライアントの併用

SSL をサポートする Java クライアントは、シン クライアントと WLS-IIOP クライアントです。これらのクライアントでは、SSL URL を指定するだけで SSL を使用できます。

 

IIOPS シン クライアント プロキシの使用

IIOPs シン クライアント プロキシを使用すると、WebLogic シン クライアントは発信リクエストをサーバにプロキシできます。その場合、各ユーザはすべての発信リクエストをプロキシ経由でルーティングします。ユーザのプロキシはそのリクエストを WebLogic Server に転送します。ネットワーク チャネルの実装が適当でない場合は、この方法を使用してください。プロキシを有効にするには、以下のプロパティを設定します。 

-Diiops.proxyHost=<host>
-Diiops.proxyPort=<port>

各要素の説明は次のとおりです。

以下のようなセキュリティの影響を考慮してください。

 

委託を通じた CORBA クライアントから WebLogic Server オブジェクトへのアクセス

WebLogic Server には、CORBA クライアントから RMI リモート オブジェクトにアクセスできるようにするサービスが用意されています。また、それ以外の方法として、WebLogic Server に CORBA ORB (Object Request Broker) をホストし、発着信メッセージをその ORB に委託することで、サーバ内でバインド可能なあらゆるオブジェクトを CORBA クライアントから間接的に呼び出せるようにすることもできます。

委託の概要

WebLogic Server をホストとするオブジェクトに CORBA 呼び出しを委託するには、いくつかのオブジェクトが連携してそれを実行する必要があります。それらのオブジェクトを作成する主な手順を以下に示します。

  1. WebLogic Server を実行している JVM と共存するように ORB を作成し初期化する起動クラスを作成します。
  2. その ORB から着信するメッセージを受け付けるオブジェクトを作成するための IDL (インタフェース定義言語) を作成します。
  3. その IDL をコンパイルします。これによって多数のクラスが生成されますが、そのうちの 1 つが Tie クラスです。 Tie クラスは、着信呼び出しを処理するためにサーバサイドで用いられ、それらの呼び出しをしかるべき実装クラスにディスパッチします。その実装クラスは、CORBA クライアントに代わって、サーバの接続、適切なオブジェクトのルックアップ、およびそのオブジェクトに対するメソッドの呼び出しを行います。

図 3-1 には、サーバに接続して EJB 上で動作する実装クラスに、EJB の呼び出しを委託する CORBA クライアントを示します。同様のアーキテクチャを使用すると、これとは逆の状況でも機能します。起動クラスを使用すると、ORB を起動し、対象となる CORBA 実装オブジェクトへの参照を取得できます。このクラスは、JNDI ツリー内の別の WebLogic オブジェクトで使用できるようにして、CORBA オブジェクトへの適切な呼び出しを委託することも可能です。

図 3-1 委託された呼び出しで EJB を呼び出す CORBA クライアント

委託された呼び出しで EJB を呼び出す CORBA クライアント


 

委託の例

以下のサンプル コードでは、サーバへの接続、JNDI ツリー内の Foo オブジェクトのルックアップ、および bar メソッドの呼び出しを行う実装クラスを作成しています。このオブジェクトはまた、以下の処理による CORBA 環境の初期化を行う起動クラスでもあります。 

import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
import java.rmi.*;
import javax.naming.*;
import weblogic.jndi.Environment;
public class FooImpl implements Foo
{ 
  public FooImpl() throws RemoteException {
    super();
  }
  public void bar() throws RemoteException, NamingException {
    // 呼び出しの委託先となるインスタンスをルックアップして呼び出す
    weblogic.jndi.Environment env = new Environment();
    Context ctx = env.getInitialContext();
    Foo delegate = (Foo)ctx.lookup("Foo");
    delegate.bar();
    System.out.println("delegate Foo.bar called!");
  }
  public static void main(String args[]) {
    try {
      FooImpl foo = new FooImpl();
      // ORB を作成し初期化する
      ORB orb = ORB.init(args, null);
      // Tie オブジェクトを作成し、ORB に登録する
      _FooImpl_Tie fooTie = new _FooImpl_Tie();
      fooTie.setTarget(foo);
      orb.connect(fooTie);
      // ネーミング コンテキストを取得する
      org.omg.CORBA.Object o = \
      orb.resolve_initial_references("NameService");
      NamingContext ncRef = NamingContextHelper.narrow(o);
      // オブジェクト参照をネーミング サービスにバインドする
      NameComponent nc = new NameComponent("Foo", "");
      NameComponent path[] = {nc};
      ncRef.rebind(path, fooTie);
      System.out.println("FooImpl created and bound in the ORB       registry.");
    }
    catch (Exception e) {
      System.out.println("FooImpl.main: an exception occurred:");
      e.printStackTrace();
    }
  }
}

起動クラスの実装方法の詳細については、「サーバの起動と停止」を参照してください。

 

ハードウェア ロード バランサと RMI over IIOP の併用

注意 : この機能は、ハードウェア ロード バランサを使用してブートストラップを行っている場合にのみ正常に動作します。

SP3 以降の WebLogic Server 8.1 BEA ORB を拡張すると、ブートストラップ時の再接続の強制によるハードウェア ロード バランシングをサポートできます。これにより、ハードウェア ロード バランサによる接続試行のバランシングが可能になります。

ほとんどの場合、いったん接続が確立されると、元の接続を使用して次の NameService ルックアップが実行されます。しかし、この機能はハードウェア ロード バランサにエンド ポイントの再ネゴシエーションを強制するため、既存の接続で処理中のリクエストはすべて破棄されます。

-Dweblogic.system.iiop.reconnectOnBootstrap システム プロパティを使用すると、BEA ORB の接続動作を設定できます。 有効な値は、次のとおりです。

ハードウェア ロード バランサを必要とする環境では、このプロパティを true に設定する必要があります。

 

WebLogic RMI-IIOP の制約事項

以下の各節では、WebLogic RMI-IIOP に関するさまざまな問題点の概要を説明します。

クライアントで RMI-IIOP を使用する際の制約

WebLogic Server と一緒に使用する JDK は、バージョン 1.3.1_01 またはそれ以降でなければなりません。それ以前のバージョンは RMI-IIOP に準拠していません。 これら旧バージョンの JDK には以下の問題点があることに注意してください。

これらの多くは、両方でサポートすることが不可能なものです。選択肢がいくつかある場合には、WebLogic では仕様に準拠する方をサポートしています。

Java IDL クライアントの開発上の制約

RMI-IIOP を使用する予定であれば、RMI クライアント モデルを用いて Java クライアントを開発することを強くお勧めします。Java IDL クライアントを開発する場合には、名前の衝突やクラスパスの問題が発生するおそれがあり、サーバサイドとクライアントサイドのクラスを分離しておく必要があります。RMI オブジェクトと IDL クライアントのタイプ システムはそれぞれ異なるので、サーバサイドのインタフェースを定義するクラスは、クライアントサイドのインタフェースを定義するクラスとは非常に異なるものになります。

オブジェクトの値渡しに関する制約

オブジェクトを値で渡すには、値タイプを使用する必要があります (詳細については、「CORBA/IIOP 2.4.2 仕様」の第 5 章を参照してください)。値タイプは、それが定義または参照されるプラットフォームごとに実装されます。この節では、WebLogic Server 上のエンティティ Bean にアクセスする C++ クライアントのケースを具体的に取り上げながら、複合的な値タイプを渡す際の問題点について説明します。

Java プログラマが直面する問題の 1 つは、常に可視とは限らない派生データ型の使用に関することです。たとえば、EJB ファインダにアクセスする際に、Java プログラマは Collection や Enumeration を目にすることになりますが、その基礎となる実装には注意を払いません。これは、JDK ランタイムがネットワークを通じてこれらのクラスをロードするためです。しかし、C++ や CORBA のプログラマであれば、ネットワークを通じて送られてくるデータ型を把握している必要があります。そうすれば、それに応じた値タイプ ファクトリを登録でき、また ORB でそのデータ型をアンマーシャリングできるようになります。

定義された EJB インタフェースで ejbc を実行するだけでは、これらの定義は生成されません。インタフェースにそれらが現れないからです。このため、ejbc には、リモート インタフェース以外の Java クラスも指定できるようになっています (これは特に、それらのインタフェースの IDL を生成するのが目的です)。なお、値タイプ ファクトリを登録する方法については、/iiop/ejb/entity/cppclient サンプルを参照してください。

シリアライズ可能でありながら writeObject() を定義する Java 型は、IDL で記述されるカスタム値タイプにマップされます。値タイプを手動でアンマーシャリングする C++ コードを書く必要があります。その方法の例としては、SAMPLES_HOME/server/src/examples/iiop/ejb/entity/tuxclient/ArrayList_i.cpp を参照してください。

注意 : Tuxedo を使用する場合には、IDL コンパイラに -i 修飾子を指定することで、FileName_i.h および FileName_i.cpp という実装ファイルを作成させることができます。たとえば、次の構文の場合、TradeResult_i.h および TradeResult_i.cpp という実装ファイルが作成されます。

  idl -IidlSources -i   idlSources\examples\iiop\ejb\iiop\TradeResult.idl

結果として生成されるソース ファイルには、値タイプに対するアプリケーション定義の操作が実装されています。実装ファイルは、CORBA クライアント アプリケーションに組み込まれます。

 

クライアント ID の伝播

最近まで、CORBA クライアントからのクライアント ID の伝播に関する標準が十分ではありませんでした。外部 ORB のクライアント ID に関して問題がある場合は、以下のいずれかの方法を実装する必要があります。

これらの方法は、RMI クライアントで WLInitialContextFactory を使用する場合は必要ありません。また、sectuxclient サンプル (SAMPLES_HOME/server/examples/src/examples/iiop/ejb/stateless/sectuxclient に格納) で例示されているように WebLogic C++ クライアントを使用して回避することもできます。

 

RMI-IIOP サンプル コード パッケージ

examples.iiop パッケージは、SAMPLES_HOME/server/examples/src/examples/iiop ディレクトリにあり、その中には、さまざまなクライアントとアプリケーションとの接続性について説明するサンプルが用意されています。詳細については、サンプルの説明を参照してください。特に WebLogic Tuxedo Connector に関するサンプルについては、SAMPLES_HOME/server/examples/src/examples/wtc ディレクトリを参照してください。

 

その他の情報源

WebLogic RMI-IIOP は、RMI の完全な実装を意図したものです。ご使用のバージョンに該当するその他の考慮事項については、『リリース ノート』を参照してください。

 

フッタのナビゲーションのスキップ  ページの先頭 前 次