WebLogic RMI over IIOP プログラマーズ ガイド
|
 |
 |
|
以下の各節では、さまざまなプログラミング モデルを用いた RMI-IIOP アプリケーションの開発方法について説明します。
IIOP は、異機種分散システム間の相互運用が容易になるように設計された堅牢なプロトコルで、多くのベンダによってサポートされています。RMI-IIOP に関連する基本的なプログラミング モデルには、RMI クライアントを使用した RMI-IIOP (RMI クライアント使用型 RMI-IIOP) と IDL クライアントを使用した RMI-IIOP (IDL クライアント使用型 RMI-IIOP) の 2 種類があります。これらのモデルの機能や概念はある程度共通しています。たとえば、どちらのモデルでも Object Request Broker (ORB) および Internet InterORB Protocol (IIOP) を使用します。ただし、これら 2 つのモデルには、異機種システム間での相互運用が可能な環境を作成するためのアプローチとしては、はっきりとした違いがあります。IIOP は単に、インタフェースが IDL か Java RMI のどちらかで記述された分散アプリケーションの転送プロトコルにすぎません。プログラムを作成する際には、IDL インタフェースと RMI インタフェースのどちらを使用するかを決める必要があり、2 つを混在させることはできません。
分散アプリケーション環境をどのように作成するかは、いくつかの要因で決まります。RMI-IIOP を採用するためのモデルにはさまざまなものがあり、それらが提供する機能や標準の多くが共通しているので、どのモデルに従えばよいか見通しが立てにくいのが現状です。
次の表には、WebLogic Server 環境でサポートされるクライアントのタイプと、それぞれの特徴、機能、および制約についてまとめてあります。表では、RMI-IIOP の 2 種類だけでなく、T3 および CORBA クライアントの選択肢についても取り上げています。
表 2-1 WebLogic Server クライアントのタイプと機能
|
|
|||||
WebLogic Server 8.1 では、独自の ORB 実装が提供されています。この ORB は、プログラムで ORB.init() が呼び出されるとき、または JNDI で "java:comp/ORB" がルックアップされるときにデフォルトでインスタンス化されます。WebLogic Server が J2SE 1.4 における CORBA サポートの仕様にどのように準拠するかについては、「WebLogic Server 8.1 での CORBA のサポート」を参照してください。
デフォルトの WebLogic Server 実装以外の ORB を使用するには、次のプロパティを設定します。
org.omg.CORBA.ORBSingletonClass=<classname>
org.omg.CORBA.ORBClass=<classname>
ORBSingletonClass はサーバのコマンドラインで設定する必要があります。ORBClass には、ORB.init() のプロパティ引数を設定できます。
別の RMI-IIOP 実装を使用するには、次の 2 つのプロパティを設定する必要があります。
javax.rmi.CORBA.UtilClass=<classname>
javax.rmi.CORBA.PortableRemoteObjectClass=<classname>
<Sep 19, 2003 9:12:03 AM CDT> <Error> <IIOP> <BEA-002015> <Using javax.rmi.CORBA.UtilClass <classname>; The IIOP subsystem requires a WebLogic Server-compatible UtilClass.>
<Sep 19, 2003 9:12:03 AM CDT> <Error> <IIOP> <BEA-002016> <Using javax.rmi.CORBA.PortableRemoteObjectClass <classname>, the IIOP subsystemrequires a WebLogic Server-compatible PortableRemoteObjectClass.>
WebLogic RMI-IIOP ランタイムは動作しないことを示しています。
これらのプロパティに対する J2SE のデフォルトは次のとおりです。
org.omg.CORBA.ORBSingletonClass=com.sun.corba.se.internal.corba.ORBSingleton
org.omg.CORBA.ORBClass=com.sun.corba.se.internal.Interceptors.PIORB
javax.rmi.CORBA.UtilClass=com.sun.corba.se.internal.POA.ShutdownUtilDelegate
javax.rmi.CORBA.PortableRemoteObjectClass=com.sun.corba.se.internal.javax.rmi.PortableRemoteObject
RMI は、分散コンピューティングの Java-to-Java モデルです。RMI を使用すると、ネットワーク内の別の場所に存在するオブジェクトへの参照をアプリケーション側で取得することができます。RMI-IIOP モデルはすべて RMI に基づいていますが、IIOP を使用しない基本的な RMI モデルに従う場合には、Java 以外の言語で記述されたクライアントを統合することはできません。また、独自プロトコルである T3 を使用して、クライアント側に WebLogic クラスを用意することもあります。RMI アプリケーションの開発については、「WebLogic RMI の機能とガイドライン」を参照してください。
RMI クライアントを使用した RMI over IIOP (RMI クライアント使用型 RMI over IIOP) では、RMI の機能と標準 IIOP プロトコルが一体化されており、完全に Java プログラミング言語だけで作業できるようになっています。RMI クライアント使用型 RMI-IIOP は Java-to-Java モデルであり、その場合 ORB は通常、クライアントで動作する JDK の一部となっています。RMI-IIOP では、オブジェクトは参照としても値としても渡すことができます。
J2SE クライアントは J2EE プログラミング モデルを指向しており、RMI の機能と IIOP プロトコルが一体化されています。アプリケーションが Java で開発されており、IIOP の利点を活用したいと考えているのであれば、RMI クライアントを使用した RMI-IIOP モデルをお勧めします。RMI-IIOP を使用する場合、Java ユーザは RMI インタフェースのプログラムを作成した後、基礎となる転送メカニズムとして IIOP を使用することができます。RMI クライアントは、J2EE または J2SE コンテナ (ほとんどの場合、JDK 1.3 以降) をホストとする RMI-IIOP 対応 ORB を実行します。WebLogic のクラスは不要であり、必要なものはこのシナリオで自動的にダウンロードされます。これはクライアントの分散を最小にするにはよい方法です。また、通常の WebLogic RMI で用いられる独自の t3 プロトコルを使用する必要もありません。使用するのは、独自仕様でない業界標準に基づいた IIOP です。
このクライアントは、J2EE ではなく J2SE に準拠しているので、エンタープライズレベルのアプリケーションで提供される多彩な機能をサポートしていません。アプリケーションの要件によっては、このクライアントは必要な機能を提供できない可能性があります。また、セキュリティ、トランザクション、JMS もサポートしていません。
RMI クライアント使用型 RMI-IIOP を用いてアプリケーションを開発するには、以下の手順に従います。
このクラスには、記述済みのリモート インタフェースを実装する必要があります。これは、インタフェースに含まれるメソッド シグネチャを実装したことを意味します。すべてのコード生成はこのクラスファイルに依存します。通常は、実装クラスを WebLogic 起動クラスとしてコンフィグレーションし、そのオブジェクトを JNDI ツリー内にバインドする main メソッドを組み込みます。
-iiop オプションを使用する必要はありません。$ java weblogic.rmic nameOfImplementationClass
スタブはリモート オブジェクト用のクライアントサイド プロキシで、個々の WebLogic RMI 呼び出しを対応するサーバサイド スケルトンに転送します。今度は、サーバサイド スケルトンが、その呼び出しを実際のリモート オブジェクト実装に転送します。なお、WebLogic RMI コンパイラで作成される IIOP スタブは、JDK 1.3.1_01 以降の ORB で使用するためのものである点に注意してください。他の ORB を使用する場合、それぞれの ORB ベンダのマニュアルを参照して、これらのスタブが適切かどうかを判断してください。
RMI クライアントは、初期コンテキストを作成しオブジェクトをルックアップする (次の手順を参照) ことで、リモート オブジェクトにアクセスします。次に、このオブジェクトは適切な型にキャストされます。
初期コンテキストの取得では、JNDI コンテキスト ファクトリを定義する際に com.sun.jndi.cosnaming.CNCtxFactory を使用する必要があります (WebLogic Server 8.1 では、WLInitialContextFactory はこのクライアント用として非推奨)。新しい InitialContext() にパラメータとして渡す「Context.INITIAL_CONTEXT_FACTORY」プロパティの値を設定する際には、com.sun.jndi.cosnaming.CNCtxFactory を使用します。
注意 : Sun JNDI クライアントでは、ネームスペースからリモート オブジェクト参照を読み込む機能はサポートされていますが、シリアライズされた汎用 Java オブジェクトの読み込みはサポートされていません。つまり、ネームスペースから EJBHome などを読み込むことはできますが、DataSource オブジェクトを読み込むことはできません。このコンフィグレーションでは、クライアントが開始したトランザクション (JTA API) もサポートされません。また、セキュリティもサポートされていません。ステートレス セッション Bean の RMI クライアントの例では、次のコードで初期コンテキストを取得します。
InitialContext の取得 :
* JDK1.3 クライアントでは、Properties オブジェクトを
* 次のように使用できる
*/
private Context getInitialContext() throws NamingException {
try {
// InitialContext を取得
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.cosnaming.CNCtxFactory");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
} catch (NamingException ne) {
log("We were unable to get a connection to the WebLogic server at "+url);
log("Please make sure that the server is running.");
throw ne;
}
/**
* Java2 バージョンを使用して InitialContext を取得する場合。
* このバージョンは、jndi.properties ファイルがアプリケーションのクラスパス
* に存在するかどうかに依存する。詳細については、
* 『WebLogic JNDI プログラマーズ ガイド』を参照
private static Context getInitialContext()
throws NamingException
{
return new InitialContext();
}
RMI over IIOP RMI クライアントが通常の RMI クライアントと異なるのは、初期コンテキストを取得する際にプロトコルとして IIOP が定義されるという点です。このため、ルックアップとキャストは、javax.rmi.PortableRemoteObject.narrow() メソッドと組み合わせて行われます。
通常ならオブジェクトを特定のクラス型へキャストするような状況ではすべて、javax.rmi.PortableRemoteObject.narrow() メソッドを使用する必要があります。CORBA クライアントからは、リモート インタフェースを実装しないオブジェクトが返されることがあります。そのため、リモート インタフェースを実装するようオブジェクトを変換するために ORB から narrow メソッドが提供されます。たとえば、EJB ホームをルックアップしてその結果を Home オブジェクトにキャストするクライアント コードは、以下に示すように、javax.rmi.PortableRemoteObject.narrow() を使用するように修正する必要があります。
ルックアップの実行 :
/**
* RMI/IIOP クライアントはこの narrow 関数を使用する
*/
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref, c);
}
/**
* JNDI ツリーで EJB ホームをルックアップ
*/
private TraderHome lookupHome()
throws NamingException
{
// JNDI を使用して Bean ホームをルックアップ
Context ctx = getInitialContext();
try {
Object home = ctx.lookup(JNDI_NAME);
return (TraderHome) narrow(home, TraderHome.class);
} catch (NamingException ne) {
log("The client was unable to lookup the EJBHome. Please
make sure ");
log("that you have deployed the ejb with the JNDI name
"+JNDI_NAME+" on the WebLogic server at "+url);
throw ne;
}
}
/**
* JDK1.3 クライアントでは、次のように Properties オブジェクトを使用すると
* 機能する
*/
private Context getInitialContext() throws NamingException {
try {
// InitialContext を取得
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.cosnaming.CNCtxFactory");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
} catch (NamingException ne) {
log("We were unable to get a connection to the WebLogic
server at "+url);
log("Please make sure that the server is running.");
throw ne;
}
}
url では、プロトコル、ホスト名、WebLogic Server 用のリスン ポートを定義し、それらがコマンドライン引数として渡されます。
public static void main(String[] args) throws Exception {
log("\nBeginning statelessSession.Client...\n");
String url = "iiop://localhost:7001";
$ java -Djava.security.manager -Djava.security.policy=java.policy examples.iiop.ejb.stateless.rmiclient.Client iiop://localhost:7001
java -Djava.security.manager -Djava.security.policy==java.policy myclient
クライアント側の RMI インタフェースをナロー変換するには、サーバからそのインタフェースに適したスタブが提供される必要があります。このクラスのロードは、JDK ネットワーク クラスローダの使用を前提としており、デフォルトでは有効にはなっていません。これを有効にするには、適切な Java ポリシー ファイルを使用して、クライアントにセキュリティ マネージャを設定する必要があります。Java セキュリティの詳細については、Sun のサイト (http://java.sun.com/security/index.html) を参照してください。java.policy ファイルの例を以下に示します。
permission java.security.AllPermission;
J2EE アプリケーション クライアントはクライアント マシン上で実行され、マークアップ言語で得られるよりも豊富なユーザ インタフェースを提供できます。アプリケーション クライアントはビジネス層で実行されているエンタープライズ Bean に直接アクセスし、適宜 HTTP を介して Web 層で実行されているサーブレットと通信できます。一般に、アプリケーション クライアントはサーバからダウンロードされますが、クライアント マシン上にインストールすることもできます。
J2EE アプリケーション クライアントは Java アプリケーションですが、J2EE コンポーネントであるため、スタンドアロンの Java アプリケーション クライアントとは異なります。具体的には、他の J2EE 準拠のサーバへ移植できるという利点があり、J2EE サービスにアクセスできます。
WebLogic Server アプリケーション クライアントは、標準クライアントと JMS クライアントとして用意され、2 つの独立した jar ファイル (wlclient.jar と wljmsclient.jar) にパッケージ化されて WebLogic Server インストール ディレクトリの WL_HOME/server/lib サブディレクトリに存在します。各 jar は約 400KB です。
シン クライアントは RMI-IIOP プロトコル スタックに基づいており、J2SE 1.4 の新機能を活用しています。また、JDK ORB のサポートも必要です。シン クライアントは JRE 1.4 の以前のリリースでも動作しますが、JRE 1.4.2_04 以降を使用することをお勧めします。RMI リクエストの作成は基本的に JDK によって処理されるため、非常に小さいクライアントを実現できます。クライアントサイドの開発には、WebLogic Server API ではなく標準の J2EE API を使用します。
シン クライアント アプリケーションの開発プロセスは、他の J2EE アプリケーションを開発する場合と同じです。クライアントは InitialContext、UserTransaction、EJB などの標準 J2EE アーティファクトを活用できます。WebLogic Server シン クライアントは、URL のプロトコル部分の値として iiop、iiops、http、https、t3、および t3s をサポートしています。各々、InitialContext で異なる URL を使うことで選択できます。URL に関係なく、IIOP は必ず使用されます。URL に t3 を指定すると iiop が使用され、t3s を指定すると iiops が使用されます。http は iiop 上を、https は iiops 上をトンネリングされます。
サーバサイド コンポーネントは、通常の方法でデプロイされます。クライアント スタブは、デプロイ時または実行時に生成できます。デプロイ時にスタブを生成するには、-iiop および -basicClientJar オプションを付けて appc を実行し、シン クライアントでの使用に適したクライアント jar を作成します。この手順を実行しない場合、WebLogic Server が必要に応じて実行時にスタブを生成し、クライアントに提供します。クライアントがスタブをダウンロードするには、適切なセキュリティ マネージャがインストールされている必要があります。シン クライアントは、デフォルトの軽量セキュリティ マネージャを提供します。強固なセキュリティが必要な場合は、コマンドライン オプションの -Djava.security.manager -Djava.security.policy==policyfile を使用して、別のセキュリティ マネージャをインストールできます。アプレットは、スタブのダウンロードを可能にする別のセキュリティ マネージャを使用します。
シン クライアント jar では、完全 jar とシン クライアント jar の両方が CLASSPATH にあった場合に、weblogic.jar 内のクラスをいくつか置き換えて、シン クライアント jar がパス内で先になるようにします。ただし、シン クライアントのサポートに weblogic.jar は必須ではありません。必要な場合は、次の構文に従って、明示的に CLASSPATH を指定して実行できます。
java -classpath "<WL_HOME>/lib/wlclient.jar;<CLIENT_CLASSES>" your.app.Main
注意 : wljmsclient.jar は wlclient.jar を参照するので、CLASSPATH にはどちらか一方の jar を指定するだけでかまいません。
シン クライアント jar をサーバサイドの CLASSPATH に入れないでください。
シン クライアント jar には、javax.ejb などの必要な J2EE インタフェース クラスが用意されているので、クライアントにその他の jar ファイルは必要ありません。
J2EE アプリケーション クライアントを開発するには、以下の手順に従います。
このクラスには、記述済みのリモート インタフェースを実装する必要があります。これは、インタフェースに含まれるメソッド シグネチャを実装したことを意味します。すべてのコード生成はこのクラスファイルに依存します。通常は、実装クラスを WebLogic 起動クラスとしてコンフィグレーションし、そのオブジェクトを JNDI ツリー内にバインドする main メソッドを組み込みます。以下は、先ほどの Ping の例を基に開発した実装クラスからの抜粋です。
public static void main(String args[]) throws Exception {
if (args.length > 0)
remoteDomain = args[0];
Pinger obj = new PingImpl();
Context initialNamingContext = new InitialContext();
initialNamingContext.rebind(NAME,obj);
System.out.println("PingImpl created and bound to "+ NAME);
}
注意 : スタブをダウンロードする場合は、rmic を実行する必要はありません。
$ java weblogic.rmic -iiop nameOfImplementationClass
RMI クライアントは、初期コンテキストを作成しオブジェクトをルックアップする (次の手順を参照) ことで、リモート オブジェクトにアクセスします。次に、このオブジェクトは適切な型にキャストされます。
初期コンテキストの取得では、JNDI コンテキスト ファクトリを定義する際に weblogic.jndi.WLInitialContextFactory を使用する必要があります。新しい InitialContext() にパラメータとして渡す「Context.INITIAL_CONTEXT_FACTORY」プロパティの値を設定する際には、このクラスを使用します。
RMI over IIOP RMI クライアントが通常の RMI クライアントと異なるのは、初期コンテキストを取得する際にプロトコルとして IIOP が定義されるという点です。このため、ルックアップとキャストは、javax.rmi.PortableRemoteObject.narrow() メソッドと組み合わせて行われます。
通常ならオブジェクトを特定のクラス型へキャストするような状況ではすべて、javax.rmi.PortableRemoteObject.narrow() メソッドを使用する必要があります。CORBA クライアントからは、リモート インタフェースを実装しないオブジェクトが返されることがあります。そのため、リモート インタフェースを実装するようオブジェクトを変換するために ORB から narrow メソッドが提供されます。たとえば、EJB ホームをルックアップしてその結果を Home オブジェクトにキャストするクライアント コードは、以下に示すように、javax.rmi.PortableRemoteObject.narrow() を使用するように修正する必要があります。
ルックアップの実行 :
/**
* RMI/IIOP クライアントはこの narrow 関数を使用する
*/
private Object narrow(Object ref, Class c) {
return PortableRemoteObject.narrow(ref, c);
}
/**
* JNDI ツリーで EJB ホームをルックアップ
*/
private TraderHome lookupHome()
throws NamingException
{
// JNDI を使用して Bean ホームをルックアップ
Context ctx = getInitialContext();
try {
Object home = ctx.lookup(JNDI_NAME);
return (TraderHome) narrow(home, TraderHome.class);
} catch (NamingException ne) {
log("The client was unable to lookup the EJBHome. Please
make sure ");
log("that you have deployed the ejb with the JNDI name
"+JNDI_NAME+" on the WebLogic server at "+url);
throw ne;
}
}
/**
* JDK1.3 クライアントでは、次のように Properties オブジェクトを使用すると
* 機能する
*/
private Context getInitialContext() throws NamingException {
try {
// InitialContext を取得
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, url);
return new InitialContext(h);
}catch (NamingException ne) {
log("We were unable to get a connection to the WebLogic
server at "+url);
log("Please make sure that the server is running.");
throw ne;
}
}
url では、プロトコル、ホスト名、WebLogic Server 用のリスン ポートを定義し、それらがコマンドライン引数として渡されます。
public static void main(String[] args) throws Exception {
log("\nBeginning statelessSession.Client...\n");
String url = "iiop://localhost:7001";
$ java -Djava.security.manager -Djava.security.policy=java.policy examples.iiop.ejb.stateless.rmiclient.Client iiop://localhost:7001
JAAS (Java Authentication and Authorization Service) およびセキュア ソケット レイヤ (SSL) を使用する Weblogic クライアントを開発できます。
JAAS は、ユーザ ID に基づくアクセス制御機能を提供します。WebLogic Server クライアントの認証方法としては、より望ましい選択肢です。一般には、ファイルの読み込みや書き込みの認証方法として使用します。クライアントの証明書認証 (双方向 SSL 認証) が必要な場合は JNDI 認証を使用します。JAAS 認証の実装方法の詳細については、「Java クライアントでの JAAS 認証の使用」を参照してください。
WebLogic シン クライアント アプリケーションでの JAAS 認証は以下のクラスでのみサポートされます。
BEA WebLogic Server では、WebLogic Server クライアントとサーバ、Java クライアント、Web ブラウザ、および他のサーバの間で転送されるデータを暗号化するためにセキュア ソケット レイヤ (SSL) がサポートされています。
すべての SSL クライアントは、信頼を指定する必要があります。信頼は、どの信頼性のある認証局がクライアントから信頼されるのかを指定する CA 証明書の集合です。SSL 接続を確立するためには、RMI クライアントはサーバのデジタル証明書を発行した認証局を信頼する必要があります。サーバの信頼性のある CA 証明書の場所は、RMI クライアントを起動する際に指定します。
デフォルトでは、JDK (...\jre\lib\security\cacerts) で利用できる信頼性のあるすべての認証局が RMI クライアントから信頼されます。サーバの信頼性のある CA 証明書がこのキーストアに格納されている場合は、何も設定する必要はありません。また、サーバの信頼性のある CA 証明書は、以下のタイプの信頼キーストアに格納することもできます。
WL_HOME\server\lib directory ディレクトリに配置されたデモ用信頼キーストア (DemoTrust.jks) の信頼性のある CA 証明書。JDK cacerts キーストアの信頼性のある CA も信頼されます。デモ信頼を使用するには、次のコマンドライン引数を指定します。 -Dweblogic.security.TrustKeyStore=DemoTrust
次のコマンドライン引数を必要に応じて使用すると、JDK cacerts 信頼キーストアのパスワードを指定できます。
-Dweblogic.security.JavaStandardTrustKeystorePassPhrase=password
password は、Java 標準信頼キーストアのパスワードです。このパスワードは、キーストアを作成するときに定義します。
サーバサイド SSL の実装方法の詳細については、「SSL を使用した RMI over IIOP のコンフィグレーション」を参照してください。
WebLogic シン クライアントでは、双方向 SSL のみがサポートされます。双方向 SSL には、SECURITY_CREDENTIALS プロパティに指定されている SSLContext が必要です。例として、次のクライアント コードを参照してください。
.
.
.
// KeyManager の KeyManagerFactory を取得する
System.out.println("Retrieving KeyManagerFactory & initializing");
KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509","SunJSSE");
kmf.init(ks,keyStorePassword);
// SSLContext を取得して初期化する
System.out.println("Initializing the SSLContext");
SSLContext sslCtx = SSLContext.getInstance("SSL");
sslCtx.init(kmf.getKeyManagers(),null,null);
// SSLContext を初期コンテキスト ファクトリに渡し、InitialContext
// を取得する
System.out.println("Getting initial context");
Hashtable props = new Hashtable(); props.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
props.put(Context.PROVIDER_URL,
"corbaloc:iiops:" +
host + ":" + port +
"/NameService");
props.put(Context.SECURITY_PRINCIPAL,"weblogic");
props.put(Context.SECURITY_CREDENTIALS, sslCtx);
Context ctx = new InitialContext(props);
.
.
.
WebLogic Server 製品には、セキュリティのサンプルが用意されています。これらのサンプルは、SAMPLES_HOME\server\examples\src\examples\security ディレクトリにあります。各サンプルの説明と、サンプルをビルド、コンフィグレーション、実行する方法については、package-summary.html ファイルを参照してください。これらのコード サンプルは、変更して再利用できます。
WebLogic Server では、WLS-IIOP クライアントという「ファット」RMI-IIOP クライアントをサポートされています。また、WLS-IIOP クライアントではクラスタ化がサポートされています。
WLS-IIOP クライアントをサポートするには、以下を行う必要があります。
weblogic.jar (WL_HOME/server/lib に存在) をクライアントの CLASSPATH に指定する。weblogic.jndi.WLInitialContextFactory を使用する。新しい InitialContext() にパラメータとして渡す「Context.INITIAL_CONTEXT_FACTORY」プロパティの値を設定する際には、このクラスを使用します。上記以外の WLS-IIOP の開発手順は、「J2SE クライアントの開発」で説明した手順と同じです。
注意 : WebLogic Server 8.1 では、クライアントの起動時に -D weblogic.system.iiop.enableClient=true コマンドライン オプションを使用して、クライアント アクセスを有効にする必要はありません。weblogic.jar を使用する場合、enableClient はデフォルトで true に設定されています。
CORBA/IDL クライアントを使用した RMI over IIOP (CORBA/IDL クライアント使用型 RMI over IIOP) には、ORB (Object Request Broker) と共に、IDL と呼ばれる相互運用のための言語を作成するコンパイラが必要になります。C、C++、COBOL などは、ORB で IDL にコンパイル可能な言語の例です。CORBA のプログラマは、CORBA インタフェース定義言語 (IDL : Interface Definition Language) のインタフェースを使用して、CORBA オブジェクトの定義、実装、および Java プログラミング言語からのアクセスが可能です。
CORBA/IDL クライアント使用型 RMI-IIOP を用いると、Java 以外のクライアントと Java オブジェクトとの相互運用が可能になります。CORBA アプリケーションがすでに存在する場合には、CORBA/IDL クライアント使用型 RMI-IIOP モデルに従ってプログラムを作成しなければなりません。基本的に、IDL インタフェースは Java から生成します。クライアント コードと WebLogic Server との通信は、これらの IDL インタフェースを介して行われます。これが基本的な CORBA プログラミングです。
以下の各節では、CORBA/IDL クライアント使用型 RMI-IIOP アプリケーションを開発するためのガイドラインを少し示します。
詳細については、Object Management Group (OMG) による以下の仕様を参照してください。
CORBA では、リモート オブジェクトへのインタフェースは、プラットフォームに依存しないインタフェース定義言語 (IDL) で記述されます。IDL を特定の言語にマッピングするには、IDL コンパイラで IDL をコンパイルします。IDL コンパイラによって、スタブやスケルトンといった多くのクラスが生成されます。これらのクラスは、クライアントやサーバで、リモート オブジェクトへの参照の取得、リクエストの転送、および受信した呼び出しのマーシャリングに使用されます。IDL クライアントを使用する場合でも、以降の各節で示すように、プログラミングを行うに当たっては、まず Java リモート インタフェースおよび実装クラスの作成から始め、その後 IDL を生成して、WebLogic クライアントおよび CORBA クライアントとの相互運用性を実現することを強くお勧めします。IDL でコードを記述した後、その逆マッピングによって Java コードを作成することも可能ですが、それは難しく、多数のバグを発生させることになるので、WebLogic ではお勧めしません。
IDL と RMI-IIOP モデルの関係を以下の図に示します。
図 2-1 IDL クライアント (CORBA オブジェクト) の関係
WebLogic RMI では、リモート オブジェクトへのインタフェースは、java.rmi.Remote を拡張した Java リモート インタフェースに記述されます。「Java-to-IDL マッピング」仕様では、IDL が Java リモート インタフェースからどのように作成されるのかを定義しています。WebLogic RMI over IIOP 実装では、-idl オプションを付けて WebLogic RMI コンパイラまたは WebLogic EJB コンパイラで実装クラスを実行します。このプロセスによって、リモート インタフェースの IDL 相当部分が作成されます。その後、この IDL を IDL コンパイラでコンパイルして、CORBA クライアントに必要なクラスを生成します。
クライアントは、リモート オブジェクトへの参照を取得し、スタブを介してメソッド呼び出しを転送します。WebLogic Server には、着信した IIOP リクエストを解析し RMI 実行時環境に直接ディスパッチする CosNaming サービスが実装されています。
図 2-2 WebLogic RMI over IIOP オブジェクトの関係
Objects-by-Value 仕様により、2 つのプログラミング言語間で複合データ型をやり取りできるようになります。IDL クライアントで Objects-by-Value をサポートするには、Objects-by-Value をサポートする ORB (Object Request Broker) と組み合わせてそのクライアントを開発する必要があります。現在のところ、Objects-by-Value を正確にサポートしている ORB は比較的少数です。
IDL を使用する RMI over IIOP アプリケーションを開発する際には、IDL クライアントで Objects-by-Value をサポートするかどうかを検討し、それに応じて RMI インタフェースを設計する必要があります。クライアント ORB が Objects-by-Value をサポートしない場合、RMI インタフェースを制限して、他のインタフェースか CORBA プリミティブ データ型のみを渡すようにする必要があります。Objects-by-Value のサポート状況に関して BEA Systems で検証した ORB とその結果を以下の一覧表に示します。
Objects-by-Value の詳細については、「オブジェクトの値渡しに関する制約」を参照してください。
CORBA/IDL を使用した RMI over IIOP アプリケーションを開発するには、以下の手順に従います。
-idl オプションを付けて「WebLogic RMI コンパイラ」または「WebLogic EJB コンパイラ」を実行することで、IDL ファイルを生成します。 IDL ファイルをコンパイルすると、必要なスタブ クラスが生成されます。CORBA/IDL クライアントがエンタープライズ Bean オブジェクトにアクセスする方法の詳細については、「RMI-IIOP での EJB の使用 」を参照してください。また、Java IDL 仕様については、「Java 言語の OMG IDL へのマッピング仕様」を参照してください。
以下のコンパイラ オプションは、RMI over IIOP に固有のものです。
オプションの適用例を、次の RMI コンパイラの実行例で示します。
> java weblogic.rmic -idl -idlDirectory /IDL rmi_iiop.HelloImpl
このコンパイラでは、実装クラスのパッケージに従って、IDL ファイルを、idlDirectoy のサブディレクトリ内に生成します。たとえば、上記のコマンドの場合には、Hello.idl ファイルが /IDL/rmi_iiop ディレクトリに生成されます。idlDirectory オプションが使用されない場合には、IDL ファイルは、スタブ クラスやスケルトン クラスの生成先からの相対パスに生成されます。
WebLogic コンパイラで生成された IDL ファイルには、#include orb.idl ディレクティブが含まれています。この IDL ファイルは各 ORB ベンダから提供されます。orb.idl ファイルは、WebLogic 配布キットの \lib ディレクトリにあります。このファイルは、WebLogic Server に付属の JDK に含まれている ORB だけで使用するためのものです。
IDL クライアントは、純粋な CORBA クライアントで、WebLogic クラスはまったく必要としません。ORB ベンダによっては、リモート クラスへの参照を解決し、ナロー変換して、取得する場合のために、追加のクラスが生成されることがあります。VisiBroker 4.1 ORB 向けに開発された次のクライアントの例では、クライアントはネーミング コンテキストを初期化し、リモート オブジェクトへの参照を取得し、そのリモート オブジェクトに対するメソッドを呼び出します。
RMI-IIOP サンプルの C++ クライアントから抜粋したコード
// 文字列をオブジェクトに変換
CORBA::Object_ptr o;
cout << "Getting name service reference" << endl;
if (argc >= 2 && strncmp (argv[1], "IOR", 3) == 0)
o = orb->string_to_object(argv[1]);
else
o = orb->resolve_initial_references("NameService");
// ネーミング コンテキストを取得
cout << "Narrowing to a naming context" << endl;
CosNaming::NamingContext_var context = CosNaming::NamingContext::_narrow(o);
CosNaming::Name name;
name.length(1);
name[0].id = CORBA::string_dup("Pinger_iiop");
name[0].kind = CORBA::string_dup("");
// 解決し RMI オブジェクトにナロー変換する
cout << "Resolving the naming context" << endl;
CORBA::Object_var object = context->resolve(name);
cout << "Narrowing to the Ping Server" << endl;
::examples::iiop::rmi::server::wls::Pinger_var ping =
::examples::iiop::rmi::server::wls::Pinger::_narrow(object);
// ping を呼び出す
cout << "Ping (local) ..." << endl;
ping->ping();
ネーミング コンテキストを取得する前に、標準のオブジェクト URL (「CORBA/IIOP 2.4.2 仕様」のセクション 13.6.7 を参照) を使用して初期参照が解決されている点に注意します。サーバでのルックアップが、COS ネーミング サービス API を実装する JNDI のラッパーによって解決されています。
このネーミング サービスは、WebLogic Server アプリケーションが論理名を使ってオブジェクト参照を公開するのを可能にしています。CORBA ネーム サービスから提供されるものは以下のとおりです。
WebLogic C++ クライアントは、Tuxedo 8.1 C++ クライアント ORB を使用して、WebLogic Server で実行している EJB に対して IIOP リクエストを生成します。このクライアントでは、Objects-by-Value および CORBA Interoperable Naming Service (INS) をサポートします。
以下のような場合は、WebLogic C++ クライアントの使用を検討してください。
Tuxedo C++ クライアント ORB は Tuxedo 8.1 以降にパッケージ化されていますが、WebLogic C++ クライアントの開発に Tuxedo のライセンスは必要ありません。開発試用版の Tuxedo は BEA Evaluation Center から入手できます。
WebLogic C++ クライアントは、次のモデルに基づいてクライアント リクエストを処理します。
図 2-3 WebLogic C++ クライアントと WebLogic Server の相互運用性
WebLogic Server 製品には、C++ クライアントのサンプルが用意されています。これらのサンプルは、SAMPLES_HOME\server\examples\src\examples\iiop\ejb ディレクトリにあります。各サンプルの説明と、サンプルをビルド、コンフィグレーション、実行する方法については、package-summary.html ファイルを参照してください。これらのコード サンプルは、変更して再利用できます。
WebLogic Tuxedo Connector を使用すると、WebLogic Server アプリケーションと Tuxedo サービスの相互運用が実現されます。
Tuxedo で開発したアプリケーションを WebLogic Server に移行する場合や、従来の Tuxedo システムを新しい WebLogic 環境に統合する場合は、WebLogic Tuxedo Connector の使用を検討してください。スケーラビリティと信頼性の高い Tuxedo の CORBA 環境を有効に活用できます。
コネクタでは、XML コンフィグレーション ファイルを使用することで、WebLogic Server から Tuxedo サービスを呼び出すようにコンフィグレーションできます。また、サービス リクエストに応じて、Tuxedo から WebLogic Server エンタープライズ JavaBean (EJB) やその他のアプリケーションを呼び出すこともできます。
以下のマニュアルではそれぞれ、Weblogic Tuxedo Connector と、Tuxedo での CORBA アプリケーションの構築について説明しています。
WebLogic Server 製品には、WebLogic Tuxedo Connector IIOP のサンプル コードが用意されています。これらのサンプルは、SAMPLES_HOME\server\examples\src\examples\iiop\ejb ディレクトリにあります。各サンプルの説明と、サンプルをビルド、コンフィグレーション、実行する方法については、package-summary.html ファイルを参照してください。これらのコード サンプルは、変更して再利用できます。
WLS 8.1 では、RMI-IIOP ランタイムが拡張され、すべての CORBA オブジェクト タイプ (RMI 値タイプではなく) と CORBA スタブをサポートするようになりました。この拡張では次のような機能が提供されます。
以下の節では、CORBA API の使用方法について説明します。
この節では、発信呼び出し用に CORAB API を使用する顧客向けに、典型的な開発モデルを実装する方法について説明します。
この節では、WebLogic ORB にアクセスするいくつかのメカニズムの例を示します。これらのメカニズムは同じ効果を持つので、ある程度はそれらの構成要素を混ぜ合わせることができます。narrow() で返されるオブジェクトは、外部 ORB サービスを表す CORBA スタブであり、通常の CORBA 参照で呼び出せます。以下の各コード サンプルでは、CORBA インタフェースは MySvc、サービスは exthost:extport にある外部 ORB の CosNaming サービスの「where」でホストされるものとします。
.
.
.ORB orb = (ORB)new InitialContext().lookup("java:comp/ORB");
NamingContext nc = NamingContextHelper.narrow(orb.string_to_object("corbaloc:iiop:exthost:extport/NameService"));
MySvc svc = MySvcHelper.narrow( nc.resolve(new NameComponent[] { new NameComponent("where", "")}));
.
.
.
.
.
.
ORB orb = ORB.init();
MySvc svc = MySvcHelper.narrow(orb.string_to_object("corbaname:iiop:exthost:extport#where"));
.
.
.
.
.
.
MySvc svc = MySvcHelper.narrow(new InitialContext().lookup("corbaname:iiop:exthost:extport#where"));
.
.
.
WebLogic ORB では、DII (Dynamic Invocation Interface) を含むほとんどのクライアント ORB 機能がサポートされます。そのためには、外部 ORB をサーバ内でインスタンス化してはなりません。インスタンス化すると、WebLogic ORB による統合メリットを活かせなくなります。
WebLogic 8.1 では、サーバ内で ORB をホストする以外の方法として、着信 CORBA 呼び出しの基本サポートも提供されます。それには、ORB.connect() を使用して、WebLogic Server 内で CORBA サーバをパブリッシュします。この方法としては、CORBA インタフェースを実装する RMI オブジェクトを記述するのが最も簡単です。上記の MySVC サンプルを利用します。
.
.
.
class MySvcImpl implements MvSvcOperations, Remote
{
public void do_something_remote() {}
public static main() {
MySvc svc = new MySvcTie(this);
InitialContext ic = new InitialContext();
((ORB)ic.lookup("java:comp/ORB")).connect(svc);
ic.bind("where", svc);
}
}
.
.
.
起動クラスとして登録すると、CORBA サービスは、場所「where」にある WebLogic Server の CosNaming サービスで使用できるようになります。
CORBA オブジェクト タイプのサポートには以下の制約があります。
ORB.connect() によって作成された CORBA サービスは、サーバ内でホストされる別のオブジェクトとなる。オブジェクトが不要になった場合、ORB.disconnect() を使用して削除する必要があります。
RMI over IIOP を使用するエンタープライズ JavaBean を実装することで、異機種サーバ環境における以下のような EJB 相互運用性を実現することができます。
CORBA/IDL クライアントを使用する場合には、Java ソース ファイルに定義されている EJB クラスがマッピング情報の源になります。WebLogic Server には、必要な IDL ファイルを生成するための weblogic.appc ユーティリティが用意されています。これらのファイルは、CORBA ビューを、対象となる EJB の状態と動作で表します。weblogic.appc ユーティリティの用途は以下のとおりです。
weblogic.appc ユーティリティでは、さまざまなコマンド修飾子がサポートされています。「CORBA/IDL クライアントの開発手順」を参照してください。
結果として生成されたファイルはコンパイラで処理されます。コンパイラはその際に、idlSources ディレクトリからソース ファイルを読み込み、CORBA C++ のスタブ ファイルとスケルトン ファイルを生成します。値タイプ以外のすべての CORBA データ型に対しては、生成されるこれらのファイルで十分です (詳細については、「WebLogic RMI-IIOP の制約事項」を参照)。生成された IDL ファイルは、idlSources ディレクトリに配置されます。なお、Java-to-IDL マッピング処理には、さまざまな問題が潜んでいます。「Java 言語の OMG IDL へのマッピング」仕様を参照してください。また、Sun からも優れたガイド『Enterprise JavaBeansTM Components and CORBA Clients: A Developer Guide』が公開されています。
以下の例では、作成済みの Bean から IDL を生成する方法を示します。
> java weblogic.appc -compiler javac -keepgenerated
-idl -idlDirectory idlSources
build\std_ejb_iiop.jar
%APPLICATIONS%\ejb_iiop.jar
次に、以下のようにして、EJB インタフェースとクライアント アプリケーションをコンパイルします (この例では CLIENT_CLASSES および APPLICATIONS ターゲット変数を使用しています)。
> javac -d %CLIENT_CLASSES% Trader.java TraderHome.java
TradeResult.java Client.java
続いて、上記の手順で weblogic.appc を使用して作成した IDL ファイルに対して、以下のように IDL コンパイラを実行し、C++ のソース ファイルを作成します。
>%IDL2CPP% idlSources\examples\rmi_iiop\ejb\Trader.idl
.. .
>%IDL2CPP% idlSources\javax\ejb\RemoveException.idl
これで、C++ クライアントをコンパイルすることができます。
RMI-IIOP での EJB の使用方法の詳細については、WebLogic Server に付属している RMI-IIOP サンプルを参照してください。このサンプルは、インストール済み環境の SAMPLES_HOME/server/examples/src/examples/iiop ディレクトリに入っています。
WL_HOME/samples/examples/iiop ディレクトリに examples.iiop パッケージがあり、その中にさまざまなクライアントとアプリケーションとの接続方法を示すサンプルが用意されています。RMI-IIOP での EJB の使用、C++ クライアントへの接続、Tuxedo Server との相互運用性の設定などを扱ったサンプルが含まれています。詳細については、サンプルの説明を参照してください。特に WebLogic Tuxedo Connector に関するサンプルについては、/wlserver8.1/samples/examples/wtc ディレクトリを参照してください。
次の表に、WebLogic Server 8.1 用の RMI-IIOP サンプルについての情報をまとめます。
表 2-3 WebLogic Server 8.1 IIOP サンプル
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
次の表に、dev2dev コードライブラリで提供される WebLogic Server 8.1 用のその他の RMI-IIOP サンプルについての情報をまとめます。
表 2-4 WebLogic Server 8.1 IIOP dev2dev サンプル
|
|
||
|
|
||
|
|
|
|
|
|
||
WebLogic Server のデフォルト ガベージ コレクションは、未使用で参照されていないサーバ オブジェクトをガベージ コレクションの対象として削除します。これにより、多数の未使用オブジェクトによってメモリが不足するおそれが少なくなります。このガベージ コレクションのポリシーが原因で、クライアントにリモート オブジェクトへの参照が保持されているものの、約 6 分間そのオブジェクトを呼び出していない場合に、RMI-IIOP で NoSuchObjectException エラーが発生することがあります。このような例外は EJB に関しては発生せず、たとえば JNDI を介してサーバ インスタンスによって参照される RMI オブジェクトに関しても通常は発生しません。
RMI-IIOP に関する J2SE 仕様では、javax.rmi.PortableRemoteObject の exportObject() および unexportObject() メソッドを使用して、DGC (Distributed Garbage Collection) ではなく、RMI-IIOP 環境で RMI オブジェクトのライフサイクルを管理することが求められています。ただし、exportObject() および unexportObject() は WebLogic Server のデフォルトのガベージ コレクション方法にはまったく影響しません。デフォルト ガベージ コレクション方法を変更する場合は、BEA テクニカルサポートに連絡してください。
|
|
|