また、IDL インタフェースの属性はパブリックなクラスフィールドや C++ のデータメンバーに似ています。idlj コンパイラは OMG IDL の属性を Java プログラミング言語で記述されたアクセス用メソッドおよび修飾用メソッドにマッピングします。たとえば、ball というインタフェースは color という属性を含むとします。idlj コンパイラは色を取得するための Java プログラミング言語のメソッドを生成します。またその属性が readonly でない限り、生成されたメソッドは色を設定することもできます。
Object はまた、IDL インタフェースのオブジェクト参照に利用される暗黙の共通基本型でもあります。 org.omg.CORBA.SystemException から継承するシステム例外 (java.lang.RuntimeException になります)、および (2) org.omg.CORBA.UserException から継承するユーザー定義例外 (java.lang.Exception になります)。 .java ファイルです。バージョン 1.3 より前の J2SDK の idlj コンパイラは、idltojava コンパイラと呼ばれていました。idlj コンパイラでは、RMI-IIOP に必要な CORBA の新しい標準機能がサポートされています。idlj コンパイラは、インストールプログラムによって SDK の .bin ディレクトリに格納されます。 .java ファイルです。J2SDK のバージョン 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 サイトを参照してください。
- インタフェースリポジトリ (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 です。
- object
-
コンピュータ上で、オペレーションおよびデータをモジュール化された単位にグループ化したもの。オブジェクトは、自らが他のオブジェクトに提示するインタフェース、インタフェース上のオペレーションが呼び出された時の動作、およびオブジェクトの状態により定義されます。
- オブジェクトアダプタ
- オブジェクト参照、アクティブ化、サービスに関連する状態をオブジェクトの実装へ提供する 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 オペレーションは片方向であることもあります。この場合、結果 (戻り値や 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 を非活性化することもできます。
- policy
- ポリシーはアプリケーションにより POA に関連付けられたオブジェクトで、その POA に実装したオブジェクトが共有する機能を指定します。この仕様は、POA のスレッドモデルやオブジェクト管理についてのさまざまなオプションを管理する方針を定義します。別の仕様では別のポリシーが定義され、POA で実装したオブジェクトへの要求を ORB が処理する方法に影響を与えることもあります。
- ポータブルインセプタ
- ポータブルインセプタは、ORB サービスがそれを介して通常の実行の流れを遮断することができる ORB へのフックです。詳細は、「PortableInterceptor パッケージ」を参照してください。
- プラグマ
-
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 コンパイラにより生成されるパブリックな抽象クラス。メソッド呼び出しをサーバントオブジェクトにディスパッチする際に必要な情報を 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 ネームサービスの仕様を単純な形で実装したものです。オブジェクト参照は名前空間に名前で格納され、それぞれのオブジェクト参照と名前の組は、ネームバインディングと呼ばれます。ネームバインディングはネーミングコンテキストに組み込むことができます。ネーミングコンテキストはそれ自体がネームバインディングであり、ファイルシステムのサブディレクトリと同じ編成機能を持ちます。すべてのバインディングは初期ネーミングコンテキストの下に格納されます。名前空間において、初期ネーミングコンテキストは唯一の持続的バインディングです。それ以外のネーミングコンテキストは、一時ネーミングサービスプロセスが停止し、再起動されると失われます。
- 一時オブジェクト
- 作成したプロセスやスレッドのライフタイムによって存在期間が限定されているオブジェクト。
| ホーム |