Common Object RequestBrokerアーキテクチャ

Common_Object_Request_Broker_Architecture

共通オブジェクト・リクエスト・ブローカ・アーキテクチャ（CORBAは）あり、標準で定義されたオブジェクト管理グループの多様なプラットフォーム上で展開されているシステムの通信を容易にするために設計された（OMG）。CORBAは、異なるオペレーティングシステム、プログラミング言語、およびコンピューティングハードウェア上のシステム間のコラボレーションを可能にします。CORBAはオブジェクト指向モデルを使用しますが、CORBAを使用するシステムはオブジェクト指向である必要はありません。CORBAは、分散オブジェクトパラダイムの例です。
Common Object RequestBrokerアーキテクチャCORBA
状態
公開済み
年が始まった
1991 ; 31年前 （1991）
最新バージョン
3.4 2021年2月; 11ヶ月前 （2021-02）
組織
オブジェクト管理グループ
Webサイト
corba .org

コンテンツ
1 概要
2 バージョン履歴
3 使用人
4 特徴
4.1 参照によるオブジェクト 4.2 値によるデータ 4.3 値によるオブジェクト（OBV） 4.4 CORBAコンポーネントモデル（CCM） 4.5 ポータブル迎撃機 4.6 General InterORB Protocol（GIOP） 4.7 VMCID（ベンダーマイナーコードセットID） 4.8 チョルバロケーション（CorbaLoc）
5 利点
6 問題と批判
7 も参照してください
7.1 ソフトウェア工学 7.2 コンポーネントベースのソフトウェアテクノロジー 7.3 言語バインディング
8 参考文献
9 参考文献
10 外部リンク

概要
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）。
CORBA仕様では、アプリケーションが他のオブジェクトと対話するためのORBが存在する必要がこれが実際の実装方法です。
アプリケーションはORBを初期化し、内部オブジェクトアダプターにアクセスします。このアダプターは、参照カウント、オブジェクト（および参照）インスタンス化ポリシー、オブジェクト存続期間ポリシーなどを維持します。
オブジェクトアダプタは、生成されたコードクラスのインスタンスを登録するために使用されます。生成されたコードクラスは、ユーザー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インフラストラクチャ内でどのように使用されるかを示しています。
Illustration
  この図は、CORBAを使用したリモートプロセス間通信の高レベルのパラダイムを示しています。CORBA仕様は、データの入力、例外、ネットワークプロトコル、通信タイムアウトなどにさらに対応しています。例：通常、サーバー側には、呼び出しをローカルサーバントまたは（負荷のバランスを取るために）にリダイレクトするポータブルオブジェクトアダプター（POA）が他のサーバー。CORBA仕様（したがってこの図）は、分散システムのさまざまな側面をアプリケーションに任せて、オブジェクトの存続期間（参照カウントのセマンティクスはアプリケーションで使用できます）、冗長性/フェイルオーバー、メモリ管理、動的負荷分散、アプリケーションなどを定義します。表示/データ/制御セマンティクス間の分離などの指向モデル（たとえば、モデル-ビュー-コントローラーを参照）など。
CORBAは、言語とプラットフォームに依存しないリモートプロシージャコール（RPC）仕様をユーザーに提供するだけでなく、トランザクションとセキュリティ、イベント、時間、その他のドメイン固有のインターフェイスモデルなどの一般的に必要なサービスを定義します。

バージョン履歴
この表は、CORBA標準バージョンの履歴を示しています。
バージョン バージョン日付 ハイライト 1.0 1991年10月
最初のバージョン、Cマッピング 1.1 1992年2月
相互運用性、C ++マッピング 1.2 1993年12月- 2.0
1996年8月
標準の最初のメジャーアップデート、これもCORBA2と呼ばれます 2.1 1997年8月- 2.2
1998年2月
Javaマッピング 2.3 1999年6月- 2.4
2000年8月- 2.5
2001年9月 – 2.62.6
2001年12月- 3.0
2002年7月
標準の2番目のメジャーアップデートで、CORBA 3 CORBAコンポーネントモデル（CCM）とも呼ばれます。
3.0.1
2002年11月 – 3.0.2
2002年12月 – 3.0.3
2004年3月- 3.1
2008年1月 – 3.1.1
2011年8月
ISO / IEC19500の2012年版として採用 3.2 2011年11月- 3.3
2012年11月
ZIOPの追加
3.43.4 2021年2月

