|
|
このドキュメントは Java TM IDL テクノロジの使用に関する質問にお答えするためのものです。 このドキュメントは、届いた質問をもとに今後も更新していきます。 探している質問の答えがこのドキュメントに見つからない場合は、ユーザによって支援されている Java IDL テクノロジのフォーラムを参照してください。フォーラムは、http://forum.java.sun.com で参照できます。 コメントは、電子メールで javaidl@sun.com にお送りください。
使用している JDK ORB クライアントが、ORBIX サーバと通信できるかどうかをテストする方法を教えてください。
CORBA クライアントと Java サーバアプリケーションの使用例は提供されていますか。
多くの場合、Java IDL チュートリアルの HelloServer (HelloClient の場合も同様) を実行すると、このエラーが発生するのは、HelloServer がクラスパスに含まれていないためです。 クラスパス変数の設定方法の詳細は、「クラスパスの設定」を参照してください。2 番目に多い原因は、次のコード行の引用符と引用符の間に空白が追加されていることです。
NameComponent nc = new NameComponent("Hello", "");引用符の間には空白を入れないでください。 空白がなければ、この値は Null として渡されます。 引用符の間に空白があると、空白文字が渡されます。
idlj コンパイラは、POA 継承モデルに基づくサーバ側マッピングを生成します。 既存のアプリケーションとの互換性を保つため、idlj コンパイラに新しいフラグ -oldImplBase を追加して、ImplBase 継承モデルに基づくサーバ側マッピングを作成することができます。 J2SE バージョン 1.3 以前で作成したサーバと接続する必要がある既存のアプリケーションは、MAKEFILE を更新してこのフラグが利用できるようにする必要があります。ただし、そのような要求がない新規アプリケーションではこうしたマッピングは作成しないことをお勧めします。
Red Hat Linux をインストールした場合、InetAddress.getLocalHost() が、ループバックアドレス (127.0.0.1) に対応する InetAddress を返すことがあります。 この問題が発生するのは、デフォルトのインストールによって、マシンのホスト名とループバックアドレスとの関連付けが /etc/hosts 内に作成されるためです。 InetAddress.getLocalHost() によって確実に実際のホストアドレスが返されるようにするには、/etc/hosts ファイルまたはネームサービスの構成ファイル (/etc/nsswitch.conf) を更新して、ホストを検索する前に、dns または nis に問い合わせるようにします。
J2SE に同梱されている Java CORBA ORB はマルチスレッド化されています。 サーバ側に用意されているスレッド プールでは、各着信要求が独立したスレッドによって処理されます。 プールのスレッドがすべて使用中のときに新しいリクエストを受け取ると、新しいスレッドが作成されてプールに追加されます。 このスレッドは、要求が完了すると、プールに戻されます。
Java CORBA ORB は、スケーラビリティとリクエストの同時処理を実現するために、スレッド化されています。 POA スレッドポリシー用の SINGLE_THREAD オプションはサポートされていません。
Java CORBA ORB のスレッドモデルは次のように暗黙的です。 すなわち、ユーザは、ORB のスレッドポリシーを設定しません。 また、スレッドモデルやスレッド数を制御するための、公開された外部のユーザレベル API はありません。
いいえ、ありません。 イベントサービスが必要な場合は、実装したり、既製品を購入したり、自由に利用できるイベントサービスを検索したりしてください。
いいえ、ありません。 インタフェースリポジトリが必要な場合は、実装したり、既製品を購入したり、自由に利用できるインタフェースリポジトリを検索したりしてください。
ネームサーバと同一のマシン上で実行されていないクライアントやサーバを起動する場合、-ORBInitialHost <ネームサービスが起動されるホストの名前> オプションを使います。 こうすると、クライアントとサーバはネームサービスの場所を知ることができます。 Web サイト http://java.sun.com/j2se/1.4/ja/docs/ja/guide/idl/tutorial/jidl2machines.html に例があるので参照してください。
J2SE 1.3 の idlj コンパイラを使うと CORBA 2.3 に準拠しますが、全部ではありません。 J2SE 1.4 では、CORBA 2.3 に準拠する部分が増加しています。 CORBA への準拠については、http://java.sun.com/j2se/1 .4/docs/api/org/omg/CORBA/doc-files/compliance.html を参照してください。RMI-IIOP も大部分は CORBA/IIOP 2.3.1 に準拠しており、CORBA 2.3 への準拠と似た方法で GIOP 1.2 をサポートしています。
アプリケーション内で、Java CORBA ORB 以外の ORB を使用するには、org.omg.CORBA.ORBClass プロパティを、選択した ORB に設定します。 たとえば、明示的に ORB を POA ORB に設定するには、コード内で次のようにプロパティを設定します。
public class MyApp { public static void main(String args[]) { Properties properties = System.getProperties( ); properties.put( "org.omg.CORBA.ORBClass", "com.sun.corba.se.internal.POA.POAORB"); try { ORB orb = ORB.init( args, properties ); ...POA ORB へのパスは、使用する ORB のパスに置き換えてください。
Java ORB とほかのベンダーの ORB との相互運用性についてはまだテストされていません。
ほかのベンダー製の ORB と JDK ORB との互換性については、まだテストされていません。
次の方法を試してください。 ORB.object_to_string() メソッドを使用して、ORBIX サーバ上の Interoperable Object References (INS チュートリアルの IOR に関する説明を参照) を文字列に変換します。 その文字列をファイルに書き込みます。
クライアント側で、ORB.string_to_object() メソッドを使用して、その文字列をオブジェクト参照に変換し、そのオブジェクト参照を使用して通信してみます。
Java IDL ネームサービスまたはORBIX ネームサーバと通信するには、Interoperable Naming Service (INS) を使用するか、または前に説明したように、RootNamingContext の参照を文字列化する必要があります。
C++ クライアントと Enterprise JavaBeans コンポーネントを使用したサンプルアプリケーションを含むホワイトペーパーが Web サイト http://java.sun.com/j2se/1.4/docs/guide/rmi-iiop/interop.pdf (英語版) に用意されています。
サードパーティ製のネームサービスが、Interoperable Naming Service (INS) をサポートしている場合は、INS オプションを使用する方法をお勧めします。Sun ORB をほかのベンダーのネームサービスとともに使用するには
- ホストおよびポート上でサードパーティ製のネームサービスを起動します。
- 次の引数を ORB.init() に渡します。
-ORBInitRef NameService=corbaloc:iiop:1.2@: /NameService
orb.resolve_initial_references( "NameService" ) を実行すると、サードパーティ製のネームサービスに接続できるようになります。 接続できない場合は、以下のトラブルシューティングに関するヒントを試してください。
- サードパーティ製のネームサービスが INS をサポートしていることを確認する
- ホストとポートの情報が正しいことを確認する
- サードパーティ製のネームサービスが正しく起動されていることを確認する
- サードパーティ製のネームサービスが GIOP 1.2 をサポートしていることを確認する。サポートしていない場合は、ネームサーバのドキュメントを参照して、適切な GIOP のバージョンを確認し、そのバージョンに合わせて corbaloc: URL を修正する
- サードパーティ製のネームサービスが異なるオブジェクトキーを使用して NameService と通信しているかどうかを調べる。 その場合は、ネームサーバのドキュメントを参照する
Java IDL ORB は完全に Java テクノロジを使用して記述された ORB です。 idlj コンパイラは、「IIDL to Java 言語マッピング仕様」で定義された規約に従うコードを生成します。 Java ORB は、Java プラットフォーム以外の言語でコードを生成するコンパイラを提供しません。 Java ORB とそれ以外の言語 (C++ など) で記述した ORB との相互運用性をテストする場合、その言語で記述した ORB とその言語マッピングに一致するコンパイラを探す必要があります。 言語マッピング仕様は、Object Management Group の Web サイト http://www.omg.org/technology/documents/formal/corba_language_mapping_specs.htm で入手できます。 一方で Java プラットフォームを使用し、もう一方で C++ を使用するには、IDL を共有するだけで十分です。 C++ ORB のツールを使って C++ ORB で使用するスタブとスケルトンを生成する必要がありますが、IDL は変更する必要がありません。 CORBA ORB と、使用する言語の言語マッピングコンパイラを提供するベンダーは、「C++ CORBA ORB」などのキーワードで Web を検索します。C++ クライアントと Enterprise JavaBeans コンポーネントを使用したサンプルアプリケーションを含むホワイトペーパーが Web サイト http://java.sun.com/j2se/1.4/ja/docs/ja/guide/rmi-iiop/interop.html に用意されています。
異なる言語で書かれた ORB 間での通信が可能なはずですが、Java ORB とほかのベンダーの ORB との相互運用性はまだテストされていません。
すべての新規コードに対して、IDL-to-Java コンパイラ idlj の最新バージョンを使用することを強くお勧めします。 従来のアプリケーションのために idltojava を使用する必要がある場合は、JDK 1.2 の idltojava コンパイラを、http://developer.java.sun.com/developer/earlyAccess/jdk12/idltojava.html でダウンロードできます。最新バージョンの IDL-to-Java コンパイラを入手するには、最新バージョンの Java TM 2 Platform, Standard Edition (J2SE TM) をダウンロードしてください。 J2SE をインストールすると、idlj は bin ディレクトリに格納されます。
J2SE v1.3 の idltojava に関するその他のトラブルシューティング情報については、「Java IDL FAQ」を参照してください。
Java 2 プラットフォームの一部である CORBA 技術は、Java 言語で書かれた Object Request Broker (ORB) (一部はネイティブコードで書かれている)、RMI プログラミングモデル、および IDL プログラミングモデルで構成されています。
異なる言語間、異なるベンダー間の相互運用性は Internet InterORB Protocol (IIOP) という「魔法」を使って実現されました。 IIOP は IDL または Java RMI のどちらかで書かれた分散アプリケーション用の伝送プロトコルにすることができます。 IIOP を使えば、分散オブジェクトを OMG の CORBA 仕様に適合させることができます。
IDL プログラミングを使う場合は、インタフェースがすべてです。 IDL では、リモートアクセスから呼び出ことができるエントリポイント (呼び出された手続きが受け入れる引数の型など) や、返された情報の値や出力パラメータなどを定義します。 IDL を使うと、プログラマは通信プロセス間を移動するエントリポイントやデータ型を標準言語であるかのように扱うことができます。
CORBA は言語から中立のシステムで、引数の値や戻り値は使用する実装言語で表すことができるものに制限されます。 CORBA では、オブジェクトの方向は参照用に渡すことができるオブジェクトに制限されるか、または全体のフレームワークであらかじめ定義されています。オブジェクトコード自体をマシン間で渡すことができません。 渡す型も戻す型もインタフェースで宣言されている必要があります。
RMI では、IDL と実装言語は同一のものであり、お互いをマッピングするための心配はありません。 言語レベルのオブジェクト (コード) をあるプロセスから次のプロセスに渡すことができます。 値は、宣言された型ではなく実際の型で返されます。 または、インタフェースをコンパイルして IIOP 対応のスタブとスケルトンを生成し、ほかの CORBA 対応言語で書かれている別のマシンのオブジェクトと通信することができます。
これは基本的な問題であり、Java プログラミング言語と CORBA を統合する 2 つの方式の違いを理解することが重要です。
Java IDL は、CORBA インタフェース定義言語 (IDL) で定義されたインタフェースに基づいて Java プログラミング言語でプログラムを記述したい CORBA プログラマ向けです。 これは「通常どおりの」CORBA プログラミングで、C++ や COBOL のようなほかの言語とまったく同じ方法で Java 言語をサポートしています。
RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) は、IIOP を背後のトランスポートとして使用し、Java プログラミング言語を使用して Java RMI インタフェースをプログラミングしたい、Java プログラマ向けです。 RMI-IIOP はさまざまな言語で実装される CORBA オブジェクトとの相互運用性を提供しますが、リモートインタフェースをあらかじめ Java RMI インタフェースとして定義しておく必要があります。 EJB のリモートオブジェクトモデルは RMI ベースなので、Enterprise JavaBeans (EJB) を使うプログラマには特に重要です。
分散型 CORBA アプリケーションの作成にはいくつかの定義方法があります。 以下に一般的な方法を示します。
Java IDL。 IDL を使って CORBA アプリケーションを開発している場合、環境をそのまま使用することができます。 IDL を使ってインタフェースを作成し、Java プログラミング言語を使ってクライアントとサーバアプリケーションを定義します。これにより、Java の「Write Once, Run AnywhereTM」移植性機能、生産性の高い実行環境、および非常に堅牢なプラットフォームなどの利点を活用することができます。
RMI-JRMP。 アプリケーションがすべて Java プログラミング言語で書かれている場合、Java RMI テクノロジを使って別の仮想マシンと別の物理マシンの Java オブジェクト間で通信することができます。 IIOP オプションを持たない Java RMI を使用すると、コード移植性の強さや、セキュリティ、ガーベジコレクションを活用することができます。
RMI-IIOP。 新規アプリケーションの大半は Java プログラミング言語で書いているが、他の言語で記述されている従来のアプリケーションも保守する必要がある場合、Java RMI の IIOP コンパイラオプションを使用することができます。
製品の制限の詳細については、「制限」を参照してください。
IOR が複数のプロファイルを含んでいる場合、J2SE v1.4 ORB は、常に最初のプロファイルを使用します。
|
Copyright © 2000-2002 Sun Microsystems, Inc. All Rights Reserved. |
Java ソフトウェア |