共通オブジェクトリクエストブローカーアーキテクチャ

Common Object Request Broker Architecture ( CORBA )は、さまざまなプラットフォームに展開されているシステムの通信を容易にするために設計された、 Object Management Group (OMG)によって定義された標準です。CORBA により、異なるオペレーティング システム、プログラミング言語、およびコンピューティング ハードウェア上のシステム間のコラボレーションが可能になります。CORBA はオブジェクト指向モデルを使用しますが、CORBA を使用するシステムはオブジェクト指向である必要はありません。CORBA は分散オブジェクトパラダイム の一例です。

CORBAは1990年代半ばから後半にかけて一時的に人気を博しましたが、その複雑さ、一貫性のなさ、ライセンスコストの高さから、ニッチな技術となってしまいました。^[1]

CORBA は、異なる言語で記述され、異なるコンピュータで実行されるソフトウェア間の通信を可能にします。特定のオペレーティング システム、プログラミング言語、およびハードウェア プラットフォームの実装の詳細は、CORBA を使用する開発者の責任からすべて取り除かれます。CORBA は、同じアドレス空間 (アプリケーション) またはリモート アドレス空間 (同じホスト、またはネットワーク上のリモート ホスト) にあるアプリケーション オブジェクト間のメソッド呼び出しセマンティクスを標準化します。バージョン 1.0 は 1991 年 10 月にリリースされました。

CORBA は、インターフェイス定義言語(IDL) を使用して、オブジェクトが外部に提示するインターフェイスを指定します。次に、CORBA は IDL から C++ や Java などの特定の実装言語へのマッピングを指定します。Ada 、 C 、 C ++、C ++11 、 COBOL 、 Java 、 Lisp 、 PL/I 、 Object Pascal 、 Python 、 Ruby 、 Smalltalk には標準マッピングが存在します。C #、Erlang、Perl、Tcl、Visual Basicには、それらの言語用に記述されたオブジェクトリクエストブローカー( ORB )によって実装された非標準マッピングが存在します。IDL のバージョンは大幅に変更され、一部のプラグマが注釈に置き換えられました。

CORBA 仕様では、アプリケーションが他のオブジェクトと対話するための ORB が必要であると規定されています。これは実際には次のように実装されます。

1. アプリケーションは ORB を初期化し、参照カウント、オブジェクト (および参照) のインスタンス化ポリシー、オブジェクトの有効期間ポリシーなどを管理する内部オブジェクト アダプタにアクセスします。
2. オブジェクト アダプタは、生成されたコード クラスのインスタンスを登録するために使用されます。生成されたコード クラスは、ユーザー IDL コードをコンパイルした結果であり、高レベルのインターフェイス定義を、ユーザー アプリケーションが使用できるように OS および言語固有のクラス ベースに変換します。この手順は、CORBA セマンティクスを適用し、CORBA インフラストラクチャとのインターフェイスにクリーンなユーザー プロセスを提供するために必要です。

一部の IDL マッピングは、他のマッピングよりも使いにくいです。たとえば、Java の性質上、IDL-Java マッピングは比較的簡単で、Java アプリケーションで CORBA を使用するのが非常に簡単になります。これは、IDL から Python へのマッピングにも当てはまります。C++ マッピングでは、プログラマーは C++標準テンプレート ライブラリ(STL) より前のデータ型を学習する必要があります。対照的に、C++11 マッピングは使いやすいですが、STL を多用する必要があります。C 言語はオブジェクト指向ではないため、IDL から C へのマッピングでは、C プログラマーがオブジェクト指向機能を手動でエミュレートする必要があります。

