ORB是一個中間件(middleware)，它可以建立對象之間的client/server關系。通過ORB，一個client可以透明的引用同一臺機器上或網絡上的一個server對象的方法。ORB解釋該調用并負責查找一個實現該請求的對象，找到后，把參數傳給該對象，調用它的方法，最后返回結果。client并不清楚該對象的位置，它的編程語言，它的操作系統以及其它不是對象接口的系統信息。 ORB能實現分布環境中位于不同機器上的應用之間的互操作以及多對象系統之間的無縫連接。
在傳統的client/server)應用中，開發者使用自己設計的標準或通用標準來定義設備之間的協議。協議定義與實現的語言、網絡傳輸及其它因素有關。ORB簡化了這一過程，它使用IDL來定義應用接口之間的協議。ORB允許程序員選擇通用操作系統,運行環境和編程語言。更重要的是，它能集成現存元素。
ORB結構
圖 1 通過ORB傳遞請求
圖1顯示了一個client向對象實現發送一個請求。Client是一個想對對象進行操作的一個實體，對象實體是實現對象的代碼和數據。ORB負責根據一個請求來定位一個對象，安排對象實現準備接受請求，與請求的數據通訊。Client的接口與對象的位置完全，實現對象的語言及其它不在對象接口反映出來的方面等無關。
圖2顯示了單個ORB的結構。用斜條文的矩形框表示ORB的接口, 箭頭表示調用ORB或ORB使用接口把信息向上傳遞。
圖2 ORB接口結構
Clinet使用Dynamic Invocation interface (與目標對象的接口無關)或OMG IDL stub (與目標對象接口有關的stub)來發出請求。由于某種原因，Client也可以直接與ORB聯系。對象實現使用OMG IDL生成的skeleton或動態 skeleton以向上傳送（up-call）的方式接受請求。對象實現也可以調用Object Adapter和ORB。可以用兩種方式來定義對象接口：一是用OMG Interface Definition Language (OMG IDL)來定義接口。該語言根據可能對對象進行的操作和這些操作使用的參數來定義對象類型。第二種方法是，把接口（interface）放入Interface Repository service中; 該服務把接口中的元素描述成一個對象。任何能實現ORB的軟件中，Interface Definition Language (可能根據文檔的內容而改變)和Interface Repository具有相同的作用。一個client要使用Object Reference完成請求，它必須知道對象的類型的及具體的操作。Client初始化請求有兩種方法，一是通過調用目標對象的stub routines，二是動態的創造請求（如圖3所示）。
圖 3 Client使用Stub 或Dynamic Invocation Interface
不論使用Stub還是Dynamic Invocation Interface來發出請求具有相同的語義，信息的接收者不能分辨出該請求是使用哪種方法來傳遞的。ORB確定適當的實現代碼，傳遞參數，通過IDL skeleton或dynamic skeleton (如圖Figure 4 所示)把控制傳給Object Implementation。每一個接口和object adapter 使用不同的Skeletons。為了完成請求，object implementation 可能通過Object Adapter 使用來自ORB的服務。當完成請求后，控制和輸出結果返回給client。
圖4 Object Implementation 接受請求 Object Implementation選擇使用何種Object Adapter。它是根據Object Implementation 需要服務的種類來確定的。圖5 顯示了clients和object implementations如何使用接口和實現信息。用OMG IDL或Interface Repository來定義接口；該定義用于產生client Stubs和object implementation Skeletons。
圖 5 Interface 和 Implementation Repositories
在安裝時把object implementation 信息放入Implementation Repository中，以備請求使用。
ORB結構中的主要構件
圖6.1 CORBA ORB結構
1) Object Implementation(對象實現): 它定義了實現一個CORBA IDL接口的操作。它可以用各種語言來寫，如C, C++, Java, Smalltalk和Ada。
圖6.2 典型的Object Implementation 結構
2) Client(客戶): 這是一個程序實體，它調用了某一個對象實現中操作。對調用這來講，訪問遠程對象server應該是透明的。它應該和調用對象中的方法一樣簡單，如，obj->op(args)。
Client只能根據對象的接口了解對象的邏輯結構，雖然，我們一般都把client看作是一個程序或一個進程，但是，知道一個client都是某一個對象有關的。例如，一個對象的實現可能是其他對象的client。
圖 7 典型的Client結構 Client通過語言映射（language mapping）來使用對象和ORB 接口。當這種映射關系改變時，不需要改變Client。Client不需要了解對象的實現方式，對象適配器及ORB。
3) Object Request Broker(ORB):
ORB提供了一種機制，能實現client請求與目標對象實現之間的透明通信。它使得client請求就象一個本地過程調用一樣。當一個client引用一個操作，ORB負責找到對象實現，如果需要則透明的激活它，然后把該請求遞交給該對象，最后返回應答給調用者。實現時，可以把ORB不作為單個成分，但它只能由它的接口來定義。任何ORB實現方式提供的接口都是可以接受的。可以把接口中的操作分為三類：
1. 對于所有的ORB實現都一樣的操作
2. 特定類型對象的操作
3. 與對象實現種特定類別有關的操作
不同的ORB有不同的實現方式，但都包括有：IDL 編譯器, 倉庫（repositories），各種Object Adapters，給client提供各種服務集，具有不同屬性的對象實現等。
現在有各種不同的ORB實現。一個client可以同時訪問兩個由不同ORB實現管理的對象引用（object references）當這兩個ORB需要一起工作時，它們能區分出各自的對象引用。Client不需要對此負責。ORB Core是ORB的一個組成部分，它提供對象的基本表示和與請求的通信。
有四種不同類型的ORB：
1．Client- and Implementation-resident ORB
2．Server-based ORB
3．System-based ORB
4．Library-based ORB
ORB Interface:
一個ORB是一個邏輯實體（logical entity），它可以用各種方法實現（如一個或多個過程，或一個libraries集合）。為了減輕編寫程序的困難，CORBA規范定義了一個抽象的接口。該接口提供各種幫助函數。
CORBA IDL stubs and skeletons:
它相當于client、server應用程序和ORB之間的“膠水”。由CORBA IDL編譯器自動實現CORBA IDL定義與目標編程語言之間的轉換。
使用編譯器可以減少client stub和server skeletons之間的潛在矛盾。
Dynamic Invocation Interface(DII):
該接口允許client直接調用ORB所提供得最底層的請求機制。應用程序使用DII動態地把請求傳給對象而不需要IDL接口（包括特定stub）。與IDL stub（它只允許RPC模式的請求）不同，DII也允許clients使用無塊的延遲同步調用（non-blocking deferred synchronous）(發送操作是獨立的)和單向調用（send-only）。
Dynamic Skeleton Interface(DSI):
與client端的DII類似的，位于server端的接口。DSI允許ORB把請求發送給對象實現，該對象實現不包含編譯時所需要的類型。發出請求的client不知道該實現是使用指定類型的IDL skeletons 還是使用動態的skeletons。
Object Adapter:
它幫助ORB把請求傳給對象并激活該對象。更重要的是一個object adapter總是與一個對象實現（object implementations）聯系的。Object adapter可以被定義來支持特定的對象實現類型（如OODB object adapters用于持續對象（persistence）而library object adapters 用于非遠程對象）。
圖8 典型的Object Adapter結構
它的作用有：
(1)產生和解釋對象引用
(2)Method調用
(3)相互作用的安全性
(4)對象和激活實現及撤銷實現
(5)把對象引用映射到相應的對象實現
(6)注冊對象實現
3 系統集成
圖9 不同對象系統集成的方法
4 互操作ORB 的互操作性提供了種易于理解的、方便的途徑來支持網絡中的對象，這些對象由多樣的，不同種類的（與CORBA 兼容的）ORB管理。由于CORBA中的元素能以很多方式結合在一起以滿足各種不同的需要，因此取得“interORBability”的方法很方便。
1) 支持互操作的元素
能支持互操作的元素有：:
1. ORB 互操作結構
2. Inter-ORB 橋支持（bridge support）
3. General and Internet inter-ORB Protocols (GIOPs and IIOPs)
而且，該結構還支持environment-specific inter-ORB protocols (ESIOP)，它能優化特定領域如DCE）
2) ORB 互操作結構
該結構引入了ORB域中immediate and mediated bridging（直接橋接和間接橋接）這兩個概念。IIOP是廣域網橋接的基礎。而inter-ORB 橋接既能用于直接橋接，也能用于“半橋接”，使用半橋接能搭建用于間接橋接。使用這些橋接技術，ORB能互操作，而不需要知道彼此的實現細節，如，使用何種特殊的IPC或協議（如ESIOP）來實現CORBA規范。
使用能用IIOP通訊的“半橋接”， 兩個或多個ORB能相互橋接在一起。這種方法既能用于單機ORB，也能用于網絡ORB如ESIOP。IIOP也能用于實現ORB中的內部消息機制。
3) Inter-ORB Bridge Support
互操作結構明確指出ORB中不同域的作用，這些域包括對象引用域（object reference domain），類型域（type domain），安全域（safety domain）（如the scope of a Principal identifier), 事物域（transaction domain）等等。
當兩個ORB位于同一個域中，它們能直接通訊，多數情況下，這是一個很好的方法。但由于各個機構需要建造各自控制域，因此，這種方法不常使用。當需要的信息離開它的域時，就必須使用橋接來傳遞信息。橋接的作用是確保信息能完整的從一個ORB映射到另一個ORB。inter-ORB 橋接支持也能提供與非CORBA系統(如Microsoft’s Component Object Model (COM))之間的互操作。
4) General Inter-ORB Protocol (GIOP)
General Inter-ORB Protocol (GIOP) 元件提供了一個標準傳輸語法（低層數據表示方法）和ORB之間通信的信息格式集。GIOP只能用在ORB與ORB之間，而且，只能在符合理想條件的面向連接傳輸協議中使用。它不需要使用更高一層的RPC機制。這個協議是簡單的（盡可能簡單，但不是簡單化），可升級的，使用方便。它被設計為可移動的、高效能的表現、較少依靠其它的低層傳輸協議。當然，由于不同傳輸使用不同版本的GIOP，它們可能不能直接協作工作，但它能很容易的連接網絡域。
5) Internet Inter-ORB Protocol (IIOP)
Internet Inter-ORB Protocol (IIOP) 元件指出如何通過TCP/IP連接交換GIOP信息。IIOP為Internet提供了一個標準的協作工作協議，它使兼容的ORB能基于現在流行的協議和產品進行“out of the box”方式的協作工作。它也能被用于兩個半橋（half-bridges ）之間的協議。該協議能用于任何ORB與IP（Internet Protocol）域之間的協作工作，除非ORB選擇了特殊的協議。這時，它是TCP/IP環境下基本的inter-ORB 協議，最普遍的傳輸層。
IIOP與GIOP的關系就象特特殊語言與OMG IDL之間的關系；GIOP能被映射到不同層，它能指定協議。就象IDL不能見招完整的程序一樣，GIOP 本身也不能提供完整的協作工作。IIOP和不同傳輸層上的其它相似映射，實現抽象的GIOP定義，如圖10所示。
圖 10 Inter-ORB Protocol 關系
6) Environment-Specific Inter-ORB Protocols (ESIOPs)
它為使用Environment-Specific Inter-ORB Protocols (ESIOPs)的條件提出了解決方案。Such protocols would be used for “out of the box” interoperation at user sites where a particular networking or distributing computing infrastructure is already in general use. Because of the opportunity to leverage and build on facilities provided by the specific environment, ESIOPs might support specialized capabilities such as those relating to security and administration. While ESIOPs may be optimized for particular environments, all ESIOP specifications will be expected to conform to the general ORB interoperability architecture conventions to enable easy bridging. The inter-ORB bridge support enables bridges to be built between ORB domains that use the IIOP and ORB domains that use a particular ESIOP.
7) Domain(域)
域把一個系統中的元素按照某種特征分成幾個部分。在本結構中，域是一個范圍，一個對象的集合，對象是域的成員，這些成員有共同的特征。可以把域看作是一個對象，它本生也可能是其它域的一個成員。
圖11 各種類型的域
CORBA中的域分為以下幾個部分：
Referencing domain – 對象引用范圍
Representation domain – 信息傳輸語法和協議范圍
Network addressing domain –網絡地址范圍
Network connectivity domain – 可能的網絡信息范圍
Security domain – 特殊安全策略
Type domain – 特殊標識符范圍
Transaction domain –特定事物服務范圍
有兩種方式使用域：一是嵌入，一個域包括在另一個域中；二是聯合，兩個域聯合起來使用。當兩個域的邊界上發生交互作用時，就需要使用一種映射機制（如橋接）在邊界處傳遞相關元素。這里有兩種方法，一是間接橋接（mediated bridging），一是直接橋接（immediate bridging）。
圖12 兩種橋接技術, 都用于兩個域之間
7.1 Mediated Bridging
使用間接橋接時，在每一個域的邊界上，以一種協商的、通用的格式來傳遞與域有關的元素。可以從以下幾個方面來觀察間接橋接：
(1)公共格式的應用范圍可能與兩個ORB/域的私下約定不同。
(2)可能有多個公共格式，每一種格式對應一個應用目的。
(3)如果有多個可供選擇的公共格式，選擇方式可以分為兩種，一是靜態選擇（兩個ORB開發商之間），二是動態選擇（每一個對象各自選擇）。
(4)這種方法隨著嵌入式編譯（與stub相比）或普通的庫代碼（如加密例程）的不同，它的格式不同
7.2 Immediate Bridging
使用直接橋接時，在每一個域的邊界上，相關的元素直接從一個域的內部格式轉到另一個域的內部格式。
可以從以下幾個方面來觀察間接橋接：
(1)這種方法有被優化的可能性（這時交互不通過第三方）但它是以犧牲靈活性和通用性來取得的。
(2)一般只當需要在與邊界傳遞純管理（不交換技術）才使用這種方法。例如，當需要在兩個相似ORB的安全管理域傳遞消息時，就不需要使用通用的間接標準。
綜上所述，當兩個ORB/域使用私有機制時，就比較難于區分這兩種方法。
7.3 Inter-Domain Functionality的位置
從邏輯上講，不論是間接橋接還是直接橋接，只要是域間橋（inter-domain bridge），它在兩個域中都有元素。但是，一方面，域可以跨越ORB邊界，而ORB也可以跨越機器和系統邊界；另一方面，一個機器或一個進程可能跨越多個ORB。從工程學的角度來講，這意味著一個域間橋中的元素根據ORB或系統的不同而采取分散或同處的分布方式。例如，如果一個ORB包括兩個安全域，那么，域間橋就可以在ORB的內部實現。同樣的，也可能在一個進程或系統中實現兩個ORB或域間的橋。從工程學來講，這種情況下，域間橋是有限的，它局限于單個系統或進程。如果所有的橋都用這種方式實現，那么系統或進程之間的協作只能在單個域或ORB中發生。
7.4 橋接級別（Bridging Level）
橋接可以在ORB級或更高以及實現。它們分別叫做嵌入（in-line）級橋接和請求級（request-level）橋接。請求級橋接使用CORBA API，包括使用Dynamic Skeleton Interface,來接受和流出（issue）請求。但是，也存在“implicit context”類，它與某些引用聯合起來，持有如事物信息和安全信息等的ORB Service信息，通常的API中部包括這種類。
7.5 網絡中橋接的結構
在網絡情況中的ORB，我們將引入“backbone”ORB的概念。不論是大型網絡還是小規模網絡倒要用到它。大型網絡的制造商可以定義自己的中樞ORB，而小規模網絡則選擇一個商業的ORB作為它的中樞。
圖 13 一個ORB作為中樞，它通過半橋和全橋連接其它的ORB
這種中樞結構是一種標準的網絡管理技術。它能減少橋接又能滿足網絡館管理。對于大型網絡來講，增加ORB橋接并不需要給網絡線路增加新的節點（hop）。
8) 橋接的種類
8.1 In-line Bridging(嵌入橋接)
嵌入橋接的代碼位于ORB中，它完成必要的翻譯和映射功能。它是兩個ORB進行橋接的最直接方法。它與單個ORB中的系統進行僑界的結構相似(例如，間接使用某些內部處理通訊模式，如網絡協議)。這表明，實現嵌入橋接可能會修改ORB中的某些基本的元素，例如插入新的內部處理通訊模式。(有一些ORB被設計成可以進行某些修改)。使用這種方法時，在不同級別上用軟件元素的集成來完成所需要的橋接功能：
(1)面的ORB提供附加的或可選擇的服務
(2)附加的或可選擇的stub和skeleton代碼
圖14 使用ORB內部的API構造 In-Line bridges
8.2 Request-Level Bridging(請求級橋接)
請求級橋接的代碼位于ORB的外面，它完成必要的翻譯和映射功能。它通過位于不同執行環境中兩個ORB的元素（一個ORB一個元素）使用普通協議（如網絡、共享內存和主機操作系統提供的其他IPC）來達到目的，這種方法也叫做“半橋”。
請求級橋接的基本原理：
(1)原始請求被傳給client ORB 中的代理對象（proxy object）。
(2)代理對象把請求內容（包括目標對象引用）翻譯成服務ORB（server ORB）能理解的格式
(3)代理引用透明服務對象上所需要的操作
(4)使用補充路徑把操作結果返回給客戶A
圖15 使用公共的ORB API構造 Request-Level bridges
CORBA Core定義了如下接口，使用它們能構造請求級橋接：
(1)Dynamic Invocation Interface (DII) 允許橋接能任意調用對象引用，而當建立橋接時不需要知道對象引用的類型。
(2)Dynamic Skeleton Interface (DSI) 即使當建立橋接時不知道對象引用的類型，也允許橋接手動地調用代理對象引用。
(3Interface Repositories 橋接用來獲取信息以驅動DII和DSI，這些信息包括操作參數的類型及返回值和意外。
(4)Object Adapters (例如Basic Object Adapter) 當引導橋接和映射對象引用（從一個ORB動態地傳給另一個ORB）時，創建對象引用的代理器。
(5)CORBA Object References 提供操作，這些操作能完全描述它們接口和建造把對象引用映射到它們代理器（或反之）的表。Interface repositories 雖然半橋接使用的給定的池ID（如接口類型ID，意外ID）或操作ID必須一致，但是與半橋接相連的兩邊的接口池（Interface repositories ）中的信息可以不一樣。