WebLogic ServerのRMI-IIOP用構成

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

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>

説明:

hostnameは、ユーザーのプロキシ・サーバーのネットワーク・アドレス。
portはポート番号。明示的に設定しない場合、ポート番号の値は80に設定されます。

hostnameとportには次のような識別名を使用できます。

-Diiops.proxyHost=https.proxyHost
-Diiops.proxyPort=https.proxyPort

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

この機能によってWebLogic Serverの動作が変わることはありません。ただし、この機能を使用すると、クライアントのファイアウォールがあってもIPアドレスが公開されます。接続の両端には信頼性があり、送信される情報は暗号化されるので、ほとんどの環境で許容できるレベルのセキュリティです。
本番環境によっては、プロキシ・サーバーのCONNECT属性を有効にできない場合もあります。そのような環境ではHTTPSトンネリングを使用してください。『Oracle WebLogic Serverサーバー環境の管理』のHTTPトンネリングのためのWebLogic Serverの設定に関する項を参照してください。

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呼出しを委任するには、いくつかのオブジェクトが連携してそれを実行する必要があります。それらのオブジェクトを作成する主なステップを以下に示します。

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

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

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

「図9-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を使用してリモート・ドメインからのインバウンド呼出しを認証します。

IDアサーション・プロバイダを更新します。Oracle WebLogic Serverセキュリティの管理のIDアサーション・プロバイダの構成を参照してください。
ユーザー名マッパーを更新します。Oracle WebLogic Serverセキュリティの管理のユーザー名マッパーの構成を参照してください。
アプリケーションで必要なリモート・ドメイン内のすべてのユーザーをWebLogic認証プロバイダに追加します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーの作成を参照してください。

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

ノート:

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

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

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

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

true—エンド・ポイントの再ネゴシエーションを強制します。
false—デフォルト値。

ハードウェア・ロード・バランサを必要とする環境では、このプロパティを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に関して問題がある場合は、以下のいずれかの方法を実装する必要があります。

IIOPを通じてWebLogic Serverに接続するすべてのクライアントのIDは、デフォルトで<anonymous>になります。以下の例に示すように、config.xmlファイルにユーザー名とパスワードを設定することで、IIOPを通じてWebLogic Serverの個々のインスタンスに接続するすべてのクライアント用に単一のIDをセット・アップできます。
```
<Server
Name="myserver"
NativeIOEnabled="true"
DefaultIIOPUser="Bob"
DefaultIIOPPassword="Gumby1234"
ListenPort="7001">
```
また、config.xmlにはIIOPEnabled属性を設定することもできます。この属性のデフォルト値は"true"ですが、IIOPのサポートを無効にする場合のみ、"false"に設定します。すべてのリモート・オブジェクトがJNDIツリーにバインドされてクライアントからアクセスできるようにしているのであれば、RMI over IIOPを使用するために追加のサーバーを構成する必要はありません。RMIオブジェクトは通常、起動クラスによってJNDIツリーにバインドされます。EJBホームは、デプロイメント時にJNDIツリーにバインドされます。WebLogic Serverは、JNDIツリーのルックアップ呼出しをすべて委任することにより、CosNaming Serviceを実装します。
このリリースでは、corbanameおよびcorbalocの各RMI-IIOP JNDI参照をサポートしています。http://www.omg.org/cgi-bin/doc?formal/01-02-33を参照してください。これらの参照の特徴の1つは、あるWebLogic ServerをホストとするEJBなどのオブジェクトをIIOPを介して他のアプリケーション・サーバーから利用可能にできるということです。そのため、たとえばejb-jar.xmlに以下の内容を追加することもできます。
```
<ejb-reference-description>
<ejb-ref-name>WLS</ejb-ref-name>
<jndi-name>corbaname:iiop:1.2@localhost:7001#ejb/javaee/interop/foo</jndi-name>
</ejb-reference-description>
```

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++クライアントを使用することによって回避することもできます。