Java IDL 用語集

アダプタアクティベータ: アダプタアクティベータは、アプリケーションの開発者が POA と関連付けることのできるオブジェクトです。ORB は、存在していない子 POA への要求を受け取ると、アダプタアクティベータのオペレーションを呼び出します。アダプタアクティベータは必要な POA をその場で作成します。
属性 (IDL): オブジェクトと値の特定可能な関連付け。属性 A は、オペレーションの組み合わせget_A および set_A によりクライアントに識別されます。readonly 属性の場合は get オペレーションだけを生成します。
また、IDL インタフェースの属性はパブリックなクラスフィールドや C++ のデータメンバーに似ています。idlj コンパイラは OMG IDL の属性を Java プログラミング言語で記述されたアクセス用メソッドおよび修飾用メソッドにマッピングします。たとえば、ball というインタフェースは color という属性を含むとします。idlj コンパイラは色を取得するための Java プログラミング言語のメソッドを生成します。またその属性が readonly でないかぎり、生成されたメソッドは色を設定することもできます。
クライアント: 分散オブジェクト上でオペレーションを呼び出す任意のコード。クライアントは、それ自体が CORBA オブジェクトであることも、非オブジェクト指向のプログラムのこともあります。しかし、CORBA オブジェクト上のメソッドを呼び出しているかぎり、クライアントとして機能していると言えます。
クライアントスタブ: idlj により生成された Java プログラミング言語のクラス。オブジェクトの呼び出しの間、クライアント ORB から透過的に使用されます。クライアントによるリモートオブジェクト参照は、クライアントスタブを指します。このスタブは、それを生成した IDL インタフェース固有であり、クライアントが IDL インタフェースで定義された CORBA オブジェクトのメソッドを呼び出すのに必要な情報を含んでいます。
クライアント層: サーバー層にサービスを要求する分散アプリケーションの一部。通常、クライアント層の特徴は、省資源のローカル環境、グラフィカルユーザーインタフェース、開発と保守に要する労力の簡素化です。
Common Object Request Broker Architecture (CORBA): CORBA オブジェクトモデルの基礎となる OMG 仕様のアーキテクチャー。CORBA の仕様には、言語に依存しない方法でオブジェクト間の取り決めを作成して分散アプリケーションの実装を可能にするインタフェース定義言語 (IDL) が含まれます。

