bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0

Tuxedo CORBA idltojava コンパイラ

 Previous Next Contents Index View as PDF  

Java IDL プログラミングの概念

ここでは、以下の内容について説明します。

 


例外

CORBA には 2 種類の例外があります。OMG によって完全に指定されている標準的なシステム例外と、個々のアプリケーション・プログラマによって定義されるユーザ例外です。CORBA の例外は Java の例外オブジェクトとわずかに異なりますが、こうした相違は主に IDL と Java のマッピングで処理されます。

ここでは、次の内容について説明します。

CORBA の例外と Java の例外の相違

IDL で例外を指定するために、インターフェイス設計者は raises キーワードを使用します。これは、Java での throwsの指定と同様です。IDL で exception キーワードを使用すると、ユーザ定義の例外を作成することになります。標準的なシステム例外は、このような指定をする必要がありません (このような指定はできません)。

システム例外

CORBA では、一連の標準システム例外を定義しています。これらの例外は一般に ORB ライブラリによって生成され、以下のようなシステムのエラー状態を知らせます。

すべての IDL オペレーションは、呼び出されたときにシステム例外をスローできます。インターフェイス設計者がインターフェイス内のオペレーションでシステム例外をスローするよう指定しなくても、処理は自動で行われます。

これは、オペレーションのインプリメンテーションが単純であっても、別のプロセス (多くは別のマシン上のプロセス) であるクライアントからのオペレーション呼び出しによって、あらゆる種類のエラーが発生する可能性があるためです。

このため、CORBA Java クライアントは常に CORBA システム例外をキャッチできる必要があります。さらに、開発者は、キャッチする必要のあるシステム例外の通知を idltojava コンパイラに期待できません。これは、CORBA のシステム例外が java.lang.RuntimeException の下位クラスであるためです。

システム例外の構造

すべての CORBA システム例外は同じ構造です。

exception <SystemExceptionName> { // エラーの説明
unsigned long minor; // エラーの詳細
CompletionStatus completed; // 値は、yes、no、maybe のいずれか
}

システム例外は java.lang.RuntimeException のサブタイプで、org.omg.CORBA.SystemException の下位クラスです。

java.lang.Exception
|
+--java.lang.RuntimeException
|
+--org.omg.CORBA.SystemException
|
+--BAD_PARAM
|
+--//etc.

完了ステータス

すべての CORBA システム例外には、例外をスローしたオペレーションのステータスを示す完了ステータス・フィールドがあります。完了コードは、以下のとおりです。

ユーザ例外

CORBA ユーザ例外は java.lang.Exception クラスのサブタイプで、org.omg.CORBA.UserException の下位クラスです。

java.lang.Exception
|
+--org.omg.CORBA.UserException
|
+-- Stocks.BadSymbol
|
+--//etc.

IDL に指定されているユーザ定義例外が起きるたびに、結果として Java の例外クラスが生成されます。こうした例外は、すべてプログラマが定義し、インプリメントします。

マイナー・コードの意味

すべてのシステム例外には、例外発生の原因についての付加情報を CORBA ベンダが提供するための「minor」フィールドが用意されています。表 4-1 および表 4-2 に、Java IDL のシステム例外のマイナー・コードと、それらの意味を示します。

表 4-1 ORB のマイナー・コードとその意味

コード

意味

BAD_PARAM 例外のマイナー・コード

1

Java IDL メソッドに NULL パラメータが渡されました。

COMM_FAILURE 例外のマイナー・コード

1

オブジェクト・リファレンス、または位置/オブジェクトの転送の後で取得されたオブジェクト・リファレンスで指定されているホストおよびポートに接続できませんでした。

2

ソケットへの書き込みを試みている間にエラーが発生しました。ソケットは他方の側で閉じられているか、アボートされています。

3

ソケットへの書き込みを試みている間にエラーが発生しました。接続が存在しません。

6

サーバへの接続が、数回試みてもできませんでした。

DATA_CONVERSION 例外のマイナー・コード

1

ORB の string_to_object オペレーション中に不正な 16 進数が見つかりました。

2

string_to_object() の指定された IOR の長さの値が奇数です。偶数を指定して下さい。

3

string_to_object() に指定された文字列が IOR で始まりません。このため、IOR の文字列が無効です。

4

ORB の resolve_initial_references オペレーションを実行できません。ホストまたはポートが不正または未指定であるか、リモート・ホストが Java IDL のブートストラップ・プロトコルをサポートしていません。

INTERNAL 例外のマイナー・コード

3

サーバによる IIOP 応答メッセージで不正なステータスが返されました。

6

マーシャリングの解除時に、ユーザ例外のリポジトリ ID の長さが不正であることが判明しました。

7

Java API の InetAddress.getLocalHost().getHostName() を使用してもローカルなホスト名を判別できません。

8

特定のポートのリスナ・スレッドを作成できません。ポートが既に使用中であるか、デーモン・スレッドの作成でエラーが発生したか、あるいはセキュリティ制限がリスニングを妨げています。

9

IIOP 位置の応答で、不正な位置応答のステータスが見つかりました。

