ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server RMIのプログラミング
11gリリース1 (10.3.6)
B61626-04
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

8 WebLogic ServerのRMI-IIOP用構成

この章では、RMI over IIOP (RMI-IIOP)を使用して相互運用するようWebLogic Serverを構成するために必要な概念と手順について説明します。

リスニング・アドレスの設定

IIOPを容易に使用できるようにするには、構成ファイル(config.xml)のリスニング・アドレス属性に常に有効なIPアドレスまたはDNS名を指定して、接続をリスニングできるようにしておきます。

リスニング・アドレスがデフォルト値のnullである場合は、構成されたネットワーク・インタフェースのすべてをリスニングできます。ただし、この機能を使用できるのはT3プロトコルのみです。IIOPプロトコルで使用する複数のリスニング・アドレスを構成する必要がある場合は、ネットワーク・チャネル機能を使用します(『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください)。

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

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

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

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

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

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

  • 双方向IIOPを使用します。次のWebLogicのフラグを使用します。

    -Dweblogic.corba.client.bidir=true

    この場合、サーバーは受信した接続を使用してリクエストを送信するので、クライアントからパブリッシュされたIPアドレスを必要としません。

  • 次のJDKのプロパティを使用して、サーバーが送信用の接続に使用するアドレスを設定します。

    -Dcom.sun.CORBA.ORBServerHost=client_ipaddress

    ここでclient_ipaddressは、クライアントからパブリッシュされたアドレスを示します。

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

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

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

説明:

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

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

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

委任を通じた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クライアントにかわって、サーバーの接続、適切なオブジェクトのルックアップ、およびそのオブジェクトに対するメソッドの呼出しを行います。

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

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

図8-1の説明が続きます
「図8-1 委任された呼出しでEJBを呼び出すCORBAクライアントの説明」

委任の例

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

  • ORBの作成

  • Tieオブジェクトの作成

  • 実装クラスとTieオブジェクトの関連付け

  • ORBへのTieオブジェクトの登録

  • ORBのネーミング・サービス内へのTieオブジェクトのバインド

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 {
    // look up and call the instance to delegate the call to...
    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();

      // Create and initialize the ORB
      ORB orb = ORB.init(args, null);

      // Create and register the tie with the ORB
      _FooImpl_Tie fooTie = new _FooImpl_Tie();
      fooTie.setTarget(foo);
      orb.connect(fooTie);

      // Get the naming context
      org.omg.CORBA.Object o = \
      orb.resolve_initial_references("NameService");
      NamingContext ncRef = NamingContextHelper.narrow(o);

      // Bind the object reference in naming

      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();
    }
  }
}

CSIv2認証の構成

Common Secure Interoperability仕様バージョン2(CSIv2)は、相互運用可能な認証、委任および権限のためのCommon Object Request Broker Architecture (CORBA)セキュリティの要件に応えるOpen Management Group (OMG)仕様です。『Oracle WebLogic Serverのセキュリティの理解』のCommon Secure Interoperability Version 2(CSIv2)に関する項を参照してください。

次の手順に従って、CSIv2を使用してリモート・ドメインからの着信呼出しを認証します。

  1. IDアサーション・プロバイダを更新します。『Oracle WebLogic Serverの保護』のIDアサーション・プロバイダの構成に関する項を参照してください。

  2. ユーザー名マッパーを更新します。『Oracle WebLogic Serverの保護』のユーザー名マッパーの構成に関する項を参照してください。

  3. アプリケーションで必要なリモート・ドメイン内のすべてのユーザーをWebLogic認証プロバイダに追加します。Oracle WebLogic Server管理コンソール・ヘルプのユーザーの作成に関する項を参照してください。

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


注意:

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

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

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

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

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

WebLogic RMI-IIOPの制約事項

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

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

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

  • GIOP 1.0メッセージとGIOP 1.1プロファイルをIORで送信します。

  • EJB 2.0相互運用性を実現するのに必要なコンポーネント(GIOP 1.2、コード・セット・ネゴシエーション、UTF-16)をサポートしていません。

  • マングルされたメソッド名の取扱いにバグがあります。

  • 未検査の例外が正しくアンマーシャリングされません。

  • 値タイプのエンコーディングに関してわずかなバグがあります。

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

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

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

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

オブジェクトを値で渡すには、値タイプを使用する必要があります(http://www.omg.org/cgi-bin/doc?formal/01-02-33を参照)、値タイプは、それが定義または参照されるプラットフォームごとに実装します。この節では、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++コードを書く必要があります。


注意:

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に関して問題がある場合は、以下のいずれかの方法を実装する必要があります。

reference-descriptionスタンザは、ejb-jar.xmlに定義されているリソース参照をWebLogic Server内に用意されている実際のリソースのJNDI名にマップするものです。ejb-ref-nameではリソース参照名を指定します。これは、EJBプロバイダによってejb-jar.xmlデプロイメント記述子ファイル内に記載される参照です。jndi-nameでは、WebLogic Serverに用意されている実際のリソース・ファクトリのJNDI名を指定します。


注意:

iiop:1.2は、<jndi-name>セクションに含まれています。このリリースには、GIOP (General-Inter-Orb-Protocol) 1.2の実装が用意されています。GIOPは、相互運用するORB間で交換されるメッセージのフォーマットを規定するものです。これによって、他の多数のORBやアプリケーション・サーバーとの相互運用が可能になります。GIOPのバージョンは、corbanameまたはcorbaloc参照内のバージョン番号で指定できます。

これらの方法は、RMIクライアントでWLInitialContextFactoryを使用する場合には必要ありません。また、WebLogic C++クライアントを使用することによって回避することもできます。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次