|
このドキュメントは Java TM IDL テクノロジの使用に関する質問にお答えするためのものです。このドキュメントは、届いた質問をもとに今後も更新していきます。探している質問の答えがこの ドキュメント内に見つからない場合は、ユーザーによって支援されている Java IDL テクノロジのフォーラムを参照してください。 フォーラムは、http://forums.java.sun.com で参照できます。
servertool
を使用してサーバーを起動するとき、複数のクラスパスを追加できますか。
tnameserv
、orbd
) を実行できない場合には、どうしたらよいでしょうか。
多くの場合、Java IDL チュートリアルの HelloServer (HelloClient の場合も同様) を実行すると、このエラーが発生するのは、HelloServer がクラスパスに含まれていないためです。クラスパス変数の設定方法の詳細は、「クラスパスの設定」を参照してください。2 番目に多い原因は、次のコード行の引用符と引用符の間に空白が追加されていることです。
NameComponent nc = new NameComponent("Hello", "");引用符の間には空白を入れないでください。空白がなければ、この値は Null として渡されます。引用符の間に空白があると、空白文字が渡されます。
J2SE 1.4.x と J2SE 5.0 の間の互換性に関する情報は、互換性のドキュメントを参照してください。
Red Hat Linux をインストールした場合、InetAddress.getLocalHost() が、ループバックアドレス (127.0.0.1) に対応する InetAddress を返すことがあります。この問題が発生するのは、デフォルトのインストールによって、マシンのホスト名とループバックアドレスとの関連付けが /etc/hosts 内に作成されるためです。InetAddress.getLocalHost() によって確実に実際のホストアドレスが返されるようにするには、/etc/hosts ファイルまたはネームサービスの構成ファイル (/etc/nsswitch.conf) を更新して、ホストを検索する前に、dns または nis に問い合わせるようにします。
最新バージョンの標準 (OMG) マイナーコード例外については、OMG の Web サイト (http://www.omg.org/) を参照してください。よく遭遇する Sun のマイナーコード例外には、次のようなものがあります。
- COMM_FAILURE/201。 「vmcid: SUN マイナーコード: 201」は、「CONNECT_FAILURE」 を意味します。これは、
java.net.SocketException
が原因で生じることがあり、通常はBindException
、ConnectException
、 またはNoRouteToHostException
のいずれかです。次のような点を確認する必要があります。
- ネームサービスは実行されているか。実行されていない場合は、「ネー ムサービスの起動と停止」の説明に従って、ORDB ネームサービスを開始します。
- ネームサービスに対して
-ORBInitialHost
および-ORBInitialPort
の値が正しく設定されているか。どのように設定したらよいか分からない場合は、「ネームサー ビスの起動と停止」を参照してください。- クライアントアプリケーションとサーバーアプリケーションは、ネームサービスが実行されているポート番号 (必要な場合は、さらにマシン名) を認識しているか。これを行う方法については、「ネーム サービスの起動と停止」を参照してください。
- COMM_FAILURE/208。 「vmcid: SUN マイナーコード: 208」は、「CONNECTION ABORT」 を意味します。 これは一般に、接続が切れたことを表します。
- COMM_FAILURE/209。 「vmcid: SUN マイナーコード: 209」は、「CREATE_LISTENER_FAILED:
Unable to create the listener thread on the specific port. Either the post is taken or there was an error creating the daemon thread
」 を意味します。これは一般に、ネームサービスを実行しようとしたポートが別のプロセスによって使用中であることを示しています。Solaris 上で実行している場合には、このポートで別のプロセスが実行中かどうかを調べるために、端末プロンプトで次のコマンドを実行します。
netstat | grep port_number
- COMM_FAILURE/204。「vmcid: SUN マイナーコード: 204」は、「SERVANT_NOT_FOUND」を意味します。これがスローされる唯一の場所は、
corba.INSSubcontract.getINSReference
です。
- MARSHAL/217。 vmcid: SUN マイナーコード: 217」は、クライアントが GIOP 1.0 で
wchar
かwstring
のいずれかを送信しようとしたことを意味します。 これは、仕様で許可されていません。
- MARSHAL/202。「vmcid: SUN マイナーコード: 202」は、
org.omg.CORBA.Object
から派生したオブジェクトを整列化しようとしたが、その特定のインスタンスが ORB に接続されていないことを意味します。POA を使用する場合は、まずオブジェクトを POA に登録する必要があります。オブジェクトを POA に登録する方法の詳細については、POA のドキュメントまたはチュートリアルを参照してください。
- BAD_PARAM/201。「vmcid: SUN マイナーコード: 201」は、「NULL_PARAM」 を意味します。この例外は、多くの場合、
write_string
やwrite_octet_array
などのwrite
メソッドに対して Java のnull
を渡したときに発生します。 Java メソッドの結果として Java のnull
を返すことはできません。
- org.omg.CORBA.INTERNAL。「vmcid: SUN マイナーコード: 208」は、「
Unable to determine local hostname using InetAddress.getLocalHost().getHostName()
」を意味します。ORB は、
InetAddress.getLocalHost().getHostName()
を使用して、参照の検索やバインドのためにネームサービスへの参照を作成します。また、サーバー側でInetAddress.getLocalHost().getHostName()
を使用して、ドット区切り 10 進数とポートの組み合わせではなく、サーバーの名前とポートを含んだリモートオブジェクト参照 (つまり IOR) を作成します。
getHostName
の呼び出しを回避するには、次のようなプロパティーを設定します (設定方法については、「ネームサービスの起動と停止」を参照)。
- ORB がサーバーとして機能している場合は、
com.sun.CORBA.ORBServerHost
にサーバーの DNS 名またはドット区切り 10 進数アドレスを設定com.sun.CORBA.ORBInitialHost
に、ネームサーバーの DNS 名またはドット区切り 10 進数アドレスを設定注: これらのプロパティーは独自のもので、削除または変更されることがあります。
これらの説明では不十分な場合、または上記以外の Sun マイナーコードに遭遇した場合には、ユーザーによって支援されている Java IDL テクノロジのフォーラム (http://forum.java.sun.com) を利用してみてください。マイナーコードの意味についてフォーラムに情報を求める場合は、次の情報をお知らせください。
- クライアントおよびサーバーを実行しているプラットフォーム (Solaris、Linux、Win32 など)
- 使用している Java SE のバージョン (1.5.0_01 など)
- スタックトレース全体
- 異なるベンダーのネームサービスまたは ORB を使用している場合は、その製品に関する情報
servertool
を使用してサーバーを起動するとき、複数のクラスパスを追加できますか。この質問は、もともと次のような内容でした。
私のサーバーコードでは、クラスパスに複数の JAR ファイルが必要です。そこで、servertool
を使用してサーバーを登録するときにクラスパスを指定しようとしたのですが、register
コマンドで構文エラーが起こります。使用したコマンド行の長さが制限を超えているように思われます。
servertool
でサーバーを登録するとき、非常に長いクラスパスを指定するにはどうしたらよいのでしょうか。
servertool
そのものは複数の JAR ファイルを受け付けるのですが、現在のところ、servertool
のコマンド行バッファーの長さに関してバグがあります。servertool
ラッパーのバグ (バグ 4482166) の詳細については、http://developer.java.sun.com/developer/bugParade/bugs/4482166.html を参照してください。回避策として、
servertool
内からサーバーを起動する代わりに、ServerTool
クラスを呼び出してサーバーを起動することができます。 たとえば、次のようにします。${JAVA_HOME}/bin/java com.sun.corba.se.internal.Activation.ServerTool -ORBInitialPort ${ORB_INITIAL_PORT} -cmd register -server sample.MyServer -classpath jar1:jar2:jar3 -applicationName sample
servertool
クラスの名前は、将来のリリースで変更になる可能性があるこ とに注意してください。
tnameserv
、orbd
) を実行できない場合には、どうしたらよいでしょうか。Linux 上でネームサービスの起動が失敗する場合は、/etc/hosts
ファイルに次の行を組み込みます。
<Local Host IP Address> localhost <Local Host IP Address> <HostName>ここで <Local Host IP Address> は、ネームサービス (
tnameserv
、orbd
) を起動するホストの IP アドレスです。
Java SE に同梱されている Java CORBA ORB はマルチスレッド化されています。サーバー側に用意されているスレッド プールでは、各着信要求が独立したスレッドによって処理されます。プールのスレッドがすべて使用中のときに新しいリクエストを受け取ると、新しいスレッドが作成されてプールに追加されます。このスレッドは、要求が完了すると、プールに戻されます。
Java CORBA ORB は、スケーラビリティーとリクエストの同時処理を実現するために、スレッド化されています。POA スレッドポリシー用の SINGLE_THREAD オプションはサポートされていません。
Java CORBA ORB のスレッドモデルは次のように暗黙的です。すなわち、ユーザーは、ORB のスレッドポリシーを設定しません。また、スレッドモデルやスレッド数を制御するための、公開された外部のユーザーレベル API はありません。
いいえ、ありません。これらのサービスが必要な場合は、自分で実装するか、既製品を購入するか、自由に利用できるサービスを探す ことができます。そのようなサードパーティーのサービスは、INS テクノロジを使用して ORB にプラグインできます。
ネームサーバーと同一のマシン上で実行されていないクライアントやサーバーを起動する場合、-ORBInitialHost <ネームサービスが起動されるホストの名前> オプションを使います。こうすると、クライアントとサーバーはネームサービスの場所を知ることができます。Web サイト http://java.sun.com/j2se/1.5.0/docs/technotes/guides/idl/tutorial/jidl2machines.html に例があるので参照してください。
J2SE 5.0 に同梱されている CORBA テクノロジの準拠に関する情報は、http://java.sun.com/j2se/1.5.0/docs/technotes/guides/idl/compliance.html にあるCORBA の準拠についての説明を参照してください。
Official Specifications for CORBA support in J2SE 5.0 を参照してください。
アプリケーション内で Java CORBA ORB 以外の ORB を使用するには、org.omg.CORBA.ORBClass プロパティーを、選択した ORB に設定します。たとえば、使用したい ORB 実装を ORB に設定するには、次の例のようなコードを使用します。
public class MyApp { public static void main( String args[] ) { Properties properties = System.getProperties(); properties.put( "org.omg.CORBA.ORBClass", "<com.other_company.package.ORB>" ); try { ORB orb = ORB.init( args, properties); ...使用する ORB 実装に固有のプロパティー設定については、ベンダーのドキュメントを参照してください。
この JDK ORB については、J2EE の検証プロセスの一環としてテストを実施済みです。 ただし、すべてのベンダーのスタンドアロン CORBA ORB との相互運用性についてテストを実施したわけではありません。
使用する他ベンダーのサービスで INS がサポートされている場合は、それを試してみてください。INS を利用し、ORB.object_to_string() メソッドを使用して、他ベンダーの ORB サーバー上の Interoperable Object References (INS チュートリアルの IOR に関する説明を参照) を文字列に変換します。その文字列をファイルに書き込みます。
C++ クライアントと Enterprise JavaBeans コンポーネントを使用したサンプルアプリケーションを含む開発者ガイドが、Web サイト http://java.sun.com/j2se/1.5.0/docs/technotes/guides/rmi-iiop/interop.html に用意されています。
サードパーティー製のネームサービスが Interoperable Naming Service (INS) をサポートしている場合は、INS オプションを使用する方法をお勧めします。Sun ORB をほかのベンダーのネームサービスとともに使用するには
- ホストおよびポート上でサードパーティー製のネームサーバーを起動します。
- 次の引数を ORB.init() に渡します。
-ORBInitRef NameService=corbaloc:iiop:1.2@:/NameServiceorb.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/) から入手できます。一方で Java プラットフォームを使用し、もう一方で C++ を使用するには、IDL を共有するだけで十分です。C++ ORB のツールを使って C++ ORB で使用するスタブとスケルトンを生成する必要がありますが、IDL は変更する必要がありません。CORBA ORB と、使用する言語の言語マッピングコンパイラを提供するベンダーは、「C++ CORBA ORB」などのキーワードで Web を検索します。C++ クライアントと Enterprise JavaBeans コンポーネントを使用したサンプルアプリケーションを含む開発者ガイドが、Web サイト http://java.sun.com/j2se/1.5.0/docs/technotes/guides/rmi-iiop/interop.html に用意されています。
異なる言語で書かれた ORB 間での通信が可能なはずですが、Java ORB とほかのベンダーの ORB との相互運用性はまだテストされていません。
これは基本的な問題であり、Java プログラミング言語と CORBA を統合する 2 つの方式の違いを理解することが重要です。
Java IDL テクノロジは、CORBA インタフェース定義言語 (Interface Definition Language、IDL) で定義されたインタフェースに基づいて Java プログラミング言語でプログラムを記述したい CORBA プログラマ向けです。これは「通常どおりの」CORBA プログラミングで、C++ や COBOL のような他の言語とまったく同じ方法で Java をサポートしています。
Java RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) テクノロジは、IIOP を背後のトランスポートとして使用して Java Remote Method Invocation (Java RMI) インタフェースでプログラムを作成したい、Java プログラマ向けです。RMI-IIOP はさまざまな言語で実装される CORBA オブジェクトとの相互運用性を提供しますが、リモートインタフェースをあらかじめ Java RMI インタフェースとして定義しておく必要があります。EJB のリモートオブジェクトモデルは Java RMI テクノロジベースなので、Enterprise JavaBeansTM (EJBTM) テクノロジを使うプログラマには特に重要です。
idltojava コンパイラをダウンロードすることはできなくなりました。IDL-to-Java コンパイラ idlj の最新バージョンを使用することを強くお勧めします。最新バージョンの IDL-to-Java コンパイラを入手するには、最新バージョンの Java TM 2 Platform, Standard Edition (J2SE TM) をダウンロードしてください。Java SE をインストールすると、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 言語をサポートしています。
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 を使用すると、コード移植性の強さや、セキュリティー、ガーベジコレクションを活用することができます。
Java RMI-IIOP。 新規アプリケーションの大半は Java プログラミング言語で書いているが、ほかの言語で記述されている従来のアプリケーションも保守する必要があるという場合には、Java RMI を IIOP コンパイラオプションと併用することができます。
製品の制限の詳細については、「制限」を参照してください。
最新バージョンの標準タグ割り当てファイルについては、OMG の Web サイト (http://www.omg.org/) を参照してください。
Copyright © 2000-2004 Sun Microsystems, Inc. All Rights Reserved. |
Java Software |