CORBA ベースの分散オブジェクト インターフェイスを使用または実装するシステムを構築するには、開発者は、システムが使用または実装するロジックへのオブジェクト指向インターフェイスを定義する IDL コードを取得するか、または作成する必要があります。通常、ORB 実装には、システムのその部分で使用するために IDL インターフェイスをターゲット言語に変換する IDL コンパイラと呼ばれるツールが含まれています。次に、従来のコンパイラが生成されたコードをコンパイルして、アプリケーションで使用するためのリンク可能なオブジェクト ファイルを作成します。次の図は、生成されたコードが CORBA インフラストラクチャ内でどのように使用されるかを示しています。

この図は、CORBA を使用したリモート プロセス間通信の高レベル パラダイムを示しています。CORBA 仕様では、さらに、データ型、例外、ネットワーク プロトコル、通信タイムアウトなどについても規定されています。たとえば、通常、サーバー側には、呼び出しをローカルサーバントまたは (負荷を分散するため) 他のサーバーにリダイレクトするポータブルオブジェクト アダプター(POA)があります。CORBA 仕様 (およびこの図) では、オブジェクトの有効期間 (参照カウント セマンティクスはアプリケーションで使用可能)、冗長性/フェイルオーバー、メモリ管理、動的負荷分散、表示/データ/制御セマンティクス間の分離などのアプリケーション指向モデル (例:モデル - ビュー - コントローラーを参照) など、 分散システムのさまざまな側面をアプリケーションで定義するようにしています。

CORBA は、ユーザーに言語とプラットフォームに依存しないリモート プロシージャ コール(RPC) 仕様を提供するだけでなく、トランザクションとセキュリティ、イベント、時間、その他のドメイン固有のインターフェイス モデルなど、一般的に必要なサービスを定義します。

この表はCORBA標準バージョンの履歴を示しています。^{[2] [3] [4]}

IDL の変更は、一部のプラグマを置き換えるアノテーション (@unit、@topic など) によって進行していることに注意してください。

サーバントは、リモート メソッド呼び出しを処理するメソッドを含む呼び出しターゲットです。新しい CORBA バージョンでは、リモート オブジェクト (サーバー側) は、オブジェクト( リモート呼び出しに公開される)とサーバント (前者がメソッド呼び出しを転送する) に分割されます。リモートオブジェクトごとに1 つのサーバントにすることも、同じサーバントが、指定されたポータブル オブジェクト アダプタに関連付けられた複数の (場合によってはすべての) オブジェクトをサポートすることもできます。各オブジェクトのサーバントは、「1 回限りで永久に」設定または検索することも (サーバントのアクティベーション)、そのオブジェクトのメソッドが呼び出されるたびに動的に選択することもできます (サーバントの場所)。サーバント ロケータとサーバント アクティベータはどちらも、呼び出しを別のサーバーに転送できます。全体として、このシステムは、複数のマシン間で要求を分散して、負荷を分散する非常に強力な手段を提供します。オブジェクト指向言語では、オブジェクト指向プログラミングの観点からは、 リモートオブジェクトとそのサーバントはどちらもオブジェクトです。

インカネーションとは、サーバントを CORBA オブジェクトに関連付けて、リクエストに応えられるようにする行為です。インカネーションは、仮想 CORBA オブジェクトに具体的なサーバント形式を提供します。アクティブ化と非アクティブ化は CORBA オブジェクトのみを指し、インカネーションとイーサリアライゼーションという用語はサーバントを指します。ただし、オブジェクトとサーバントの有効期間は独立しています。常にサーバントをインカネーションしてから activate_object() を呼び出しますが、その逆も可能です。create_reference() はサーバントをインカネーションせずにオブジェクトをアクティブ化し、サーバントのインカネーションはサーバント マネージャーを使用して後でオンデマンドで実行されます。

のポータブル オブジェクト アダプタ(POA) は、サーバー側のリモート呼び出しハンドラーをリモートオブジェクトとそのサーバント。オブジェクトはリモート呼び出し用に公開され、サーバントには実際に要求を処理するメソッドが含まれています。各オブジェクトのサーバントは、静的 (1 回) または動的 (リモート呼び出しごとに) に選択できます。どちらの場合も、呼び出しを別のサーバーに転送できます。

