2.3.1 ORB結構
圖 2-4 通過ORB傳遞請求
圖2-4顯示了一個client向對象實現發送一個請求。Client是一個想對對象進行操作的一個實體，對象實體是實現對象的代碼和數據。ORB負責根據一個請求來定位一個對象，安排對象實現準備接受請求，與請求的數據通訊。Client的接口與對象的位置完全，實現對象的語言及其它不在對象接口反映出來的方面等無關。
圖2-5顯示了單個ORB的結構。用斜條文的矩形框表示ORB的接口, 箭頭表示調用ORB或ORB使用接口把信息向上傳遞。
圖 2-5 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，二是動態的創造請求（如圖2-6所示）。
圖 2-6 Client使用Stub 或Dynamic Invocation Interface
不論使用Stub還是Dynamic Invocation Interface來發出請求具有相同的語義，信息的接收者不能分辨出該請求是使用哪種方法來傳遞的。ORB確定適當的實現代碼，傳遞參數，通過IDL skeleton或dynamic skeleton (如圖Figure 2-7 所示)把控制傳給Object Implementation。每一個接口和object adapter 使用不同的Skeletons。爲了完成請求，object implementation 可能通過Object Adapter 使用來自ORB的服務。當完成請求後，控制和輸出結果返回給client。
圖 2-7 Object Implementation 接受請求
Object Implementation選擇使用何種Object Adapter。它是根據Object Implementation 需要服務的種類來確定的。圖2-7 顯示了clients和object implementations如何使用接口和實現信息。用OMG IDL或Interface Repository來定義接口；該定義用於產生client Stubs和object implementation Skeletons。
圖 2-8 Interface 和 Implementation Repositories
在安裝時把object implementation 信息放入Implementation Repository中，以備請求使用。
2.3.2 ORB結構中的主要構件
圖2-9 CORBA ORB結構
Object Implementation(對象實現): 它定義了實現一個CORBA IDL接口的操作。它可以用各種語言來寫，如C, C++, Java, Smalltalk和Ada。
圖2-10 典型的Object Implementation 結構
Client(客戶): 這是一個程序實體，它調用了某一個對象實現中操作。對調用這來講，訪問遠程對象server應該是透明的。它應該和調用對象中的方法一樣簡單，如，obj->op(args)。
Client只能根據對象的接口瞭解對象的邏輯結構，雖然，我們一般都把client看作是一個程序或一個進程，但是，知道一個client都是某一個對象有關的。例如，一個對象的實現可能是其他對象的client。
圖 2-11 典型的Client結構
Client通過語言映射（language mapping）來使用對象和ORB 接口。當這種映射關係改變時，不需要改變Client。Client不需要了解對象的實現方式，對象適配器及ORB。
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 用於非遠程對象）。
圖2-12 典型的Object Adapter結構
它的作用有：
(1)產生和解釋對象引用
(2)Method調用
(3)相互作用的安全性
(4)對象和激活實現及撤銷實現
(5)把對象引用映射到相應的對象實現
(6)註冊對象實現
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/helloworlder/archive/2003/07/02/20366.aspx