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仕様の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つのオプションは、orbdです。これは、ブートストラップ・サービス、一時ネーミング・サービス、永続ネーミング・サービスおよびServer Managerを含むデーモン・プロセスであり、一時ネーミング・サービスである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ツール(Solaris、Linux、Mac OS XまたはWindows)は、ブートストラップ・サービス、一時ネーム・サービス、持続ネーム・サービス、サーバー・マネージャを含むデーモン・プロセスです。
パラメータ(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のスレッド・モデルやオブジェクト管理についての様々なオプションを管理するポリシーを定義します。その他の仕様では、ORBがPOAに実装されたオブジェクトに対するリクエストを処理する方法に影響を与える他のポリシーを定義できます。
ポータブル・インタセプタ: ポータブル・インタセプタは、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 (Solaris、Linux、Mac OS XまたはWindows)はアプリケーション・プログラマが簡単に利用できるインタフェースを提供し、サーバーの登録、登録解除、起動、シャットダウンを行います。
サービス層: 分散アプリケーションの一部。ビジネス・ロジックを含み、計算処理の大半を行います。通常、サービス層は、リソースの最適利用のために共有マシン上に配置されます。
シグニチャ・インタフェース: 非抽象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 (Solaris、Linux、Mac OS XまたはWindows)は、COSネーム・サービスの仕様を単純な形で実装したものです。オブジェクト参照は名前空間に名前で格納され、それぞれのオブジェクト参照と名前の組は、ネーム・バインディングと呼ばれます。ネーム・バインディングはネーミング・コンテキストに組み込むことができます。ネーミング・コンテキストはそれ自体がネーム・バインディングであり、ファイル・システムのサブディレクトリと同じ編成機能を持ちます。すべてのバインディングは初期ネーミング・コンテキストの下に格納されます。名前空間において、初期ネーミング・コンテキストは唯一の持続的バインディングです。それ以外のネーミング・コンテキストは、一時ネーム・サービス・プロセスが停止し、再起動されると失われます。
一時オブジェクト: 作成したプロセスやスレッドのライフ・タイムによって存在期間が限定されているオブジェクト。

連絡先