サーバー側では、POA はツリーのような構造を形成し、各 POA は 1 つ以上のオブジェクトを処理する責任を負います。このツリーのブランチは独立してアクティブ化/非アクティブ化でき、サーバントの場所またはアクティブ化のための異なるコードと、異なる要求処理ポリシーを持ちます。

以下では、分散オブジェクト間の通信を容易にするために CORBA を使用できる最も重要な方法のいくつかについて説明します。

この参照は、文字列化されたUniform Resource Locator (URL)、NameService 検索 (ドメイン ネーム システム(DNS) に類似)を通じて取得されるか、呼び出し中にメソッド パラメーターとして渡されます。

オブジェクト参照は、実際のオブジェクト (リモートまたはローカル) のインターフェースに一致する軽量オブジェクトです。参照に対するメソッド呼び出しにより、ORB への後続の呼び出しが発生し、応答、成功、または失敗を待機している間、スレッドがブロックされます。パラメータ、戻りデータ (ある場合)、および例外データは、ローカル言語と OS マッピングに従って ORB によって内部的にマーシャリングされます。

CORBA インターフェイス定義言語は、言語および OS に依存しないオブジェクト間通信定義を提供します。CORBA オブジェクトは参照渡しされ、データ (整数、倍精度、構造体、列挙型など) は値渡しされます。参照渡しオブジェクトと値渡しデータの組み合わせにより、クライアントとサーバーのコンパイル時に優れたデータ型を適用しながら、CORBA の問題領域に固有の柔軟性を維持する手段が提供されます。

リモート オブジェクトとは別に、CORBA とRMI-IIOP はOBV と Valuetype の概念を定義します。Valuetype オブジェクトのメソッド内のコードは、デフォルトでローカルで実行されます。OBV がリモート側から受信された場合、必要なコードは、双方で事前にわかっているか、送信者から動的にダウンロードされる必要があります。これを可能にするために、OBV を定義するレコードには、このコードをダウンロードするURLのスペース区切りリストであるコード ベースが含まれています。OBV には、リモート メソッドを含めることもできます。

CORBA コンポーネント モデル (CCM) は、CORBA 定義ファミリーに追加されたものです。^{[5]これは CORBA 3 で導入され、CORBA コンポーネントの標準アプリケーション フレームワークを記述します。これは「言語依存の}Enterprise Java Beans (EJB)」に依存しませんが、EJB のより一般的な形式であり、EJB が定義する 2 つのコンポーネント タイプの代わりに 4 つのコンポーネント タイプを提供します。これは、ポートと呼ばれる明確に定義された名前付きインターフェイスを通じてサービスを提供および受け入れることができるエンティティの抽象化を提供します。

CCM には、ソフトウェア コンポーネントを展開できるコンポーネント コンテナーがあります。コンテナーは、コンポーネントが使用できる一連のサービスを提供します。これらのサービスには、通知、認証、永続性、トランザクション処理などが含まれます (ただし、これらに限定されません)。これらは、分散システムに必要な最もよく使用されるサービスであり、これらのサービスの実装をソフトウェア コンポーネントからコンポーネント コンテナーに移動することで、コンポーネントの複雑さが大幅に軽減されます。

ポータブル インターセプタは、CORBA システムの最も重要な機能を仲介するために CORBA およびRMI-IIOPによって使用される「フック」です。CORBA 標準では、次のタイプのインターセプタが定義されています。

1. IORインターセプターは、現在のサーバーによって提示されたリモート オブジェクトへの新しい参照の作成を仲介します。
2. クライアント インターセプターは通常、クライアント (呼び出し元) 側でリモート メソッド呼び出しを仲介します。メソッドが呼び出される同じサーバー上にオブジェクトServant が存在する場合は、ローカル呼び出しも仲介します。
3. サーバー インターセプターは、サーバー (ハンドラー) 側でのリモート メソッド呼び出しの処理を仲介します。

