| Oracle® Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントの開発 12c (12.2.1.2.0) E82877-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
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)による以下の仕様を参照してください。
Java-to-IDL言語マッピング仕様(http://www.omg.org/cgi-bin/doc?formal/01-06-07)
CORBA/IIOP 2.4.2仕様(http://www.omg.org/cgi-bin/doc?formal/01-02-33)
CORBAでは、リモート・オブジェクトへのインタフェースは、プラットフォームに依存しないインタフェース定義言語(IDL)で記述されます。IDLを特定の言語にマップするには、IDLコンパイラでIDLをコンパイルします。IDLコンパイラによって、スタブやスケルトンといった多くのクラスが生成されます。これらのクラスは、クライアントやサーバーで、リモート・オブジェクトへの参照の取得、リクエストの転送、および受信した呼出しのマーシャリングに使用されます。IDLクライアントを使用する場合でも、以降の各節で示すように、まずJavaリモート・インタフェースおよび実装クラスの作成からプログラミングを始めて、その後でIDLを生成し、WebLogicクライアントおよびCORBAクライアントとの相互運用性を実現することを強くお薦めします。IDLでコードを記述した後で、その逆マッピングによってJavaコードを作成することもできますが、その方法は難しく、バグも多数発生するのでお薦めしません。
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サービスが実装されています。
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のサポート状況に関してOracleで検証したORBとその結果を以下の一覧表に示します。
表10-1 Objects-by-ValueサポートについてテストされたORB
| ベンダー | バージョン | Objects-by-Value |
|---|---|---|
Oracle |
Tuxedo 8.x C++クライアントORB |
サポートされます |
Borland |
VisiBroker 3.3、3.4 |
サポートされません |
Borland |
VisiBroker 4.x、5.x |
サポートされます |
Iona |
Orbix 2000 |
サポートされます(Oracleは、この実装での問題をいくつか発見しました) |
Objects-by-Valueの詳細は、Oracle WebLogic Server RMIアプリケーションの開発のオブジェクトの値渡しの制限に関する項を参照してください。
CORBA/IDLを使用したRMI over IIOPアプリケーションを開発するには:
「Java SEクライアントの開発」のステップ1 - 3を実行します。
-idlオプションを使用してWebLogic RMIコンパイラまたはWebLogic EJBコンパイラを実行し、IDLファイルを生成します。
IDLファイルをコンパイルすると、必要なスタブ・クラスが生成されます。これらのコンパイラについては、『Oracle WebLogic Server RMIアプリケーションの開発』およびWebLogic RMIの理解に関する項を参照してください。また、「Java Language Mapping to OMG IDL Specification」(http://www.omg.org/technology/documents/index.htm)のJava IDL仕様も参照してください。
以下のコンパイラ・オプションは、RMI over IIOPに固有のものです。
表10-2 RMI-IIOPコンパイラ・オプション
| オプション | 機能 |
|---|---|
|
コンパイルされている実装クラスのリモート・インタフェース用のIDLを作成します。 |
|
生成されたIDLの保存先ディレクトリを指定します。 |
|
値タイプのファクトリ・メソッドを生成します。クライアントORBでファクトリの値タイプがサポートされていない場合に役立ちます。 |
|
値タイプに応じたIDLが生成されないようにします。 |
|
同名のIDLファイルが存在する場合には、コンパイラにより上書きされます。 |
|
Objects-By-Value仕様に厳密に準拠したIDLを生成します(appcでは使用できません)。 |
|
IDL生成についての詳細な情報を表示します。 |
|
VisiBroker 4.1 C++とある程度の互換性があるIDLを生成します。 |
オプションの適用例を、次のRMIコンパイラの実行例で示します。
> java weblogic.rmic -idl -idlDirectory /IDL rmi_iiop.HelloImpl
このコンパイラでは、実装クラスのパッケージに従って、IDLファイルを、idlDirectoyのサブディレクトリ内に生成します。たとえば、上記のコマンドの場合には、Hello.idlファイルが/IDL/rmi_iiopディレクトリに生成されます。idlDirectoryオプションが使用されない場合には、IDLファイルは、スタブ・クラスやスケルトン・クラスの生成先からの相対パスに生成されます。
IDLファイルをコンパイルして、IDLクライアントでリモート・クラスと通信するのに必要なスタブ・クラスを作成します。IDLコンパイラはORBベンダーにより提供されています。
WebLogicコンパイラで生成されたIDLファイルには、#include orb.idlディレクティブが含まれています。このIDLファイルは各ORBベンダーから提供されます。orb.idlファイルは、WebLogic配布キットの\libディレクトリにあります。このファイルは、JDKに含まれているORBで使用するためのみに用意されているものです。
IDLクライアントを開発します。
IDLクライアントは、純粋なCORBAクライアントで、WebLogicクラスはまったく必要としません。ORBベンダーによっては、リモート・クラスへの参照を解決し、ナロー変換して、取得するためのクラス群が生成されることもあります。以下のVisiBroker 4.1 ORB向けに開発されたクライアントの例では、クライアントでネーミング・コンテキストが初期化され、リモート・オブジェクトへの参照が取得されて、そのリモート・オブジェクトに対するメソッドが呼び出されます。
RMI-IIOPサンプルのC++クライアントからの抜粋コード
// string to object
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");
// obtain a naming context
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("");
// resolve and narrow to RMI object
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 it
cout << "Ping (local) ..." << endl;
ping->ping();
}
ネーミング・コンテキストを取得する前に、標準のオブジェクトURL (CORBA/IIOP 2.4.2仕様の13.6.7節を参照)を使用して初期参照が解決されている点に注意します。サーバーでのルックアップが、COSネーミング・サービスAPIを実装するJNDIのラッパーによって解決されています。
このネーミング・サービスにより、WebLogic Serverアプリケーションで論理名を使ってオブジェクト参照が公開できるようになっています。CORBAネーム・サービスから提供されるものは以下のとおりです。
Object Management Group (OMG)のInteroperable Name Service (INS)仕様の実装
オブジェクト参照を階層型ネーミング構造(この場合はJNDI)にマップするためのアプリケーション・プログラミング・インタフェース(API)
バインドを表示したり、ネーミング・コンテキスト・オブジェクトやアプリケーション・オブジェクトをネームスペースにバインドまたはアンバインドしたりするためのコマンド
IDLクライアント・アプリケーションでは、WebLogic ServerのJNDIツリー内の名前をルックアップするようにCORBAネーミング・サービスに依頼することで、オブジェクトを見つけられます。上記の例では、以下のコマンドを使ってクライアントを実行します。
Client.exe -ORBInitRef NameService=iioploc://localhost:7001/NameService