Java 2 Platform Standard Edition (J2SE) は、Java CORBA ORB および Internet InterORB Protocol (IIOP) を利用する CORBA Object Request Broker (ORB) および 2 つの CORBA プログラミングモデルを提供しています。2 つのプログラミングモデルとは、RMI プログラミングモデル (RMI-IIOP) と IDL プログラミングモデル (Java IDL) です。プログラミングモデルの詳細については、「CORBA 技術と Java プラットフォーム」を参照してください。
関連項目: クライアント層、サービス層、データ格納層
CORBA オブジェクト: (1) OMG IDL インタフェースにより定義された実体、かつ (2) オブジェクト参照が利用可能な実体。Object はまた、IDL インタフェースのオブジェクト参照に利用される暗黙の共通基本型でもあります。
データ格納層: リレーショナルデータベースのような持続データとその格納メカニズムへのアクセスを管理する分散アプリケーションの一部。
分散アプリケーション: 複数のコンピュータで実行するように設計されたプログラム。典型的なものは、その機能によりクライアント、サービス、およびデータ格納のような層に分割されます。
分散環境: CORBA オブジェクトを使用する 1 つ以上のコンピュータのネットワーク。さまざまなマシンにインストールされたオブジェクトの相互通信が可能です。
Dynamic Invocation Interface (DII): クライアントに対し、リモートの CORBA オブジェクトへの動的呼び出しを可能にする API。コンパイル時にクライアントが、自分が呼び出すオブジェクトについて知らない場合に使用します。オブジェクトを発見すると、クライアントプログラムはその定義を取得し、オブジェクトへのパラメータ化された呼び出しを発行し、オブジェクトからの応答を受け取ります。これらすべては、リモートオブジェクトに対して型固有のクライアントスタブを使用せずに行われます。
Dynamic Skeleton Interface (DSI): コンパイル時にオブジェクト実装型が不明な場合に、要求を ORB からオブジェクト実装に渡す方法を提供する API。DSI はクライアント側の DII と同等の機能をサーバー側に提供します。アプリケーションプログラマは DSI を使って受け取った要求のパラメータを検査し、ターゲットオブジェクトおよびメソッドを判定することができます。
例外 (IDL): 呼び出しに応答して返される、例外的な状況を表す IDL の構造。例外には次の 2 つのカテゴリがあります。(1) org.omg.CORBA.SystemException から継承するシステム例外 (java.lang.RuntimeException になります)、および (2) org.omg.CORBA.UserException から継承するユーザー定義例外 (java.lang.Exception になります)。
ファクトリオブジェクト: CORBA オブジェクトの新規作成に使用される CORBA オブジェクト。ファクトリオブジェクト自体は、通常、サーバーのインストール時に作成されます。
idlj コンパイラ: OMG IDL で記述されたインタフェースを受け取り、Java プログラミング言語のインタフェースおよびクラスを生成するツール。生成されたインタフェースおよびクラスは、IDL インタフェースから Java プログラミング言語へのマッピングを表します。結果のファイルは .java ファイルです。バージョン 1.3 より前の JDK の idlj コンパイラは、idltojava コンパイラと呼ばれていました。idlj コンパイラでは、RMI-IIOP に必要な CORBA の新しい標準機能がサポートされています。idlj コンパイラは、インストールプログラムによって SDK の .bin ディレクトリに格納されます。
idltojava コンパイラ: OMG IDL で記述されたインタフェースを受け取り、Java プログラミング言語のインタフェースおよびクラスを生成するツール。生成されたインタフェースおよびクラスは、IDL インタフェースから Java プログラミング言語へのマッピングを表します。結果のファイルは .java ファイルです。JDK のバージョン 1.3 からは、idlj コンパイラで IDL-to-Java 言語マッピングを扱うようになり、RMI-IIOP に必要な新しい CORBA 標準機能がサポートされています。idltojava コンパイラは、Java Developer Connection (JDC) の Web サイトからダウンロードできます。
実装: サポートする IDL インタフェースのオペレーションや属性すべての動作を定義する具象クラス。サーバントオブジェクトは、実装のインスタンスです。1 つのインタフェースに対して多くの実装が可能です。
初期ネーミングコンテキスト: orb.resolve_initial_references("NameService") メソッドへの呼び出しにより返される NamingContext オブジェクト。初期ネーミングコンテキストは COS ネームサービスへのオブジェクト参照です。COS ネームサービスは、ORB に登録され、ほかの NamingContext オブジェクトを作成するのに使用されます。
関連項目: ネーミングコンテキスト
インタフェース定義言語 (IDL): すべての CORBA オブジェクトのインタフェースを定義する OMG 標準言語。IDL インタフェースは、オペレーション、例外、および属性のセットを宣言します。各オペレーションには、名前、パラメータ、結果、および例外を定義したシグニチャーが付けられます。OMG IDL にはオペレーションの実装は含まれません。その名前が示すように、IDL はインタフェースを定義するだけの言語です。IDL の完全な構文およびセマンティクスについては、OMG Web サイトの OMG 仕様を参照してください。
インタフェースリポジトリ (IFR): 登録されたコンポーネントのインタフェースとそれがサポートするメソッド、必要なパラメータのすべてを含むサービス。IFR は、オブジェクトのインタフェース定義を格納、変更、および管理します。プログラムが IFR API を使ってこの情報にアクセスし、変更することも可能です。一般のクライアント/サーバー環境では IFR は必要ありません。
Internet InterORB Protocol (IIOP): OMG 仕様による ORB 間通信用のネットワークプロトコル。Java IDL は、CORBA/IIOP 仕様 2.3.1 に準拠しています。
呼び出し: CORBA オブジェクトへのメソッド呼び出しを実行するプロセス。オブジェクトのネットワーク上の位置を知らずに行われます。コンパイル時にオブジェクトのインタフェースが既知の場合、呼び出しにはクライアントスタブを使用し、呼び出されるサービスにはサーバースケルトンを使用する静的な呼び出しが使用されます。コンパイル時にインタフェースが不明な場合は、動的呼び出しを使用する必要があります。
Java IDL: CORBA オブジェクトを Java プログラミング言語から使用することを可能にするクラス、ライブラリ、およびツール。Java IDL の中核をなすコンポーネントは ORB、ネームサービス、および idlj コンパイラです。そのすべてが今回のリリースの J2SE に含まれています。
ネームバインディング: 名前をオブジェクト参照に関連付けること。ネームバインディングはネーミングコンテキストに格納されます。
名前空間: グループにまとめられたネーミングコンテキストのコレクション。
ネーミングコンテキスト: NamingContext インタフェースをサポートし、ほかのネーミングコンテキストと単純名のいずれかまたはその両方を含み (指し示し)、一種のディレクトリとして機能する CORBA オブジェクト。ネーミングコンテキストはディレクトリ構造に類似しています。ディレクトリ構造では最後の項目がファイルを、残りの項目はディレクトリを表しますが、ネーミングコンテキストでは最後の項目はオブジェクト参照名を、残りの項目はネーミングコンテキストを表します。
ネームサービス: CORBA オブジェクトにネーミングを可能にする CORBA サービス。ネーミングは名前をオブジェクト参照にバインドすることにより可能になります。ネームバインディングはネームサービスに格納され、クライアントは名前を与えて目的のオブジェクト参照を取得できます。今回リリースされた JAVA SE に同梱されているネームサービスには 2 つのオプションがあります。1 つはデーモンプロセスである orbd で、ブートストラップサービス、一時ネームサービス、持続ネームサービス、およびサーバーマネージャーが含まれています。もう 1 つは、一時ネームサービスである tnameserv です。
オブジェクト: コンピュータ上で、オペレーションおよびデータをモジュール化された単位にグループ化したもの。オブジェクトは、自らがほかのオブジェクトに提示するインタフェース、インタフェース上のオペレーションが呼び出された時の動作、およびオブジェクトの状態により定義されます。
オブジェクトアダプタ: オブジェクト参照、アクティブ化、サービスに関連する状態をオブジェクトの実装へ提供する ORB コンポーネント。実装の種類によっては別のアダプタが提供されることもあります。OMG が仕様化した一般的なオブジェクトアダプタは POA で、異なるベンダーの実装に対応する場合も最低限の書き直しで、複数の ORB 実装において使用できます。
オブジェクト ID: オブジェクト ID は POA とユーザー実装で使用される値で、特定の抽象 CORBA オブジェクトを識別します。オブジェクト ID の値は、POA で割り当てて管理する場合と実装で割り当てて管理する場合があります。オブジェクト ID の値はクライアントには隠されており、参照用にカプセル化されます。オブジェクト ID には標準形式はありません。解釈されないオクテットシーケンスとして POA で管理されます。
オブジェクトの実装: 「実装」を参照してください。
Object Management Group (OMG): オブジェクト指向アプリケーション開発のための共通のフレームワークを提供する目的で、業界のガイドラインおよびオブジェクト管理仕様を確立する、700 以上のメンバーから成る国際的な組織。そのメンバーには、プラットフォームベンダー、オブジェクト指向データベースベンダー、ソフトウェアツール開発者、企業開発者、およびソフトウェアアプリケーションベンダーが含まれます。CORBA オブジェクトモデルの仕様は、OMG が策定した Common Object Request Broker Architecture により定められています。詳細については、www.omg.org を参照してください。
オブジェクト参照: ORB でオブジェクトを指定するのに必要な情報を含む構造。オブジェクト参照は CORBA オブジェクトの位置を調べるためにメソッド呼び出しで使用されます。オブジェクト参照は、プログラミング言語固有のオブジェクトポインタと同等の機能を CORBA オブジェクトに実装したものです。オブジェクト参照は、ファクトリオブジェクトやネームサービスから取得することができます。オブジェクト参照は不透明である (内部構造がアプリケーション開発者に無関係である) ため、いつも同じ CORBA オブジェクトを指します。しかし、同一の CORBA オブジェクトを指す複数のオブジェクト参照が存在することもあります。
Object Request Broker (ORB): CORBA オブジェクトが相互に通信することを可能にする分散環境のライブラリ、プロセス、およびほかの基盤。ORB は、オブジェクト要求サービスをその提供元オブジェクトに接続します。
オペレーション (IDL): Java プログラム言語のメソッドへのマッピングを行う IDL インタフェース内の構造。たとえば、ball というインタフェースは bounce というオペレーションをサポートする、といった具合です。オペレーションは、パラメータを取り、結果を返し、例外を発生させることができます。この IDL オペレーションは oneway であることもあります。この場合、結果 (戻り値や out 引数) は返されず、例外も発生しません。
オペレーションインタフェース: 非抽象 IDL インタフェースは、2 つのパブリック Java インタフェースにマップされています。シグニチャーインタフェースとオペレーションインタフェースです。オペレーションインタフェースの名前は IDL インタフェースと同じですが、Operations という接尾辞があり、同一の場所にあるクライアントとサーバーのために最適化された呼び出しを提供するメカニズムとしてサーバー側マッピングで使用されます。
ORBD (Object Request Broker Daemon): orbd ツールは、ブートストラップサービス、一時ネームサービス、持続ネームサービス、サーバーマネージャーを含むデーモンプロセスです。
パラメータ (IDL): クライアントがオペレーションを呼び出す際に IDL オペレーションに渡す 1 つ以上のオブジェクト。パラメータは、in (クライアントからサーバーへ渡される)、out (サーバーからクライアントへ渡される)、または inout (クライアントからサーバーへ渡され、その後サーバーからクライアントに返される) として宣言されます。
持続オブジェクト: オブジェクトを生成したプロセスやスレッドが消失しても存在し続けるオブジェクト。持続オブジェクトは、明示的に削除されるまで存在します。
PIDL (擬似 IDL): CORBA 擬似オブジェクトを記述するインタフェース定義言語。IDL から Java プログラミング言語へのマッピングを含む各言語マッピングは、擬似オブジェクトを言語固有の構造にマッピングする方法を記述します。PIDL マッピングは、正規 CORBA オブジェクトのマッピング規定に従う場合も、従わない場合もあります。
POA (ポータブルオブジェクトアダプタ): オブジェクトアダプタは、オブジェクト参照を使用する要求と適切なコードを接続して、その要求にサービスを提供するメカニズムです。OMG が仕様化した一般的なオブジェクトアダプタは POA で、異なるベンダーの実装に対応する場合も最低限の書き直しで、複数の ORB 実装において使用できます。
POA は、少なくともクライアントの立場からは持続オブジェクトが可能になるようにしています。つまり、サーバーが物理的に何度再起動されても、またはさまざまなオブジェクト実装による実装が行われても、クライアントに関係していればこれらの持続オブジェクトは常に存在し、格納されたデータ値は保守されています。
POA マネージャー: POA マネージャーは 1 つまたは複数の POA の処理状態をカプセル化するオブジェクトです。開発者は POA マネージャーでオペレーションを使用して、関連する POA を待ち行列に入れたり、そこから破棄したりする要求を出すことができます。また、POA マネージャーを使って POA を非活性化することもできます。
ポリシー: ポリシーはアプリケーションにより POA に関連付けられているオブジェクトで、その POA に実装したオブジェクトが共有する機能を指定します。この仕様は、POA のスレッドモデルやオブジェクト管理についてのさまざまなオプションを管理する方針を定義します。別の仕様では別のポリシーが定義され、POA で実装したオブジェクトへの要求を ORB が処理する方法に影響を与えることもあります。
ポータブルインセプタ: ポータブルインセプタは、ORB サービスがそれを介して通常の実行の流れを遮断することができる ORB へのフックです。詳細は、「PortableInterceptor パッケージ」を参照してください。
プラグマ: J2SE v.1.2 で、idltojava コンパイラに対し、IDL ファイルのコンパイル中に特定のオペレーションを実行するように与えられる指示。たとえば、プラグマ javaPackage は、idltojava コンパイラに対し、IDL インタフェースから生成した Java プログラミング言語のインタフェースおよびクラスを、指定した Java プログラミング言語のパッケージに配置するように指示します。J2SE v.1.3 とそれ以降のバージョンでは、この機能は、idlj に対して -pkgPrefix コマンド行オプションを使用することによってサポートされます。
擬似オブジェクト: IDL で記述されたという点では CORBA オブジェクトに類似しているが、オブジェクト参照を使った引き渡しもナロー変換も文字列化もできないオブジェクト。擬似オブジェクトの例として、インタフェースリポジトリと DII を挙げることができます。これらはライブラリとして実装されていますが、OMG の仕様で明確に IDL インタフェースを持つ擬似オブジェクトとして規定されています。擬似オブジェクト用の IDL は PIDL と呼ばれ、その明確な仕様は現在策定中です。
RMI-IIOP: Java RMI-IIOP は Object Request Broker およびコンパイラの rmic -iiop で、IIOP スタブと Tie クラスを生成します。RMI-IIOP を使うと開発者はリモートインタフェースを Java プログラミング言語で書き、Java 技術と Java RMI API を使うだけでインタフェースを実装できます。このようなインタフェースは OMG マッピングがサポートするほかの言語や、ベンダーが提供するその言語の ORB で実装することができます。またクライアントは、リモートの Java 技術ベースのインタフェースから派生した IDL を使ってほかの言語で書くこともできます。RMI-IIOP を使うと、IIOP 上で、参照および値の両方によりオブジェクトを渡すことができます。
サーバント: サーバントは、1 つまたは複数のオブジェクトの要求を実装するプログラミング言語オブジェクトまたはエンティティーです。通常、サーバントはサーバープロセスのコンテキストに存在します。オブジェクトの参照で作成される要求は、ORB で調停され、特定のサーバント上の呼び出しへと変換されます。オブジェクトのライフタイムの間は、そのオブジェクトは複数のサーバントと関連付けることができます。つまり、そのオブジェクト参照で発生した要求は複数のサーバントをターゲットにします。
サーバントマネージャー: サーバントマネージャーは、開発者が POA と関連付けることができるオブジェクトです。ORB はサーバントマネージャーのオペレーションを呼び出して、要求に応じてサーバントを活性化したり非活性化させたりします。サーバントマネージャーには、Object Id 値で特徴づけられるオブジェクトと特定のサーバントの関連を管理し、オブジェクトが存在するかどうかを決定する機能があります。サーバントマネージャーには ServantActivator と ServantLocator の 2 種類があり、POA のポリシーによって使用する場面が異なります。
サーバントオブジェクト: IDL インタフェースのためのオブジェクト実装のインスタンス。呼び出しをどこに送信すればよいかを ORB が知ることができるように、サーバントオブジェクトは ORB に登録されます。CORBA オブジェクトのメソッドが呼び出されたとき、要求されたサービスを実行するのがサーバントの役割です。
サーバー: 1 つ以上の IDL インタフェースの実装を含むプログラム。たとえば、デスクトップパブリッシングサーバーは Document オブジェクト型、ParagraphTag オブジェクト型、およびほかの関連するオブジェクト型を実装するといった具合です。サーバーには、各実装 (サーバントオブジェクト) を ORB に登録することが求められます。登録すると ORB はサーバントについて知ることができるからです。サーバーは、オブジェクトサーバーとして参照されることもあります。
サーバースケルトン: idlj コンパイラにより生成される public abstract クラス。メソッド呼び出しをサーバントオブジェクトにディスパッチする際に必要な情報を ORB に提供します。クライアントスタブと同様、サーバースケルトンは、生成元の IDL インタフェースに固有です。サーバースケルトンは、クライアントスタブと同等の機能をサーバー側に提供します。サーバースケルトンもクライアントスタブも ORB の静的な呼び出しで使用されます。
servertool: Java IDL サーバーツール servertool はアプリケーションプログラマが簡単に利用できるインタフェースを提供し、サーバーの登録、登録解除、起動、シャットダウンを行います。
サービス層: 分散アプリケーションの一部。ビジネスロジックを含み、計算処理の大半を行います。通常、サービス層は、資源の最適利用のために共有マシン上に配置されます。
シグニチャーインタフェース: 非抽象 IDL インタフェースは、2 つのパブリック Java インタフェースにマップされています。シグニチャーインタフェースとオペレーションインタフェースです。シグニチャーインタフェースは、IDLEntity を拡張したもので IDL インタフェース名と同じ名前を持ち、指定した型のインタフェースをほかのインタフェースで使用する場合にメソッド宣言のシグニチャー型として使用します。
スケルトン: オブジェクトインタフェース専用の ORB コンポーネントで、オブジェクトアダプタが特定のメソッドに要求を渡す際に支援します。
静的な呼び出し: 呼び出しを参照。
文字列化されたオブジェクト参照: ディスク上にテキストファイルの形式 (またはほかの何らかの形式) で格納できるよう、文字列に変換されたオブジェクト参照。変換された文字列は、ORB の実装に依存しないために、不透明なものとして扱われる必要があります。org.omg.CORBA.Object の標準メソッドである object_to_string および string_to_object は、文字列化された参照をすべての CORBA オブジェクトで利用可能にします。
スタブ: 単独オペレーションに対応するローカル手続きで、呼び出されるオペレーションを呼び出す。
tnameserv: CORBA の COS (Common Object Services) ネームサービスは、ファイルシステムがファイルに対してディレクトリ構造を提供しているのと同じように、オブジェクト参照に対してツリー構造のディレクトリを提供します。Java IDL の一時ネームサービスである tnameserv は、COS ネームサービスの仕様を単純な形で実装したものです。オブジェクト参照は名前空間に名前で格納され、それぞれのオブジェクト参照と名前の組は、ネームバインディングと呼ばれます。ネームバインディングはネーミングコンテキストに組み込むことができます。ネーミングコンテキストはそれ自体がネームバインディングであり、ファイルシステムのサブディレクトリと同じ編成機能を持ちます。すべてのバインディングは初期ネーミングコンテキストの下に格納されます。名前空間において、初期ネーミングコンテキストは唯一の持続的バインディングです。それ以外のネーミングコンテキストは、一時ネーミングサービスプロセスが停止し、再起動されると失われます。
一時オブジェクト: 作成したプロセスやスレッドのライフタイムによって存在期間が限定されているオブジェクト。

連絡先