インターセプターは、送信されるメッセージや作成される IOR に特定の情報を添付できます。この情報は、後でリモート側の対応するインターセプターによって読み取ることができます。インターセプターは転送例外をスローして、リクエストを別のターゲットにリダイレクトすることもできます。

GIOPは、オブジェクト リクエスト ブローカー(ORB)が通信する抽象プロトコルです。プロトコルに関連する標準は、Object Management Group (OMG) によって管理されています。GIOP アーキテクチャは、次のようないくつかの具体的なプロトコルを提供します。

1. インターネット InterORB プロトコル (IIOP) – インターネット Inter-ORB プロトコルは、インターネット上で使用するための GIOP の実装であり、GIOP メッセージとTCP/IP層間のマッピングを提供します。
2. SSL InterORB プロトコル (SSLIOP) - SSLIOP は IIOP over SSLであり、暗号化と認証を提供します。
3. HyperText InterORB Protocol (HTIOP) – HTIOP はHTTP上の IIOP であり、透過的なプロキシ バイパスを提供します。
4. Zipped IOP (ZIOP) – 帯域幅の使用量を削減する GIOP の Zipped バージョン。

各標準 CORBA 例外には、例外のサブカテゴリを指定するためのマイナー コードが含まれています。マイナー例外コードは unsigned long 型で、上位 20 ビットを占める 20 ビットの「ベンダー マイナー コードセット ID」(VMCID) と、下位 12 ビットを占めるマイナー コード本体で構成されます。

標準例外のマイナー コードは、OMG に割り当てられた VMCID で始まります。これは、unsigned long 定数 CORBA::OMGVMCID として定義され、OMG に割り当てられた VMCID が上位 20 ビットを占めます。3-58 ページの表 3–13 にある標準例外に関連付けられたマイナー例外コードは、OMGVMCID と OR 演算され、ex_body 構造体に返されるマイナー コード値を取得します (3-52 ページのセクション 3.17.1「標準例外の定義」および 3-58 ページのセクション 3.17.2「標準マイナー例外コード」を参照)。