使用人
使用人は、リモートメソッド呼び出しを処理するためのメソッドを含む呼び出しターゲットです。新しいCORBAバージョンでは、リモートオブジェクト（サーバー側）は、オブジェクト （リモート呼び出しに公開される）とサーバント （前の部分がメソッド呼び出しを転送する）に分割されます。リモートオブジェクトごとに1つのサーバントにすることも、同じサーバントが特定のポータブルオブジェクトアダプタに関連付けられた複数の（場合によってはすべての）オブジェクトをサポートすることもできます。各オブジェクトのサーバントは、 「1回限り」（サーバントのアクティブ化）に設定または検出するか、そのオブジェクトのメソッドが呼び出されるたびに動的に選択することができます（サーバントの場所）。使用人ロケーターと使用人アクティベーターの両方が、呼び出しを別のサーバーに転送できます。全体として、このシステムは、負荷を分散し、複数のマシン間で要求を分散するための非常に強力な手段を提供します。オブジェクト指向言語では、リモートオブジェクトとその使用人の両方がオブジェクト指向プログラミングの観点からのオブジェクトです。
インカネーションとは、使用人をCORBAオブジェクトに関連付けて、要求を処理できるようにする行為です。Incarnationは、仮想CORBAオブジェクトの具体的なサーバントフォームを提供します。アクティブ化と非アクティブ化はCORBAオブジェクトのみを指し、化身とエーテル化という用語は使用人を指します。ただし、オブジェクトと使用人の寿命は独立しています。activate_object（）を呼び出す前に、常にサーバントをインカネートしますが、その逆も可能です。create_reference（）は、サーヴァントをインカネートせずにオブジェクトをアクティブ化し、サーバントのインカネーションは、後でサーバントマネージャを使用してオンデマンドで実行されます。
The Portable Object Adapter （POA）は、サーバー側のリモート呼び出しハンドラーをリモートオブジェクトとそのサーバントに分割するCORBAオブジェクトです。オブジェクトはリモート呼び出しに対して公開されますが、サーバントには実際にリクエストを処理しているメソッドが含まれています。各オブジェクトのサーバントは、静的（1回）または動的（リモート呼び出しごと）のいずれかで選択できます。どちらの場合も、別のサーバーへのコール転送が可能です。
サーバー側では、POAはツリーのような構造を形成し、各POAは提供される1つ以上のオブジェクトを担当します。このツリーのブランチは、個別にアクティブ化/非アクティブ化でき、サーバントの場所またはアクティブ化に異なるコードを持ち、異なる要求処理ポリシーを持ちます。

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

参照によるオブジェクト
この参照は、文字列化されたURL（ Uniform Resource Locator）、NameServiceルックアップ（ドメインネームシステム（DNS）と同様）を介して取得されるか、呼び出し中にメソッドパラメーターとして渡されます。
オブジェクト参照は、実際のオブジェクト（リモートまたはローカル）のインターフェイスに一致する軽量オブジェクトです。参照に対するメソッド呼び出しは、ORBへの後続の呼び出しを引き起こし、応答、成功、または失敗を待機している間、スレッドをブロックします。パラメータ、戻りデータ（存在する場合）、および例外データは、ローカル言語とOSマッピングに従ってORBによって内部的にマーシャリングされます。

値によるデータ
CORBAインターフェイス定義言語は、言語およびOSに依存しないオブジェクト間通信定義を提供します。CORBAオブジェクトは参照によって渡されますが、データ（整数、倍精度浮動小数点数、構造体、列挙型など）は値によって渡されます。参照によるオブジェクトと値によるデータの組み合わせは、クライアントとサーバーのコンパイル中に優れたデータ入力を強制する手段を提供しますが、CORBA問題空間に固有の柔軟性を維持します。

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

CORBAコンポーネントモデル（CCM）
CORBAコンポーネントモデル（CCM）は、CORBA定義のファミリーに追加されたものです。 CORBA 3で導入され、CORBAコンポーネントの標準アプリケーションフレームワークについて説明しています。「言語依存のEnterpriseJava Beans（EJB）」には依存しませんが、EJBのより一般的な形式であり、EJBが定義する2つではなく4つのコンポーネントタイプを提供します。これは、ポートと呼ばれる明確に定義された名前付きインターフェースを介してサービスを提供および受け入れることができるエンティティの抽象化を提供します。
CCMには、ソフトウェアコンポーネントを展開できるコンポーネントコンテナがコンテナは、コンポーネントが使用できる一連のサービスを提供します。これらのサービスには、通知、認証、永続性、トランザクション処理が含まれます（ただし、これらに限定されません）。これらは、分散システムが必要とする最もよく使用されるサービスであり、これらのサービスの実装をソフトウェアコンポーネントからコンポーネントコンテナに移動することにより、コンポーネントの複雑さが大幅に軽減されます。

