スタンドアロン クライアント プログラマーズ ガイド
|
 |
 |
|
以下の節では、さまざまなプログラミング モデルを用いた 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 クライアントについても取り上げます。
表 3-1 WebLogic Server クライアントの種類と機能
|
|
|||||
WebLogic Server では、J2SE 1.4 に付属する ORB の代わりに、独自の ORB 実装が用意されています。この ORB は、プログラムで ORB.init() が呼び出されたとき、または JNDI で "java:comp/ORB" が参照されたときにデフォルトでインスタンス化されます。
デフォルトの 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 アプリケーションの開発については、「Understanding 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 に直接アクセスし、必要に応じて Web 層で実行されているサーブレットと HTTP を介して通信します。一般に、アプリケーション クライアントはサーバからダウンロードされますが、クライアント マシン上にインストールすることもできます。
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 のサポートも必要とします。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 認証の実装方法の詳細については、「Using JAAS Authentication in Java Clients」を参照してください。
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 の実装方法の詳細については、「Configuring RMI over IIOP with SSL」を参照してください。
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 クライアントの開発」で説明した手順と同じです。
注意 : クライアントの起動時に-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 と呼ばれる相互運用のための言語を作成するコンパイラが必要になります。ORB で IDL にコンパイル可能な言語の例としては、C、C++、COBOL などがあります。CORBA のプログラマは、CORBA インタフェース定義言語 (Interface Definition Language : IDL) のインタフェースを使用して、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 コードを作成することもできますが、その方法は難しく、バグも多数発生するのでお勧めしません。
IDL と RMI-IIOP モデルの関係を以下の図に示します。
図 3-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 サービスが実装されています。
図 3-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 の詳細については、『WebLogic RMI プログラマーズ ガイド』の「Limitations of Passing Objects by Value」を参照してください。
CORBA/IDL を使用した RMI over IIOP アプリケーションを開発するには、以下の手順に従います。
IDL ファイルをコンパイルすると、必要なスタブ クラスが生成されます。これらのコンパイラの概要については、「Understanding WebLogic RMI」および「Programming WebLogic Enterprise JavaBeans」を参照してください。また、「Java Language Mapping to OMG IDL Specification」で Java 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 Download Center」から入手できます。
WebLogic C++ クライアントは、次のモデルに基づいてクライアント リクエストを処理します。
図 3-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 の使用を検討します。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 ファイルを参照してください。これらのコード例は、変更して再利用できます。
WebLogic Server リリース 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 Server では、サーバ内で 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 プログラマーズ ガイド』の「Limitations of WebLogic RMI over 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
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 9.0 用の RMI-IIOP サンプルについての情報をまとめます。
表 3-3 WebLogic Server 9.0 IIOP サンプル
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
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 テクニカルサポートにお問い合わせください。
|
|
|