| Oracle® Fusion Middleware Oracle WebLogic Server RMIアプリケーションの開発 12c (12.2.1.1.0) E79316-01 |
|
 前 |
 次 |
この章には次の項が含まれます:
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シン・クライアント・プロキシを使用すると、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の設定を参照してください。
SSLをサポートするJavaクライアントは、シン・クライアントとWLS-IIOPクライアントです。これらのクライアントでは、ssl URLを指定するだけでSSLを使用できます。
WebLogic Serverには、CORBAクライアントからRMIリモート・オブジェクトにアクセスできるようにするサービスが用意されています。また、それ以外の方法として、WebLogic ServerにCORBA ORB (Object Request Broker)をホストし、発着信メッセージをそのORBに委任することで、サーバー内でバインド可能なあらゆるオブジェクトをCORBAクライアントから間接的に呼び出せるようにすることもできます。
WebLogic ServerをホストとするオブジェクトにCORBA呼出しを委任するには、いくつかのオブジェクトが連携してそれを実行する必要があります。それらのオブジェクトを作成する主な手順を以下に示します。
以下の図 に、サーバーに接続してEJB上で動作する実装クラスに、EJBの呼出しを委任するCORBAクライアントを示します。同様のアーキテクチャを使用すると、これとは逆の状況でも機能します。起動クラスを使用すると、ORBを起動し、対象となるCORBA実装オブジェクトへの参照を取得できます。このクラスは、JNDIツリー内の別のWebLogicオブジェクトで使用できるようにして、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();
}
}
}
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を使用してリモート・ドメインからのインバウンド呼出しを認証します。
注意:
この機能は、ハードウェア・ロード・バランサを使用してブート・ストラップを行っている場合にのみ正常に動作します。
WebLogic ServerのOracle ORBを拡張すると、ブート・ストラップ時の再接続の強制によるハードウェア・ロード・バランシングをサポートできます。これにより、ハードウェア・ロード・バランサによる接続試行のバランシングが可能になります。
ほとんどの場合、いったん接続が確立されると、元の接続を使用して次のNameServiceルックアップが実行されます。しかし、この機能はハードウェア・ロード・バランサにエンド・ポイントの再ネゴシエーションを強制するため、既存の接続で処理中のリクエストはすべて破棄されます。
-Dweblogic.system.iiop.reconnectOnBootstrapシステム・プロパティを使用すると、Oracle ORBの接続動作を設定できます。有効な値は以下のとおりです。
true: エンド・ポイントの再ネゴシエーションを強制します。
false - デフォルト値
ハードウェア・ロード・バランサを必要とする環境では、このプロパティをtrueに設定する必要があります。
以下の各節では、WebLogic 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では仕様に準拠する方をサポートしています。
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クライアント・アプリケーションに組み込まれます。
最近まで、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++クライアントを使用することによって回避することもできます。