ポータブル迎撃機
ポータブルインターセプターは「フック」であり、CORBAおよびRMI-IIOPがCORBAシステムの最も重要な機能を仲介するために使用します。CORBA標準では、次のタイプのインターセプターが定義されています。
IORインターセプターは、現在のサーバーによって提示されるリモートオブジェクトへの新しい参照の作成を仲介します。
クライアントインターセプターは通常、クライアント（呼び出し元）側でリモートメソッド呼び出しを仲介します。オブジェクトServantがメソッドが呼び出されるのと同じサーバーに存在する場合、それらはローカル呼び出しも仲介します。
サーバーインターセプターは、サーバー（ハンドラー）側でリモートメソッド呼び出しの処理を仲介します。
インターセプターは、送信されるメッセージと作成されるIORに特定の情報を添付できます。この情報は、後でリモート側の対応するインターセプターで読み取ることができます。インターセプターは、転送例外をスローして、要求を別のターゲットにリダイレクトすることもできます。

General InterORB Protocol（GIOP）
一般的なORB間プロトコル
GIOPは、オブジェクトリクエストブローカ（ORB）が通信するための抽象プロトコルです。プロトコルに関連付けられている標準は、Object Management Group（OMG）によって維持されています。GIOPアーキテクチャは、次のようないくつかの具体的なプロトコルを提供します。
インターネットInterORBプロトコル（IIOP）–インターネットInter-Orbプロトコルは、インターネット上で使用するためのGIOPの実装であり、 GIOPメッセージとTCP / IP層の間のマッピングを提供します。
SSL InterORBプロトコル（SSLIOP）– SSLIOPは、SSLを介したIIOPであり、暗号化と認証を提供します。
HyperText InterORBプロトコル（HTIOP）–HTIOPはIIOPover HTTPであり、透過的なプロキシバイパスを提供します。
圧縮IOP（ZIOP）–帯域幅の使用量を削減する圧縮バージョンのGIOP。

VMCID（ベンダーマイナーコードセットID）
各標準CORBA例外には、例外のサブカテゴリを指定するためのマイナーコードが含まれています。マイナー例外コードはunsignedlong型であり、上位20ビットを占める20ビットの「ベンダーマイナーコードセットID」（VMCID）と、下位12ビットを占める適切なマイナーコードで構成されます。
標準例外のマイナーコードの前には、OMGに割り当てられたVMCIDがこれは、符号なしの長い定数CORBA :: OMGVMCIDとして定義され、OMGに割り当てられたVMCIDが上位20ビットを占めます。3-58ページの表3–13にある標準例外に関連付けられたマイナー例外コードは、OMGVMCIDと連携して、ex_body構造体で返されるマイナーコード値を取得します（セクション3.17.1「標準」を参照）。例外の定義」（3-52ページ）およびセクション3.17.2「標準のマイナー例外コード」（3-58ページ）。
ベンダーが割り当てたスペース内では、マイナーコードへの値の割り当てはベンダーに任されています。ベンダーは、tagrequest @ omg.orgに電子メールを送信してVMCIDの割り当てを要求できます。現在割り当てられているVMCIDのリストは、OMG Webサイト（http://www.omg.org/cgi-bin/doc?vendor-tags ）に
VMCID 0および0xfffffは、実験的な使用のために予約されています。VMCID OMGVMCID（セクション3.17.1、「標準例外定義」、3-52ページ）および1から0xfは、OMGで使用するために予約されています。
Common Object Request Broker：アーキテクチャと仕様（CORBA 2.3）