10

オブジェクト・リファレンスの文字列化でエラーが発生しました。

11

不正な GIOP 1.0 メッセージ型の IIOP メッセージが見つかりました。

14

ユーザ例外のマーシャリング解除でエラーが発生しました。

18

内部初期化エラーです。

INV_OBJREF 例外のマイナー・コード

1

IOR のプロファイルがありません。

MARSHAL 例外のマイナー・コード

4

オブジェクト・リファレンスのマーシャリングの解除でエラーが発生しました。

5

ワイド文字およびワイド文字列といったサポートされていない IDL の種類のマーシャリングまたはマーシャリング解除を行います。

6

文字または文字列のマーシャリングあるいはマーシャリング解除中に、ISO Latin-1 (8859.1) 準拠でない文字が見つかりました。0 〜 255 の範囲にありません。


NO_IMPLEMENT 例外のマイナー・コード

1

動的スケルトン・インターフェイスがインプリメントされていません。

OBJ_ADAPTER 例外のマイナー・コード

1

サーバ側の要求をオブジェクト・アダプタ層へディスパッチするときに、オブジェクト・キーにあるオブジェクト・アダプタと一致するオブジェクト・アダプタが見つかりません。

2

サーバ側のロケート要求をオブジェクト・アダプタ層へディスパッチするときに、オブジェクト・キーにあるオブジェクト・アダプタと一致するオブジェクト・アダプタが見つかりません。

4

ORB のサーバントへの接続を試みてエラーが発生しました。

OBJ_NOT_EXIST 例外のマイナー・コード

1

ロケート要求の結果、ロケータにとってそのオブジェクトが未知であることを示す応答がありました。

2

要求を受信したサーバのサーバ ID が、呼び出したオブジェクト・リファレンスのオブジェクト・キーに書きこまれたサーバ ID と一致しません。

4

オブジェクト・リファレンスの内部にあるオブジェクト・キーの内容と一致するスケルトンがサーバ側にありません。

UNKNOWN 例外のマイナー・コード

1

マーシャリングの解除で未知のユーザ例外が見つかりました。サーバは、クライアントが期待したものと一致しないユーザ例外を返しました。

3

未知の実行時例外がサーバのインプリメンテーションによってスローされました。


 

表 4-2 ネーム・サーバのマイナー・コードとその意味

コード

意味

INITIALIZE 例外のマイナー・コード

150

一時ネーム・サービスの初期化中に SystemException が発生しました。

151

一時ネーム・サービスの初期化中に Java の例外が発生しました。

INTERNAL 例外のマイナー・コード

100

rebind オペレーションで AlreadyBound 例外がスローされました。

101

rebind_context オペレーションで AlreadyBound 例外がスローされました。

102

内部のバインド・インプリメンテーションに渡されたバインド型が、BindingType.nobject または BindingType.ncontext ではありません。

103

オブジェクト・リファレンスはコンテキストとしてバインドされていますが、CosNaming.NamingContext にナロー変換できません。

200

バインド・オペレーションのインプリメンテーションが、以前のバインディングに遭遇しました。

201

リスト・オペレーションのインプリメンテーションがリスト・イテレータを作成する際に Java の例外をキャッチしました。

202

new_context オペレーションのインプリメンテーションが新しい NamingContxt サーバントを作成する際に Java の例外をキャッチしました。

203

destroy オペレーションのインプリメンテーションが ORB の切り離し中に、Java の例外をキャッチしました。


 

 


初期化

CORBA Java クライアントまたは CORBA Java 共同クライアント/サーバで CORBA オブジェクトを使用可能にするには、次の方法で自身を初期化する必要があります。

ORB オブジェクトの作成

CORBA Java クライアントまたは CORBA Java 共同クライアント/サーバが CORBA オブジェクトを作成または呼び出せるようになるには、最初に ORB オブジェクトを作成する必要があります。ORB オブジェクトを作成することで、クライアントまたは共同クライアント/サーバは ORB に自身の存在を知らせ、ORB オブジェクトで定義されている重要なオペレーションへのアクセスを取得します。

クライアントと共同クライアント/サーバでは、ORB のインスタンスを作成する方法がわずかに異なります。これは、ORB.init の呼び出しに渡される必要があるパラメータの配列が異なるためです。

アプリケーション用 ORB の作成

次のコードは、CORBA Java クライアントが ORB を作成する方法の一例です。

    import org.omg.CORBA.ORB;

