| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic RMI over IIOP プログラマーズ ガイド > RMI over IIOP プログラミング モデル |
|
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 を採用するためのモデルにはさまざまなものがあり、それらが提供する機能や標準の多くが共通しているので、どのモデルに従えばよいか見通しが立てにくいのが現状です。そこで、各モデルのコンポーネントとメリットを以下の表にまとめてみました。ここでは、利用可能なプログラミング モデル間の相違点をはっきりさせるために、IIOP を使用しない単純な RMI モデルも一緒に示してあります。
RMI は、分散コンピューティングの Java-to-Java モデルです。RMI を使用すると、ネットワーク内の別の場所に存在するオブジェクトへの参照をアプリケーション側で取得することができます。RMI-IIOP モデルはすべて RMI に基づいていますが、IIOP を使用しない基本的な RMI モデルに従う場合には、Java 以外の言語で記述されたクライアントを統合することはできません。また、独自プロトコルである T3 を使用して、クライアント側に WebLogic クラスを用意することもあります。 RMI アプリケーションの開発については、『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI の実装」を参照してください。
RMI (Java) クライアント使用型 RMI-IIOP アプリケーション
RMI クライアントを使用した RMI over IIOP (RMI クライアント使用型 RMI over IIOP) では、RMI の機能と標準 IIOP プロトコルが一体化されており、完全に Java プログラミング言語だけで作業できるようになっています。RMI クライアント使用型 RMI-IIOP は Java-to-Java モデルであり、その場合 ORB は通常、クライアントで動作する JDK の一部となっています。RMI-IIOP では、オブジェクトは参照としても値としても渡すことができます。
RMI (Java) クライアント使用型 RMI-IIOP を適用すべき状況
RMI クライアント使用型 RMI-IIOP は 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 なのです。
RMI クライアント使用型 RMI-IIOP アプリケーションの開発
RMI クライアント使用型 RMI-IIOP を用いてアプリケーションを開発するには、以下の手順に従います。
このリモート インタフェースには、コードをあまり記述する必要がない場合もあります。必要なのは、リモート クラスで実装するメソッドに対するメソッド シグネチャだけです。たとえば、インストール済み WebLogic Server の SAMPLES_HOME/server/src/examples/iiop/rmi/server/wls に格納されている Ping サンプルを以下に示します。
public interface Pinger extends java.rmi.Remote {
public void ping() throws java.rmi.RemoteException;
public void pingRemote() throws java.rmi.RemoteException;
public void pingCallback(Pinger toPing) throws java.rmi.RemoteException;
}
このクラスには、記述済みのリモート インタフェースを実装する必要があります。これは、インタフェースに含まれるメソッド シグネチャを実装したことを意味します。すべてのコード生成はこのクラスファイルに依存します。通常は、実装クラスを 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);
$ java weblogic.rmic nameOfImplementationClass
Pinger サンプルの場合には、nameOfImplementationClass の部分が examples.iiop.rmi.server.wls.PingerImpl になります。
スタブはリモート オブジェクト用のクライアントサイド プロキシで、個々の WebLogic RMI 呼び出しを対応するサーバサイド スケルトンに転送します。今度は、サーバサイド スケルトンが、その呼び出しを実際のリモート オブジェクト実装に転送します。なお、WebLogic RMI コンパイラで作成される IIOP スタブは、JDK 1.3.1_01 以降の ORB で使用するためのものである点に注意してください。他の ORB を使用する場合、それぞれの ORB ベンダのマニュアルを参照して、これらのスタブが適切かどうかを判断してください。
RMI クライアントは、初期コンテキストを作成しオブジェクトをルックアップする (次のステップを参照) ことで、リモート オブジェクトにアクセスします。次に、このオブジェクトは適切な型にキャストされます。
パラメータとして新しい InitialContext() に渡す「Context.INITIAL_CONTEXT_FACTORY」プロパティの値を設定する際には、これらのクラスのいずれかを使用します。Sun バージョンを使用している場合は、Sun JNDI クライアント、つまり J2SE 1.3 の Sun RMI-IIOP ORB 実装を使用することになります。このことは、クライアントでの WebLogic クラスの使用を最小限に抑える場合には重要です。ただし、WebLogic の RMI-IIOP 実装を十分に活用するには、weblogic.jndi.WLInitialContextFactory メソッドを使用することをお勧めします。
Sun JNDI クライアントおよび Sun ORB を使用する場合には、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 ファイルがアプリケーションのクラスパス
* に存在するかどうかに依存する。
* 詳細については、
* http://edocs.beasys.co.jp/e-docs/wls/docs70/jndi/jndi.html
* を参照のこと
private static Context getInitialContext()
throws NamingException
{
return new InitialContext();
}
RMI over IIOP RMI クライアントが通常の RMI クライアントと異なるのは、初期コンテキストを取得する際にプロトコルとして IIOP が定義されるという点です。このため、ルックアップとキャストは、javax.rmi.PortableRemoteObject.narrow() メソッドと組み合わせて行われます。
たとえば、RMI クライアントのステートレス セッション Bean サンプル (配布キットに付属している examples.iiop.ejb.stateless.rmiclient パッケージ) では、RMI クライアントは初期コンテキストを作成し、EJBean ホームをルックアップし、EJBean への参照を取得し、そしてその EJBean のメソッドを呼び出します。
通常ならオブジェクトを特定のクラス タイプへキャストするような状況ではすべて、javax.rmi.PortableRemoteObject.narrow() メソッドを使用する必要があります。CORBA クライアントからは、リモート インタフェースを実装しないオブジェクトが返される可能性があります。そこで、リモート インタフェースを実装するようにオブジェクトを変換するために ORB から narrow メソッドが提供されるのです。たとえば、EJBean ホームのルックアップとその 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 ファイルの例を以下に示します。
WebLogic RMI-IIOP RMI クライアント使用型 RMI-IIOP アプリケーション
WebLogic Server 7.0 では、完全にクラスタ化可能な RMI-IIOP アプリケーションを開発できる、「ファット」RMI-IIOP RMI クライアントを使用できます。この新しい WebLogic RMI-IIOP RMI クライアントを使用するには、クライアント サイドの CLASSPATH にweblogic.jar (WL_HOME/server/lib にある) を含め、-D weblogic.system.iiop.enableClient=true コマンド ライン オプションを使用して WebLogic を起動する必要があります。 この操作を行わない場合は、このクライアントの開発手順は、「RMI (Java) クライアント使用型 RMI-IIOP アプリケーション」で説明した手順と同じになります。
CORBA/IDL クライアント使用型 RMI-IIOP アプリケーション
CORBA/IDL クライアントを使用した RMI over IIOP (CORBA/IDL クライアント使用型 RMI over IIOP) には、ORB (Object Request Broker) と共に、IDL と呼ばれる相互運用のための言語を作成するコンパイラが必要になります。C、C++、COBOL などは、ORB で IDL にコンパイル可能な言語の例です。CORBA のプログラマは、CORBA オブジェクトの定義、実装、および Java プログラミング言語からのアクセスに、CORBA インタフェース定義言語 (IDL : Interface Definition Language) のインタフェースを使用できます。
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-IIOP アプリケーションの開発
CORBA/IDL を使用した RMI over IIOP アプリケーションを開発するには、以下の手順に従います。
IDL ファイルをコンパイルすると、必要なスタブ クラスが生成されます。 これらのコンパイラに関する一般的な情報については、「WebLogic RMI の実装」と『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』を参照してください。 さらに、Java IDL 仕様については、Java Language Mapping to OMG IDL 仕様を参照してください。
以下のコンパイラ オプションは、RMI over IIOP に固有のものです。
オプションの適用例を、次の RMI コンパイラの実行例で示します。
> java weblogic.rmic -idl -idlDirectory /IDL rmi_iiop.HelloImpl
コンパイラは、実装クラスのパッケージに従って、IDL ファイルを、idlDirectoy のサブディレクトリ内に生成します。たとえば、上記のコマンドの場合には、Hello.idl ファイルが /IDL/rmi_iiop ディレクトリに生成されます。idlDirectory オプションが使用されない場合には、IDL ファイルは、スタブ クラスやスケルトン クラスの生成先からの相対パスに生成されます。
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 ネーム サービスから提供されるものは以下のとおりです。
Tuxedo 8.1 ORB 用 WebLogic C++ クライアントの開発
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 ダウンロード センターから入手できます。
WebLogic C++ クライアントは、次のモデルを使用してクライアント リクエストを処理します。
図2-3 WebLogic C++ クライアントと WebLogic Server の相互運用性
WebLogic C++ クライアントには、以下の制限があります。
WebLogic Server 製品では、WebLogic C++ クライアントのサンプルが提供されます。 そのサンプルは、SAMPLES_HOME¥server¥examples¥src¥examples¥iiop¥ejb ディレクトリにあります。 各サンプルの説明と、ビルド、コンフィグレーション、および実行の手順については、package-summary.html を参照してください。 コード例は、修正して再利用できます。
WebLogic Tuxedo Connector を使用した RMI-IIOP アプリケーション
WebLogic Tuxedo Connector を使用すると、WebLogic Server アプリケーションと Tuxedo サービスの相互運用が実現されます。
いつ WebLogic Tuxedo Connector を使用するのか
Tuxedo でアプリケーションを開発して WebLogic Server に移行する場合、または旧来の Tuxedo システムを新しい WebLogic 環境に統合しようとしている場合には、WebLogic Tuxedo Connector の使用を検討してください。 WebLogic Tuxedo Connector を使用すると、Tuxedo の拡張性と信頼性が高い CORBA 環境を利用することができます。
WebLogic Tuxedo Connector の仕組み
コネクタでは、XML コンフィグレーション ファイルを使用して、WebLogic Server からの Tuxedo サービスの呼び出しを可能にしています。 また、サービス要求に応じて、Tuxedo から WebLogic Server エンタープライズ JavaBean（EJB）やその他のアプリケーションを呼び出すこともできます。
以下のマニュアルではそれぞれ、Weblogic Tuxedo Connector と、Tuxedo での CORBA アプリケーションの構築について説明しています。
WebLogic Tuxedo Connector のコード サンプル
WebLogic Server 製品では、WebLogic Tuxedo Connector IIOP のサンプルが提供されます。 そのサンプルは、SAMPLES_HOME¥server¥examples¥src¥examples¥iiop¥ejb ディレクトリにあります。 各サンプルの説明と、ビルド、コンフィグレーション、および実行の手順については、package-summary.html を参照してください。 コード例は、修正して再利用できます。
RMI over IIOP を使用するエンタープライズ JavaBean を実装することで、異機種サーバ環境における以下のような EJB 相互運用性を実現することができます。
CORBA/IDL クライアントを使用する場合には、Java ソース ファイルに定義されている EJB クラスがマッピング情報の源になります。WebLogic Server には、必要な IDL ファイルを生成するための weblogic.ejbc ユーティリティが用意されています。これらのファイルは、CORBA ビューを、対象となる EJB の状態と動作で表します。weblogic.ejbc ユーティリティの用途は以下のとおりです。
weblogic.ejbc ユーティリティでは、さまざまなコマンド修飾子がサポートされています。 「CORBA/IDL クライアント使用型 RMI-IIOP アプリケーションの開発」を参照してください。
結果として生成されたファイルはコンパイラで処理されます。コンパイラはその際に、idlSources ディレクトリからソース ファイルを読み込み、CORBA C++ のスタブ ファイルとスケルトン ファイルを生成します。 値タイプ以外のすべての CORBA データ型に対しては、生成されるこれらのファイルで十分です (詳細については、「WebLogic RMI-IIOP の制約事項」を参照してください)。 生成された IDL ファイルは、idlSources ディレクトリに配置されます。なお、Java-to-IDL マッピング処理には、さまざまな問題が潜んでいます。 詳細については、Java Language Mapping to OMG IDL 仕様を参照してください。 また、Sun からも優れたガイド『Enterprise JavaBeansTM Components and CORBA Clients: A Developer Guide』が公開されています。
以下の例では、作成済みの Bean から IDL を生成する方法を示します。
> java weblogic.ejbc -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.ejbc を使用して作成した 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/src/examples/iiop ディレクトリに入っています。
examples.iiop パッケージは、数多くのクライアントとアプリケーションとの接続を示したもので、WL_HOME/samples/examples/iiop ディレクトリにあります。 EJB を RMI-IIOP で使用し、C++ クライアントに接続して Tuxedo サーバとの相互運用性を設定する例も用意されています。 詳細については、サンプルの説明を参照してください。 特に WebLogic Tuxedo Connector に関するサンプルについては、/wlserver7.0/samples/examples/wtc ディレクトリを参照してください。
次の表に、WebLogic Server 7.0 で提供される RMI-IIOP のサンプルに関する情報を示します。
図2-4 WebLogic Server 7.0 の IIOP サンプル
|
複雑な valuetype を使用して WebLogic Server のエンティティ セッション Bean を呼び出す Tuxedo クライアントを提供する。 |
||
|
WebLogic Server のステートレス セッション Bean を呼び出す C++ CORBA クライアントを提供する。 また、WebLogic Tuxedo Connector を使用して Tuxedo サーバへの送信 RMI-IIOP 呼び出しを行う方法も例示する。 |
||
|
WebLogic Server のステートレス セッション Bean を呼び出す RMI Java クライアントを提供する。 また、WebLogic Tuxedo Connector を使用して Tuxedo サーバへの送信 RMI-IIOP 呼び出しを行う方法も例示する。 |
||
|
Tuxedo サーバを通じてさまざまなクライアント アプリケーションからステートレス セッション Bean を呼び出す方法を示す。 Tuxedo クライアントとの連携で、WebLogic Tuxedo Connector を使用したサーバ間の接続も例示する。 |
|
|
|
さまざまなクライアントを使用して、WebLogic Server で直接、または Tuxedo サーバを通じて間接的にステートレス EJB を呼び出す方法を例示する。 |
||
|
WebLogic Server で直接ステートレス セッション Bean を呼び出すか、Tuxedo サーバを通じて WebLogic の同じステートレス セッション Bean を呼び出す Tuxedo クライアントを提供する。 また、WebLogic Tuxedo Connector を使用して Tuxedo サーバから WebLogic Server への送信 RMI-IIOP 呼び出しを行う方法も例示する。 |
||
|
Tuxedo サーバまたは WebLogic Server のいずれかを呼び出す C++ クライアントを提供する。 WebLogic Tuxedo Connector を使用したサーバ間接続も例示します。 |
||
|
WebLogic Server との接続を例示する RMI クライアントを提供する。 また、WebLogic Tuxedo Connector を使用して WebLogic Server から Tuxedo サーバへの送信呼び出しを行う方法も例示する。 |
||
|
Tuxedo サーバを介したさまざまなクライアント アプリケーションからの接続を例示する。 Tuxedo クライアントとの連携で、WebLogic Tuxedo Connector を使用したサーバ間の接続も例示する。 |
|
|
|
単純な Ping アプリケーションを使用したさまざまなクライアント、Tuxedo、および WebLogic Server 間の接続を例示する。 |
||
WebLogic Server のデフォルト ガベージ コレクションによって、未使用および未参照のサーバ オブジェクトのガベージ コレクションが行われます。 これにより、多数の未使用オブジェクトを実行することが原因でメモリが不足するおそれが小さくなります。 このポリシーでは、クライアントがリモート オブジェクトへの参照を保持しているものの、そのオブジェクトを約 6 分間呼び出してしない場合に、RMI-IIOP で NoSuchObjectException エラーが発生することがあります。 こうした例外は EJB、つまり JNDI などを経由してサーバ インスタンスによって参照される RMI オブジェクトの場合には発生しません。
RMI-IIOP の J2SE 仕様では、分散ガベージ コレクション (DGC) ではなく、javax.rmi.PortableRemoteObject に対して exportObject() および unexportObject() メソッドを使用して、RMI-IIOP 環境で RMI オブジェクトのライフサイクルを管理することを求めています。 ただし、exportObject() および unexportObject() は、WebLogic Server のデフォルト ガベージ コレクション ポリシーには影響はありません。 デフォルトのガベージ コレクション ポリシーを変更する場合は、BEA テクニカル サポートにお問い合わせください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