チョルバロケーション（CorbaLoc）
Corba Location（CorbaLoc）は、URLに似たCORBAオブジェクトの文字列化されたオブジェクト参照を参照します。
すべてのCORBA製品は、OMGで定義された2つのURL「corbaloc：」および「 corbaname：」をサポートする必要がこれらの目的は、IORを取得できる場所を指定するための人間が読める形式と編集可能な方法を提供することです。
corbalocの例を以下に示します。
corbaloc :: 160.45.110.41：38693 / StandardNS / NameServer-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を単一のまとまりのあるシステム設計モデルに統合する場合、CORBAは、フィールドを平準化し、異なるチームが後で使用できるシステムとユニットテストを開発できるようにする手段を提供します。システム全体に結合されます。これは、スレッド化、タイミング、オブジェクトの有効期間などの基本的なシステムエンジニアリングの決定の必要性を排除するものではありません。これらの問題は、テクノロジに関係なく、システムの一部です。CORBAを使用すると、システム要素を単一のまとまりのあるシステムモデルに正規化できます。
たとえば、
多層アーキテクチャの設計は、WebサーバーのJavaサーブレットと、ビジネスロジックを含みデータベースアクセスをラップするさまざまなCORBAサーバーを使用して簡単
になります。これにより、ビジネスロジックの実装を変更できますが、インターフェイスの変更は他のテクノロジと同様に処理する必要がたとえば、サーバーによってラップされたデータベースは、外部インターフェイスに影響を与えることなく、ディスクの使用量やパフォーマンスを向上させるために（またはデータベースベンダー全体を変更するために）データベーススキーマを変更できます。同時に、C ++レガシーコードはC / FortranレガシーコードおよびJavaデータベースコードと通信でき、Webインターフェイスにデータを提供できます。
データタイピング
CORBAは、「ANY」データ型などの柔軟なデータ型を提供します。CORBAはまた、密結合のデータタイピングを実施し、人的エラーを減らします。名前と値のペアが渡される状況では、サーバーが文字列が期待された場所に番号を提供すると考えられます。CORBAインターフェイス定義言語は、ユーザーコードがメソッド名、戻り値、パラメーター型、および例外に準拠していることを確認するメカニズムを提供します。
高い調整可能性
多くの実装（例：ORBexpress（Ada、C ++、およびJava実装）
およびOmniORB（オープンソースC ++およびPython実装））
には、スレッド化および接続管理機能を調整するためのオプションがすべてのORB実装が同じ機能を提供するわけではありません。
データ転送の詳細からの自由
低レベルの接続とスレッド化を処理する場合、CORBAはエラー状態で高レベルの詳細を提供します。これは、CORBA定義の標準例外セットおよび実装固有の拡張例外セットで定義されています。例外を通じて、アプリケーションは、「小さな問題です。再試行してください」、「サーバーが停止しています」、「参照が意味をなさない」などの理由で呼び出しが失敗したかどうかを判断できます。一般的なルールは次のとおりです。例外を受け取らないということは、メソッド呼び出しが正常に完了したことを意味します。これは非常に強力な設計機能です。
圧縮
CORBAは、データをバイナリ形式でマーシャリングし、圧縮をサポートします。IONA、Remedy IT、および
Telefónicaは、圧縮を提供するCORBA標準の拡張に取り組んできました。この拡張機能はZIOPと呼ばれ、正式なOMG標準になりました。

