Common Object Request Broker Architecture（コモン オブジェクト リクエスト ブローカー アーキテクチャー、略称CORBA（コルバ））とは、Object Management Group (OMG) が定義した標準規格であり、様々なコンピュータ上で様々なプログラミング言語で書かれたソフトウェアコンポーネントの相互利用を可能にする（分散オブジェクト技術）ものである。
CORBA では、プログラムコードをその機能や呼び出し方の情報と共に一種のカプセル化を行う。このカプセル化されたオブジェクトは、コンピュータネットワークを経由して他のプログラム（あるいは CORBA オブジェクト）から呼び出すことができる。
CORBA はインタフェース記述言語 (IDL) を使ってこのようなオブジェクトの外部インタフェースを記述する。そして、IDLから他の特定の実装言語（C++やJava）への「マッピング」を行う。CORBAとしてマッピングが標準的に用意されているのは、Ada、C、C++、LISP、Smalltalk、Java、COBOL、PL/I、Python である。標準に組み込まれていないが、Perl、PHP、Ruby、Visual Basic、Tcl、Delphi へのマッピングを実装したObject Request Brokerが存在する。
下図はCORBA基盤で生成されたコードが使われる様子を示したものである。
この図は非常に単純化してある。通常、サーバ側には Portable Object Adapter があり、呼び出しをローカルなサーバントに渡すか（負荷分散のために）他のサーバに転送する。また、サーバ側にもクライアント側にも後述するインターセプターが存在することが多い。
ユーザーに対して言語やプラットフォームに依存しない遠隔手続き呼出し (RPC) 仕様を提供する以外に、CORBAはトランザクションやセキュリティに必要な一般的サービスを定義している。
リモートオブジェクトとは別に、CORBAとRMI-IIOPはOBVの概念を定義している。オブジェクト内のメソッドのコードはデフォルトではローカルに実行される。OBVをリモートから受信する場合、必要なコードが両者に事前に備えられているか、送信側から動的にダウンロードしなければならない。このため、コードをダウンロードできるURL群の（空白で区切った）リストである Code Base が OBV を定義するレコードに含まれている。OBV はリモートメソッドを持つこともできる。
OBV は転送される際に付属して転送されるフィールドを持つことがある。そのフィールドにはOBV自体、構成リスト、木構造やグラフなどが含まれる。OBVにはクラス階層があり、多重継承や抽象クラスもある。
CORBA Component Model (CCM) は CORBA 仕様の追加要素である。 CORBA 3 で導入された。これはCORBAコンポーネントの標準アプリケーションフレームワークを記述したものである。それはちょうど「言語に依存しない」Enterprise JavaBeans(EJB)の拡張版である。「ポート」と呼ばれる明確な名前付きのインタフェースを通してサービスのやりとりができる実体を抽象化したものである。
CCM にはコンポーネントコンテナがあり、その中にソフトウェアコンポーネントが置かれる。コンテナは内包するコンポーネントに各種サービスを提供する。例えば、通知、認証、永続性、トランザクション管理などがある。これらは分散システムには必須のサービスであり、その実装をソフトウェアコンポーネントからコンテナに移すことによってコンポーネントの複雑さは劇的に軽減される。
ポータブルなインターセプターとは、CORBAやRMI-IIOPが使用するCORBAシステムの最重要機能の「フック」である。CORBA標準では以下のようなタイプのインターセプターを定義している:
インターセプターは、送信されるメッセージに何らかの情報や生成したIORを付加することができる。それらの情報はリモート側の対応するインターセプターが読み取る。インターセプターは例外を送ったり、メッセージを他のターゲットに転送したりといったことも行う。
GIOPとは、Object Request Broker(ORB)同士が通信する際の抽象プロトコルである。このプロトコルに関する標準はObject Management Group(OMG)が管理保守している。GIOPアーキテクチャはいくつかの実際のプロトコルを提供している:
Object Management Group (OMG) は関連する標準規格としてData Distribution Service (DDS) 標準を制定している。DDS は出版-購読（publish-subscribe）型データ配信モデルであり、対照的にCORBAはリモート呼び出しオブジェクトモデルである。
標準CORBAは例外のサブカテゴリーを明示するためにマイナーコードを明記している。マイナー例外コードは unsigned long 型で、上位20ビットは “Vendor Minor Codeset ID”(VMCID)、下位12ビットがマイナーコード本体である。標準例外のマイナーコードには OMG が予約する VMCID の付与された形で unsigned long 型の定数 CORBA::OMGVMCID として定義される。従って、マイナー例外コードは OMGVMCID と OR された形で ex_body 構造体に格納されている。
マイナーコードの設定はベンダー依存である。VMCID の割り当て要求は、[email protected] に電子メールを送ればよい。VMCID のうち、0 と 0xfffff は実験用の予約されている。また、OMGVMCID と 1 から 0xf までの VMCID は OMG が予約している。
CorbaLoc とは、Corba Location の略であり、CORBA オブジェクトへの参照を文字列で表したものである。その見た目はURLによく似ている。CORBA製品には OMGが定義した二種類のURL、"corbaloc:" と "corbaname:" をサポートしている。その目的は、IORを持つ場所を指定するに当たって、人間がそれを読んで編集できる方法を提供することである。
CobaLoc の例を以下に示す:
CORBA製品はオプションとして "http:"、"ftp:"、"file:" をサポートするものもある。これらは、文字列化されたIORのダウンロード方法の詳細を提供するために存在する（または、再帰的に他のURLをダウンロードすることによって文字列化されたIORが得られるようにしている）。
CORBA、IIOP、OMG は Object Management Group の登録商標であり、利用には注意が必要である。GIOP は登録商標ではない。従って、アプリケーションについて「GIOPに基づいたアーキテクチャである」とするのが適切な場合もあるだろう。なお、CORBAの仕様書自体に関しては、それに基づいた実装を自由に行うことは（CORBAという登録商標を使わないかぎり）許されている。