|
|
以下の各節では、WebLogic Server の RMI-IIOP 用コンフィグレーションに関する概念と手続きについて説明します。
IIOP を容易に使用できるようにするには、コンフィグレーション ファイル (config.xml) のリスン アドレス属性に常に有効な IP アドレスまたは DNS 名を指定して、接続をリスンできるようにしておきます。
リスン アドレスがデフォルト値の null である場合、コンフィグレーションされたネットワーク インタフェースのすべてをリスンできます。ただし、この機能を使用できるのは T3 プロトコルのみです。IIOP プロトコルで使用する複数のリスン アドレスをコンフィグレーションする必要がある場合は、ネットワーク チャネル機能を使用します。「ネットワーク リソースのコンフィグレーション」を参照してください。
以下の節では、シン クライアント用に IIOP ネットワーク チャネルのアドレスを実装する場合に、考慮すべき事項を説明します。
一般的な環境ではファイアウォール、プロキシ、または他のデバイスを使用することが多く、その場合アプリケーション サーバの真の IP アドレスは隠蔽されます。IIOP は、ホストおよびポートを各オブジェクトに含むオブジェクトごとのアドレッシング方式に依存しているため、サーバの真の IP アドレスがマスクされると、外部クライアントとの接続を維持できなくなります。サーバの IIOP ネットワーク チャネルの PublicAddress に仮想 IP を設定し、クライアントがその仮想 IP を識別するようにすると、このような状況を回避できます。
IIOP のクライアントは、アプリケーション サーバで使用されるアドレッシング情報をパブリッシュして接続を確立します。VPN の実行時でクライアントが複数の接続を持つ場合などには、クライアントからパブリッシュされた IP アドレスをサーバで識別できないことがあります。次の 2 つのうちどちらかの方法によって、こうした状況を回避できます。
IIOPS シン クライアント プロキシを使用すると、WebLogic シン クライアントは発信リクエストをサーバにプロキシできます。その場合、各ユーザはすべての発信リクエストをプロキシ経由でルーティングします。ユーザのプロキシはそのリクエストを WebLogic Server に転送します。ネットワーク チャネルの実装が適当でない場合は、この方法を使用してください。プロキシを有効にするには、以下のプロパティを設定します。
-Diiops.proxyHost=<host>
-Diiops.proxyPort=<port>
CONNECT 属性を有効にできない場合もある。そのような環境では HTTPS トンネリングを使用してください。詳細については、『WebLogic Server 環境のコンフィグレーション』の「HTTP トンネリングのための WebLogic Server の設定」を参照してください。
SSL をサポートする Java クライアントは、シン クライアントと WLS-IIOP クライアントです。これらのクライアントでは、SSL URL を指定するだけで SSL を使用できます。
WebLogic Server には、CORBA クライアントから RMI リモート オブジェクトにアクセスできるようにするサービスが用意されています。また、それ以外の方法として、WebLogic Server に CORBA ORB (Object Request Broker) をホストし、発着信メッセージをその ORB に委託することで、サーバ内でバインド可能なあらゆるオブジェクトを CORBA クライアントから間接的に呼び出せるようにすることもできます。
WebLogic Server をホストとするオブジェクトに CORBA 呼び出しを委託するには、いくつかのオブジェクトが連携してそれを実行する必要があります。それらのオブジェクトを作成する主な手順を以下に示します。
図 8-1 に、サーバに接続して EJB 上で動作する実装クラスに、EJB の呼び出しを委託する CORBA クライアントを示します。同様のアーキテクチャを使用すると、これとは逆の状況でも機能します。起動クラスを使用すると、ORB を起動し、対象となる CORBA 実装オブジェクトへの参照を取得できます。このクラスは、JNDI ツリー内の別の WebLogic オブジェクトで使用できるようにして、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();
}
}
}
Common Secure Interoperability 仕様バージョン 2 (CSIv2) は、相互運用可能な認証、委託、および権限のための Common Object Request Broker Architecture (CORBA) セキュリティの要件に応える Open Management Group (OMG) 仕様です。『WebLogic Security について』の「CSIv2 (Common Secure Interoperability Version 2)」を参照してください。
次の手順に従って、CSIv2 を使用してリモート ドメインからの着信呼び出しを認証します。
| 注意 : | この機能は、ハードウェア ロード バランサを使用してブートストラップを行っている場合にのみ正常に動作します。 |
WebLogic Server の BEA ORB を拡張すると、ブートストラップ時の再接続の強制によるハードウェア ロード バランシングをサポートできます。これにより、ハードウェア ロード バランサによる接続試行のバランシングが可能になります。
ほとんどの場合、いったん接続が確立されると、元の接続を使用して次の NameService ルックアップが実行されます。しかし、この機能はハードウェア ロード バランサにエンド ポイントの再ネゴシエーションを強制するため、既存の接続で処理中のリクエストはすべて破棄されます。
-Dweblogic.system.iiop.reconnectOnBootstrap システム プロパティを使用すると、BEA ORB の接続動作を設定できます。有効な値は以下のとおりです。
ハードウェア ロード バランサを必要とする環境では、このプロパティを true に設定する必要があります。
以下の各節では、WebLogic RMI-IIOP に関するさまざまな問題点の概要を説明します。
WebLogic Server と一緒に使用する JDK は、バージョン 1.3.1_01 またはそれ以降でなければなりません。それ以前のバージョンは RMI-IIOP に準拠していません。これら旧バージョンの JDK には以下の問題点があることに注意してください。
これらの多くは、両方でサポートすることが不可能なものです。選択肢がいくつかある場合には、WebLogic では仕様に準拠する方をサポートしています。
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++ コードを書く必要があります。サンプル コードについては、http://dev2dev.bea.com/ の 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 クライアント アプリケーションに組み込まれます。
最近まで、CORBA クライアントからのクライアント ID の伝播に関する標準が十分ではありませんでした。外部 ORB のクライアント 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 を使用するために、WebLogic Server を特別にコンフィグレーションする必要はありません。RMI オブジェクトは通常、起動クラスによって JNDI ツリーにバインドされます。EJB ホームは、デプロイメント時に JNDI ツリーにバインドされます。WebLogic Server は、JNDI ツリーのルックアップ呼び出しをすべて委託することにより、CosNaming Service を実装します。corbaname および corbaloc の各 RMI-IIOP JNDI 参照をサポートしている。CORBA/IIOP 2.4.2 仕様を参照してください。これらの参照の特徴の 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/j2ee/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++ クライアントを使用することによって回避することもできます。サンプル コードについては、http://dev2dev.bea.com/ の iiop/ejb/stateless/sectuxclient サンプルを参照してください。
  
|