問題と批判
CORBAは、コードの記述とソフトウェアの構築の方法で多くのことを実現しましたが、批判の対象となってきました。
CORBAに対する批判の多​​くは、標準の実装が不十分であることに起因しており、標準自体の欠陥ではありません。標準自体の失敗のいくつかは、CORBA仕様が作成されたプロセスと、多くの競合する実装者によって提供された共通の標準を作成するという政治とビジネスに固有の妥協によるものでした。
初期実装の非互換性
CORBAの初期仕様では、IDLのみが定義されており、オンザワイヤ形式は定義されこれは、ソースコードの互換性が数年間利用可能な最高のものであることを意味しました。CORBA 2以降では、この問題は解決されました。
場所の透明性
CORBAのロケーションの透明性の概念は批判されています。つまり、同じ
アドレススペースにあり、単純な関数呼び出しでアクセスできる
オブジェクトは、他の場所にあるオブジェクト（同じマシン上の異なるプロセス、または異なるマシン）と同じように扱われます。これは基本的な設計上の欠陥であり、
は、すべてのオブジェクトアクセスを最も複雑なケース（つまり、ローカルコールでは不可能な幅広いクラスの障害を伴うリモートネットワークコール）と同じくらい複雑にするためです。また、2つのクラス間の避けられない違いを隠し、アプリケーションが適切な使用戦略を選択できないようにします（つまり、1
µsの遅延と保証されたリターンの呼び出しは、トランスポート障害の可能性がある1sの遅延の呼び出しとは非常に異なる方法で使用されます。 、配信ステータスが不明である可能性があり、タイムアウトになるまでに30秒かかる場合があります）。
設計とプロセスの欠陥
CORBA標準の作成は、委員会による設計
プロセスでもよく引用され相反する提案の間で仲裁したり、取り組むべき問題の階層を決定したりするプロセスはありませんでした。したがって、この標準は、一貫性に関係なく、すべての提案の機能を統合することによって作成されました。
これにより、仕様が複雑になり、完全に実装するにはコストがかかり、多くの場合あいまいになりました。
実装ベンダーと顧客が混在する設計委員会は、さまざまな関心を生み出しました。この多様性は、まとまりのある基準を難しくしました。標準と相互運用性により、競争が激化し、代替実装間の顧客の移動が容易になりました。これにより、委員会内で多くの政治的争いが発生し、一部のORB実装者が独自の拡張なしでは使用が困難であると保証したCORBA標準の改訂版が頻繁にリリースされました。
倫理性の低いCORBAベンダーは、顧客のロックインを奨励し、強力な短期的な結果を達成しました。時間の経過とともに、移植性を促進するORBベンダーが市場シェアを引き継ぎました。
実装に関する問題
その歴史を通じて、CORBAは不十分なORB実装の欠点に悩まされてきました。残念ながら、CORBAを標準として批判する論文の多くは、特に悪いCORBAORBの実装に対する批判にすぎません。
CORBAは、多くの機能を備えた包括的な標準です。すべての仕様を実装しようとする実装はほとんどなく
、初期の実装は不完全または不十分でした。リファレンス実装を提供するための要件が​​なかったため、メンバーは、有用性や実装可能性についてテストされたことのない機能を自由に提案できました。実装は、標準が冗長になるという一般的な傾向と、提出されたすべての提案の合計を採用することによる妥協の一般的な慣行によってさらに妨げられました。これにより、個々の提案が完全に合理的であっても、一貫性がなく使用が困難な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）

コンポーネントベースのソフトウェアテクノロジー
Freedesktop.org D-Bus –現在のオープンなクロス言語クロスプラットフォームオブジェクトモデル
GNOME Bonobo –非推奨のGNOMEクロスランゲージオブジェクトモデル
KDE DCOP –非推奨のKDEプロセス間およびソフトウェアコンポーネント通信システム
KDE KParts –KDEコンポーネントフレームワーク
コンポーネントオブジェクトモデル（COM）– MicrosoftWindowsのみのクロスランゲージオブジェクトモデル
DCOM（分散COM）–COMがネットワークで機能できるようにする拡張機能
共通言語インフラストラクチャ–現在の.NETクロス言語クロスプラットフォームオブジェクトモデル
XPCOM（クロスプラットフォームコンポーネントオブジェクトモデル）–それをベースにしたアプリケーション（Mozilla Application Suite、SeaMonkey 1.xなど）のためにMozillaによって開発されました
IBMシステム・オブジェクト・モデルSOMおよびDSOM – OS / 2およびAIXで使用されるIBMのコンポーネント・システム
インターネット通信エンジン（ICE）
Javaリモートメソッド呼び出し（Java RMI）
Javaプラットフォーム、Enterprise Edition（Java EE） JavaBean オープンエア
リモートプロシージャコール（RPC）
Windows Communication Foundation（WCF）
ソフトウェアコミュニケーションアーキテクチャ（SCA）–組み込みシステム、クロスランゲージ、クロストランスポート、クロスプラットフォーム用のコンポーネント

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

参考文献
^ 「CORBAの歴史」。Object ManagementGroup 。
^ 「CORBAの歴史」。Object ManagementGroup 。
^ 「CORBAコンポーネントモデル」。ドブ博士の日記。2004年9月1日。
^ 「ORBexpress：リアルタイムCORBAORB」。
^ “”omniORB：無料のCORBAORB””。sourceforge.net 。
^ Chappel、David（1998年5月）。「CORBAのトラブル」。davidchappel.com。2012年12月3日にオリジナルからアーカイブされました。
^ ウォルド、ジム; Geoff Wyant; アン・ウォルラス; サムケンダル（1994年11月）。「分散コンピューティングに関する注記」（PDF）。サンマイクロシステムズラボラトリーズ。
^ ヘニング、ミチ（2006年6月30日）。「CORBAの興亡」。ACMキュー。コンピューティングマシナリー協会。4（5）：28–34。土井：10.1145 /1142031.1142044。S2CID12103742 。_  