public static void main(String args[])
{
try{
ORB orb = ORB.init(args, null);
// コード続く

アプレット用 ORB の作成

Java アプレットでは、次のようにして ORB を作成します。

    import org.omg.CORBA.ORB;

public void init() {
try {
ORB orb = ORB.init(this, null);
// コード続く

一部の Web ブラウザには、ORB が組み込まれています。このため、ブラウザの ORB が標準に完全に準拠していないと問題が生じます。そのような場合は、Java IDL ORB を確実に初期化するための特別なステップが必要になります。たとえば、Netscape Communicator 4.01 の ORB ではクラスが不足しているために、このブラウザで表示するアプレットの init() メソッドには、次に示すようなコードが必要です。

    import java.util.Properties;
import org.omg.CORBA.*;

public class MyApplet extends java.applet.Applet {
public void init()
{
// Java IDL ORB のインスタンス化。このアプレットに渡して
// ORB がアプレットのプロパティを取得できるようにする
Properties p = new Properties();
p.put("org.omg.CORBA.ORBClass", "com.sun.CORBA.iiop.ORB");
p.put("org.omg.CORBA.ORBSingletonClass","com.sun.CORBA.idl.ORBSingleton");
System.setProperties(p);
ORB orb = ORB.init(args, p);
...
}
}

ORB.init() の引数

アプリケーションとアプレットの両方について、初期化メソッドの引数は次のとおりです。

init() オペレーションはこれらのパラメータをシステムのプロパティとともに使用して、ORB のコンフィギュレーションに必要な情報を取得します。ORB コンフィギュレーションのプロパティの検索は、以下の場所および順序で行われます。

  1. アプリケーションまたはアプレットのパラメータ (最初の引数)。

  2. java.util.Properties オブジェクト (2 番目の引数)。提供されている場合。

  3. System.getProperties() によって返された java.util.Properties オブジェクト。

いずれかのプロパティで最初に見つかった値が、init() オペレーションで使用される値です。上記の場所のいずれにもコンフィギュレーションのプロパティがない場合、init() オペレーションはインプリメンテーションに固有の値を推定します。ORB のインプリメンテーション間で移植性を最大にするために、アプレットおよびアプリケーションはオペレーションに影響するコンフィギュレーションのプロパティの値を明示的に指定する必要があります。自身が実行されている ORB による推定には依存しないようにしてください。

システムのプロパティ

BEA Tuxedo 製品は Sun Microsystems, Inc の Java 仮想マシンを使用しています。この仮想マシンは、コマンド行引数 -D を追加しています。ほかの Java 仮想マシンの中には、Sun の仮想マシンと同様のものもあれば、異なるものもあります。

現在、すべての ORB インプリメンテーションについて以下のコンフィギュレーション・プロパティが定義されています。

アプレットのパラメータには、完全なプロパティ名を指定する必要があります。アプリケーションの規則はアプレットとは異なるので、コマンド行呼び出しでの言語固有の詳細項目がエクスポーズされることはありません。

初期オブジェクト・リファレンスの取得

CORBA オブジェクトを呼び出すには、アプレットまたはアプリケーションで CORBA オブジェクトへのリファレンスが必要です。CORBA オブジェクトへのリファレンスを取得する方法は、次の 3 つです。

文字列化されたオブジェクト・リファレンス

第一のテクニックである、文字列化されたリファレンスを実際のオブジェクト・リファレンスに変換する方法は、ORB のインプリメンテーションに依存しません。アプレットまたはアプリケーションがどの ORB 上で実行されていても、文字列化されたオブジェクト・リファレンスを変換することができます。ただし、アプレットまたはアプリケーションの開発者は、以下の点に留意してください。

ORB からのリファレンスの取得

初期 CORBA オブジェクトを取得するために文字列化されたリファレンスを使用しない場合は、ORB 自身を使用して初期オブジェクト・リファレンスを生成します。

Bootstrap オブジェクトは、新しく開始されたアプリケーションまたはアプレットにオブジェクト・リファレンスをブートストラップ処理するための resolve_initial_references() というオペレーションを定義します。このオペレーションは、認識されるいくつかのオブジェクトのうち 1 つの名前を指定する文字列引数を取ります。結果として 1 つの CORBA オブジェクトが返され、このオブジェクトはアプレットやアプリケーションが認識する型にナロー変換される必要があります。

Bootstrap オブジェクトを使用すると、オブジェクト・リファレンス (SecurityCurrent、TransactionCurrent、FactoryFinder、NotificationService、Tobj_SimpleEventsService、NameService、および InterfaceRepository) を取得できます。ここでは、FactoryFinder オブジェクトについて説明します。

FactoryFinder インターフェイスは、BEA Tuxedo ドメインへの唯一の入り口となるオブジェクト・リファレンスをクライアントに提供します。FactoryFinder オブジェクトは特定のファクトリ・オブジェクトの取得に使用されます。取得したファクトリ・オブジェクトで、必要なオブジェクトを作成することができます。

Bootstrap オブジェクトの使用の詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。

 


FactoryFinder インターフェイス

FactoryFinder インターフェイスは、BEA Tuxedo ドメインへの唯一の入り口となるオブジェクト・リファレンスをクライアントに提供します。複数の FactoryFinder によって、可用性と信頼性が高まります。複数のドメインにわたるマッピングがサポートされています。

FactoryFinder のインターフェイスと NameManaer は、オブジェクトの登録、格納、および検索のためのメカニズムです。BEA Tuxedo 環境では、次のことができます。

FactoryFinder オブジェクトの使用の詳細については、『BEA Tuxedo CORBA プログラミング・リファレンス』を参照してください。

 

Back to Top Previous Next
Contact e-docsContact BEAwebmasterprivacy