ベンダーが割り当てたスペース内では、マイナー コードへの値の割り当てはベンダーに委ねられます。ベンダーは、 に電子メールを送信して VMCID の割り当てをリクエストできますtagrequest@omg.org。現在割り当てられている VMCID のリストは、OMG Web サイト (https://www.omg.org/cgi-bin/doc?vendor-tags) で確認できます。

VMCID 0 および 0xfffff は実験的な使用のために予約されています。VMCID OMGVMCID (セクション 3.17.1「標準例外定義」、3-52 ページ) および 1 から 0xf は OMG の使用のために予約されています。

共通オブジェクト リクエスト ブローカー: アーキテクチャと仕様 (CORBA 2.3)

Corba Location (CorbaLoc) は、URL に似た CORBA オブジェクトの文字列化されたオブジェクト参照を指します。

すべての CORBA 製品は、OMG 定義の 2 つの URL、「corbaloc:」と「corbaname:」をサポートする必要があります。これらの目的は、IOR を取得できる場所を指定するために、人間が読み取り可能かつ編集可能な方法を提供することです。

corbaloc の例を以下に示します。

corbaloc::160.45.110.41:38693/StandardNS/ネームサーバ-POA/_root

CORBA 製品は、オプションで「http:」、「ftp:」、および「file:」形式をサポートする場合があります。これらのセマンティクスは、文字列化された IOR をダウンロードする方法 (または、再帰的に、最終的に文字列化された IOR を提供する別の URL をダウンロードする方法) の詳細を提供することです。一部の ORB は、その ORB 専用の追加の形式を提供します。

CORBA の利点には、言語や OS に依存しないこと、テクノロジにリンクされた実装からの解放、強力なデータ型指定、高度な調整可能性、分散データ転送の詳細からの解放などがあります。

言語の独立性

CORBA は、エンジニアが設計を特定のソフトウェア言語に結び付けるという制限から解放されるように設計されています。現在、さまざまな CORBA プロバイダーによって多くの言語がサポートされていますが、最も人気のあるのは Java と C++ です。他にも、C++11、C のみ、Smalltalk、Perl、Ada、Ruby、Python 実装などがあります。

OSに依存しない

CORBA は OS に依存しない設計になっています。CORBA は Java (OS に依存しない) で使用できるほか、Linux/Unix、Windows、Solaris、OS X、OpenVMS、HPUX、Android、LynxOS、VxWorks、ThreadX、INTEGRITY などでもネイティブに使用できます。

テクノロジーからの自由

主な暗黙の利点の 1 つは、CORBA がエンジニアに中立的な場を提供し、さまざまな新しいシステムとレガシー システム間のインターフェイスを標準化できることです。C、C++、Object Pascal、Java、Fortran、Python、およびその他の言語または OS を 1 つのまとまりのあるシステム設計モデルに統合する場合、CORBA は場を平準化し、さまざまなチームがシステムと単体テストを開発して、後でシステム全体に結合できるようにする手段を提供します。これは、スレッド、タイミング、オブジェクトの有効期間などの基本的なシステム エンジニアリングの決定の必要性を排除するものではありません。これらの問題は、テクノロジに関係なく、すべてのシステムの一部です。CORBA を使用すると、システム要素を 1 つのまとまりのあるシステム モデルに標準化できます。
たとえば、 Web サーバーでJava サーブレットを使用し、ビジネス ロジックを含み、データベース アクセスをラップするさまざまな CORBA サーバーを使用すると、多層アーキテクチャの設計が簡単になります。これにより、ビジネス ロジックの実装を変更できるようになりますが、インターフェイスの変更は他のテクノロジと同様に処理する必要があります。たとえば、サーバーによってラップされたデータベースでは、外部インターフェイスに影響を与えることなく、ディスク使用量やパフォーマンスを改善するためにデータベース スキーマを変更することができます (または、データベース ベンダー全体を変更することもできます)。同時に、C++ レガシー コードは、C/Fortran レガシー コードや Java データベース コードと通信し、Web インターフェイスにデータを提供できます。

データ型

CORBA は、"ANY" データ型などの柔軟なデータ型を提供します。また、CORBA は密結合データ型を強制し、人為的エラーを減らします。名前と値のペアが渡される状況では、文字列が期待される場所にサーバーが数値を提供することが考えられます。CORBA インターフェイス定義言語は、ユーザー コードがメソッド名、戻り値、パラメータ タイプ、および例外に準拠していることを保証するメカニズムを提供します。

高い調整可能性

多くの実装（例えばORBexpress（Ada、C++、Java実装）^[6]やOmniORB（オープンソースのC++およびPython実装）^[7]）には、スレッド機能や接続管理機能を調整するためのオプションがあります。すべてのORB実装が同じ機能を提供するわけではありません。

データ転送の詳細からの自由

低レベルの接続とスレッドを処理する場合、CORBA はエラー条件の詳細レベルを提供します。これは、CORBA 定義の標準例外セットと実装固有の拡張例外セットで定義されます。例外を通じて、アプリケーションは、「小さな問題なので再試行してください」、「サーバーがダウンしています」、「参照が意味をなさない」などの理由で呼び出しが失敗したかどうかを判断できます。一般的なルールは、例外を受け取らないということは、メソッド呼び出しが正常に完了したことを意味します。これは非常に強力な設計機能です。

圧縮

CORBA はデータをバイナリ形式でマーシャリングし、圧縮をサポートします。IONA、Remedy IT、Telefónica は、圧縮を実現する CORBA 標準の拡張に取り組んできました。この拡張は ZIOP と呼ばれ、現在は正式な OMG 標準となっています。

CORBAはコードの書き方やソフトウェアの構築方法に多くの貢献をしたが、批判の対象にもなってきた。^[8]

CORBA に対する批判の多​​くは、標準の実装が不十分であることに起因しており、標準自体の欠陥によるものではありません。標準自体の失敗の一部は、CORBA 仕様の作成プロセスと、競合する多くの実装者から調達された共通標準を作成するという政治とビジネスに内在する妥協によるものです。

初期実装の非互換性

CORBA の初期の仕様では、IDL のみが定義されており、伝送フォーマットは定義されていませんでした。そのため、ソース コードの互換性は数年間最高の状態でした。CORBA 2 以降では、この問題は解決されました。

位置情報の透明性

CORBA の位置透過性の概念は批判されてきた。つまり、同じアドレス空間に存在し、単純な関数呼び出しでアクセスできるオブジェクトは、他の場所 (同じマシン上の異なるプロセス、または異なるマシン) に存在するオブジェクトと同じように扱われるということである。これは基本的な設計上の欠陥であり、^{[9] [検証失敗]}、すべてのオブジェクト アクセスが最も複雑なケース (つまり、ローカル呼び出しでは起こり得ない広範囲の障害を伴うリモート ネットワーク呼び出し) と同じくらい複雑になる。また、2 つのクラス間の避けられない違いが隠蔽され、アプリケーションが適切な使用戦略を選択できなくなる (つまり、1  μsのレイテンシと保証された戻り値の呼び出しは、1 秒のレイテンシとトランスポート障害の可能性がある呼び出し (この場合、配信状態は潜在的に不明で、タイムアウトに 30 秒かかる可能性がある) とはまったく異なる方法で使用される)。

設計とプロセスの欠陥

CORBA 標準の作成は、委員会による設計プロセスとしてよく引用されます。相反する提案を仲裁したり、取り組むべき問題の階層を決定するプロセスはありませんでした。したがって、一貫性を考慮せずにすべての提案の機能を統合することによって標準が作成されました。^[10]これにより、仕様は複雑になり、完全に実装するにはコストがかかり、あいまいなことが多かったです。

実装ベンダーと顧客が混在する設計委員会は、多様な利害関係を生み出しました。この多様性により、統一された標準の策定が困難になりました。標準と相互運用性により競争が激化し、顧客が代替実装間を移動しやすくなりました。このため、委員会内で政治的な争いが起こり、CORBA 標準の改訂版が頻繁にリリースされましたが、一部の ORB 実装者は、独自の拡張機能なしでは使用が困難であることを確認しました。^[8]倫理観の低い CORBA ベンダーは、顧客の囲い込みを奨励し、短期的には大きな成果を上げました。時間が経つにつれて、移植性を促進する ORB ベンダーが市場シェアを獲得しました。^[要出典]

実装に関する問題

CORBA はこれまでずっと、貧弱な ORB 実装の欠点に悩まされてきました。残念ながら、標準としての CORBA を批判する論文の多くは、単に CORBA ORB 実装の特に貧弱な点を批判しているだけです。

CORBA は多くの機能を備えた包括的な標準です。仕様のすべてを実装しようとする実装はほとんどなく^[10]、初期の実装は不完全または不十分でした。参照実装を提供するための要件が​​なかったため、メンバーは有用性や実装可能性についてテストされていない機能を自由に提案できました。実装は、標準が一般的に冗長になる傾向と、提出されたすべての提案の合計を採用することで妥協するという一般的な慣行によってさらに妨げられ、個々の提案が完全に合理的であっても、一貫性がなく使いにくい API が作成されることがよくあります。^{[引用が必要]}

CORBA の堅牢な実装は、以前は入手が非常に困難でしたが、現在では簡単に見つかります。SUN Java SDK には CORBA が組み込まれています。設計が不十分な実装の中には、複雑で、遅く、互換性がなく、不完全なものもあることがわかっています。堅牢な商用バージョンが登場し始めましたが、かなりのコストがかかりました。高品質の無料実装が利用可能になると、質の低い商用実装はすぐに消滅しました。

ファイアウォール

CORBA (より正確には、GIOP ) は、特定の通信トランスポートには結び付けられていません。GIOP の特殊化は、インターネット ORB 間プロトコル (IIOP) です。IIOP は、データを送信するために生のTCP/IP接続を使用します。

クライアントが、ポート 80 経由の外部へのHTTP接続のみを許可する非常に制限の厳しいファイアウォールまたは透過プロキシサーバー環境の背後にある場合、問題のプロキシ サーバーがHTTP CONNECTメソッドまたはSOCKS接続も許可していない限り、通信が不可能になる可能性があります。かつては、実装で単一の標準ポートを使用するように強制することさえ困難で、代わりに複数のランダム ポートが選択される傾向がありました。今日では、現在の ORB にはこれらの欠陥があります。このような困難さのため、一部のユーザーはCORBA の代わりにWeb サービスを使用することが増えています。これらのサービスは、通常、HTTP 経由の Web ブラウジング用に組織内の HTTP プロキシを介して開いたままにするかフィルタリングするポート 80 経由で XML / SOAP を使用して通信します。ただし、最近の CORBA 実装はSSL をサポートしており、単一のポートで動作するように簡単に構成できます。TAO、omniORB、JacORB などの一部の ORBS は双方向 GIOP もサポートしており、これにより CORBA は、Web サービス実装のポーリング アプローチ特性ではなく、コールバック通信を使用できるという利点があります。また、最近のファイアウォールのほとんどは GIOP と IIOP をサポートしているため、CORBA 対応のファイアウォールとなっています。

• コンポーネントベースのソフトウェアエンジニアリング
• 分散コンピューティング
• ポータブルオブジェクト
• サービス指向アーキテクチャ(SOA)

• 共通言語インフラストラクチャ– 現在の.NETクロス言語クロスプラットフォーム オブジェクト モデル
• コンポーネント オブジェクト モデル(COM) – Microsoft Windows 専用のクロス言語オブジェクト モデル
• DCOM (分散COM) – COMをネットワークで動作できるようにする拡張機能
• Freedesktop.org D-Bus – 現在のオープンなクロス言語、クロスプラットフォームのオブジェクト モデル
• GNOME Bonobo – 非推奨の GNOME クロス言語オブジェクト モデル
• IBM システム オブジェクト モデルSOM および DSOM – OS/2およびAIXで使用される IBM のコンポーネント システム
• インターネット通信エンジン(ICE)
• Java プラットフォーム、エンタープライズ エディション(Java EE)
• Java リモート メソッド呼び出し(Java RMI)
• JavaBean
• KDE DCOP – 廃止された KDE プロセス間およびソフトウェア コンポーネント通信システム
• KDE KParts – KDE コンポーネント フレームワーク
• オープンエア
• リモート プロシージャ コール(RPC)
• ソフトウェア通信アーキテクチャ(SCA) – 組み込みシステム、クロス言語、クロストランスポート、クロスプラットフォームのコンポーネント
• Windows 通信基盤(WCF)
• XPCOM (クロスプラットフォーム コンポーネント オブジェクト モデル) – Mozilla によって開発され、それに基づくアプリケーション (例: Mozilla Application Suite、SeaMonkey 1.x)向けに提供されています。

• アプリケーションバイナリインターフェース- ABI
• アプリケーション プログラミング インターフェイス- API
• 呼び出し規約
• アプリケーション仮想マシンの比較
• 動的呼び出しインターフェース
• 外部関数インターフェース
• 言語バインディング
• 名前のマングリング
• SWIGオープンソースの自動インターフェースバインディングジェネレーター、多くの言語から多くの言語へ

• 「CORBA」。現在の仕様。OMG。
• ボルトン、フィンタン (2001)。ピュアコルバ。サムズ出版。ISBN 0-672-31812-1。
• Brose, Gerald; Vogel, Andreas; Duddy, Keith (2001 年 1 月 25 日)。Java Programming with CORBA。John Wiley & Sons。ISBN 0-471-37681-7。
• ハーモン、ポール、モリッシー、ウィリアム (1996)。オブジェクトテクノロジーケースブック。ジョン ワイリー アンド サンズ。ISBN 0-471-14717-6。
• Hartman, Bret、Beznosov, hartman、Vinoski, Steve、Flinn, Donald (2001 年 4 月 20 日)。EJBと CORBA によるエンタープライズ セキュリティ。John Wiley & Sons。ISBN 0-471-40131-5。
• Henning, Michi; Vinoski, Steve (1999)。『C++ による高度な CORBA プログラミング』。Addison- Wesley。ISBN 0-201-37927-9。
• コルトハウス、アクセル。シェイダー、マーティン。アレクシー、マルクス（2005年6月22日）。 Java と CORBA を使用した分散システムの実装。スプリンガー。ISBN 3-540-24173-6. 2005年10月31日時点のオリジナルよりアーカイブ。2005年6月23日閲覧。
• Mowbray, Thomas J.; Malveau, Raphael C. (1997). CORBA デザインパターン. John Wiley & Sons. ISBN 0-471-15882-8。
• Mowbray, Thomas J.; Zahavi , Ron (1995)。The Essential Corba: System Integration Using Distributed Objects。John Wiley & Sons。ISBN 0-471-10611-9。
• オルファリ、ロバート (1996)。『クライアント/サーバーサバイバルガイド』。John Wiley & Sons。ISBN 0-471-15325-7。
• オルファリ、ロバート。ハーキー、ダン。エドワーズ、ジェリ (1997)。インスタント CORBA。ジョン・ワイリー＆サンズ。ISBN 0-471-18333-4。
• Orfali, Robert ; Harkey, Dan; Edwards, Jeri (1996)。『エッセンシャル 分散オブジェクト サバイバル ガイド』。John Wiley & Sons。ISBN 0-471-12993-3。
• Orfali, Robert; Harkey, Dan (1998)。JAVAと CORBA によるクライアント/サーバー プログラミング。John Wiley & Sons。ISBN 0-471-24578-X。
• Rosen, Michael ; Curtis, David (1998 年 10 月 13 日)。CORBAとCOM アプリケーションの統合。John Wiley & Sons。ISBN 0-471-19827-7。
• Rosenberger, Jeremy L. (1998)。『14日間でCORBAを独学する』。Sams Publishing。ISBN 0-672-31208-5。
• ジョン・スケッティーノ。ホーマン、ロビン S.オハラ、リズ (1998)。ダミーのための CORBA。ハングリー・マインド。ISBN 0-7645-0308-1。
• シーゲル、ジョン（2000 年 4 月 27 日）。CORBA 3 -基礎とプログラミング。John Wiley & Sons。ISBN 0-471-29518-3。
• シーゲル、ジョン（2001 年 5 月 7 日）。Quick CORBA 3。John Wiley & Sons。ISBN 0-471-38935-8。
• スラマ、ダーク; ガービス、ジェイソン; ラッセル、ペリー (1999)。エンタープライズ CORBA。プレンティス ホール。ISBN 0-13-083963-9。
• Zahavi, Ron (2000)。CORBAによるエンタープライズ アプリケーション統合: コンポーネントおよび Web ベース ソリューション。John Wiley & Sons。ISBN 0-471-32720-4。

Wikibooks にはCORBA プログラミングに関する書籍があります。

• OMG CORBA コンポーネントの公式ページ
• 非公式 CORBA コンポーネント モデル ページ
• IDL と C++ と IDL と C++11 の比較
• CORBA: 消えたが、（願わくば）忘れ去られていない
• OMG XMI仕様