参考文献
「CORBA」。現在。仕様。OMG。
Orfali、Robert（1996）。Essential Client / Server SurvivalGuide。ジョン・ワイリー＆サンズ。ISBN 0-471-15325-7。
オルファリ、ロバート; ハーキー、ダン; エドワーズ、ジェリ（1996）。Essential Distributed Objects SurvivalGuide。ジョン・ワイリー＆サンズ。ISBN 0-471-12993-3。
オルファリ、ロバート; ハーキー、ダン（1998）。JAVAおよびCORBAを使用したクライアント/サーバープログラミング。ジョン・ワイリー＆サンズ。ISBN 0-471-24578-X。
スラマ、ダーク; ガービス、ジェイソン; ラッセル、ペリー（1999）。エンタープライズCORBA。プレンティスホール。ISBN 0-13-083963-9。
ヘニング、ミチ; Vinoski、Steve（1999）。C ++を使用した高度なCORBAプログラミング。アディソン-ウェスリー。ISBN 0-201-37927-9。
Korthaus、Axel; シェーダー、マーティン; Aleksy、Markus（2005年6月22日）。JavaとCORBAを使用した分散システムの実装。スプリンガー。ISBN 3-540-24173-6。2005年10月31日にオリジナルからアーカイブされました。
ボルトン、フィンタン（2001）。純粋なコルバ。サムズパブリッシング。ISBN 0-672-31812-1。
シーゲル、ジョン（2000年4月27日）。CORBA3-基礎とプログラミング。ジョン・ワイリー＆サンズ。ISBN 0-471-29518-3。
ザハヴィ、ロン（2000）。エンタープライズアプリケーションとCORBAの統合：コンポーネントおよびWebベースのソリューション。ジョン・ワイリー＆サンズ。ISBN 0-471-32720-4。
ハートマン、ブレット; ベズノソフ、ハートマン; ヴィノスキー、スティーブ; フリン、ドナルド（2001年4月20日）。EJBとCORBAを使用したエンタープライズセキュリティ。ジョン・ワイリー＆サンズ。ISBN 0-471-40131-5。
モーブレー、トーマスJ。; ザハヴィ、ロン（1995）。Essential Corba：分散オブジェクトを使用したシステム統合。ジョン・ワイリー＆サンズ。ISBN 0-471-10611-9。
ローゼン、マイケル; カーティス、デビッド（1998年10月13日）。CORBAアプリケーションとCOMアプリケーションの統合。ジョン・ワイリー＆サンズ。ISBN 0-471-19827-7。
ブロス、ジェラルド; フォーゲル、アンドレアス; ダディ、キース（2001年1月25日）。CORBAを使用したJavaプログラミング。ジョン・ワイリー＆サンズ。ISBN 0-471-37681-7。
スケッティーノ、ジョン; ホーマン、ロビンS。; オハラ、リズ（1998）。ダミーのためのCORBA。空腹の心。ISBN 0-7645-0308-1。
ローゼンバーガー、ジェレミーL.（1998）。14日でCORBAを教えてサムズパブリッシング。ISBN 0-672-31208-5。
シーゲル、ジョン（2001年5月7日）。クイックCORBA3。ジョン・ワイリー＆サンズ。ISBN 0-471-38935-8。
モーブレー、トーマスJ。; Malveau、Raphael C.（1997）CORBAデザインパターン。ジョン・ワイリー＆サンズ。ISBN 0-471-15882-8。
オルファリ、ロバート; ハーキー、ダン; エドワーズ、ジェリ（1997）。インスタントCORBA。ジョン・ワイリー＆サンズ。ISBN 0-471-18333-4。
ハーモン、ポール; モリッシー、ウィリアム（1996）。オブジェクトテクノロジーの事例集。ジョン・ワイリー＆サンズ。ISBN 0-471-14717-6。

外部リンク
ウィキブックスには、CORBAプログラミングに関する本が
OMGCORBAコンポーネントの公式ページ
非公式のCORBAコンポーネントモデルページ
IDLからC ++とIDLからC ++ 11の比較
チョルバ：なくなったけど（うまくいけば）忘れられない
OMGXMI仕様

「https://en.wikipedia.org/w/index.php?title=Common_Object_Request_Broker_Architecture&oldid=1060758011」
から取得”