對象請求代理(ORB)(陳柏年)

對象請求代理〔ORB〕(陳柏年)公用對象請求代理〔調(diào)度〕程序體系結(jié)構(gòu)CORBA〔CommonObjectRequestBrokerArchitecture〕，是對象管理組織OMG〔ObjectManagementGroup〕對應當今快速增長的軟硬件的協(xié)同工作能力的要求而提出的方案。簡而言之，CORBA允許應用程序和其他的應用程序通訊，而不管他們在什么地方或者由誰來設計。CORBA1.1由對象管理組織在1991年發(fā)布。他定義了接口定義語言〔IDL〕和應用編程接口〔API〕，從而通過實現(xiàn)對象請求代理〔ORB〕來激活客戶/效勞器的交互。CORBA2.0于1994年的12月發(fā)布。他定義了如何跨越不同的ORB提供者而進行通訊。ORB是一個中間件，他在對象間建立客戶-效勞器的關系。通過ORB，一個客戶可以很簡單地使用效勞器對象的方法而不管效勞器是在同一機器上還是通過一個網(wǎng)絡訪問。ORB截獲調(diào)用然后負責找到一個對象實現(xiàn)這個請求，傳遞參數(shù)和方法，最后返回結(jié)果?？蛻舨挥弥缹ο笤谀睦铮鞘裁凑Z言實現(xiàn)的，他的操作系統(tǒng)以及其他和對象接口無關的東西。在傳統(tǒng)的客戶/效勞器程序中，開發(fā)者使用他們自己設計的或者公認的標準定義設備之間的協(xié)議。協(xié)議的定義依賴于實現(xiàn)的語言，網(wǎng)絡的傳輸和其他許許多多因素。ORB將這個過程簡單化。使用ORB，協(xié)議定義是通過應用接口，而該接口是接口定義語言〔IDL〕的一個實現(xiàn)，他和使用的編程語言無關的。并且ORB提供了很大的靈活性。他讓程序員選擇最適當?shù)牟僮飨到y(tǒng)，運行環(huán)境和設計語言來建設系統(tǒng)中每個組件。更重要的是，他允許集成已經(jīng)存在的組件。CORBA是在面向?qū)ο髽藴驶突ゲ僮餍缘缆飞系囊粋€信號。通過CORBA，用戶不必要知道軟硬件的平臺和他們處在企業(yè)網(wǎng)的什么地方就可以操作。ORB結(jié)構(gòu)通過ORB發(fā)送請求上面的圖形說明的是客戶端發(fā)送一個請求到對象的實現(xiàn)?？蛻舳耸窍Ｍ麑δ硨ο髨?zhí)行操作的實體。對象的實現(xiàn)是一片代碼和數(shù)據(jù)來實際實現(xiàn)對象。ORB負責下面的必要的機制：對該請求找到對象的實現(xiàn)，讓對象的實現(xiàn)準備好接受請求，和請求交換數(shù)據(jù)?？蛻舳说慕涌谕耆毩⒂趯ο蟮奈恢?，其實現(xiàn)的語言和其他不影響對象接口的東西。ORB接口的結(jié)構(gòu)上面的圖形顯示的是一個獨立的對象請求代理〔ORB〕的結(jié)構(gòu)。ORB的接口是灰色的矩形。箭頭說明ORB的調(diào)用關系。為了提出一個請求，客戶端可以使用動態(tài)調(diào)用接口DII〔DynamicInvocationInterface〕〔和目標對象的接口獨立〕或者一個OMG的IDL占位程序〔具體的占位程序依賴于目標對象的接口〕?？蛻舳艘部梢灾苯雍蚈RB在某些地方交互。對象的實現(xiàn)通過OMG的IDL產(chǎn)生的骨架或者是一個動態(tài)骨架的調(diào)用來接受請求。對象的實現(xiàn)可能在處理請求或其他的時候調(diào)用ORB。對象接口定義的定義可以有下面兩種方式。接口可以通過接口定義語言靜態(tài)的定義，這叫做OMG的IDL。該語言按照可以進行的操作和該操作的參數(shù)定義對象類型?；蛘摺惨部梢宰鳛檠a充〕，接口可以參加到InterfaceRepositoryservice。該效勞描述了該接口作為一個對象的組件，并允許運行時訪問這些組件。在任何ORB實現(xiàn)中，IDL和InterfaceRepository有相同的表達能力?？蛻舳耸褂谜嘉怀绦蚧蛘邉討B(tài)調(diào)用接口客戶端通過訪問對象的對象引用和了解對象的類型及要求執(zhí)行的操作來發(fā)布一個請求?？蛻粽{(diào)用占位程序例程來請求或者動態(tài)構(gòu)造請求。無論動態(tài)還是占位程序的接口都可以相同實現(xiàn)。接收方不可能知道請求是如何發(fā)布的。對象的實現(xiàn)接受請求ORB向?qū)ο髮崿F(xiàn)定位適當?shù)拇a，傳遞參數(shù)，傳輸控制。這一切都通過IDL骨架或者動態(tài)骨架。骨架對于不同的接口和對象適配器是不同的。在執(zhí)行該請求的時候，對象的實現(xiàn)可能由ORB通過對象適配器來獲得一定的效勞。當請求完成，控制和輸出值返回給客戶。對象的實現(xiàn)可能會選擇使用的對象適配器。該決定基于對象的實現(xiàn)要求的效勞。接口和ImplementationRepositories上圖說明的是接口和實現(xiàn)信息如何讓客戶和對象實現(xiàn)訪問的。接口用OMG的IDL和/或InterfaceRepository定義。該定義用于產(chǎn)生客戶占位程序和對象的實現(xiàn)的骨架。對象的實現(xiàn)的信息在安裝時就提供好了，儲存在ImplementationRepository中以便請求發(fā)布的時候使用。對象請求代理〔ORB〕詳細說明ORB是一個中間件(middleware)，它可以建立對象之間的client/server關系。通過ORB，一個client可以透明的引用同一臺機器上或網(wǎng)絡上的一個server對象的方法。ORB解釋該調(diào)用并負責查找一個實現(xiàn)該請求的對象，找到后，把參數(shù)傳給該對象，調(diào)用它的方法，最后返回結(jié)果。client并不清楚該對象的位置，它的編程語言，它的操作系統(tǒng)以及其它不是對象接口的系統(tǒng)信息。ORB能實現(xiàn)分布環(huán)境中位于不同機器上的應用之間的互操作以及多對象系統(tǒng)之間的無縫連接。在傳統(tǒng)的client/server)應用中，開發(fā)者使用自己設計的標準或通用標準來定義設備之間的協(xié)議。協(xié)議定義與實現(xiàn)的語言、網(wǎng)絡傳輸及其它因素有關。ORB簡化了這一過程，它使用IDL來定義應用接口之間的協(xié)議。ORB允許程序員選擇通用操作系統(tǒng),運行環(huán)境和編程語言。更重要的是，它能集成現(xiàn)存元素。

ORB結(jié)構(gòu)

圖1通過ORB傳遞請求圖1顯示了一個client向?qū)ο髮崿F(xiàn)發(fā)送一個請求。Client是一個想對對象進行操作的一個實體，對象實體是實現(xiàn)對象的代碼和數(shù)據(jù)。ORB負責根據(jù)一個請求來定位一個對象，安排對象實現(xiàn)準備接受請求，與請求的數(shù)據(jù)通訊。Client的接口與對象的位置完全，實現(xiàn)對象的語言及其它不在對象接口反映出來的方面等無關。圖2顯示了單個ORB的結(jié)構(gòu)。用斜條文的矩形框表示ORB的接口,箭頭表示調(diào)用ORB或ORB使用接口把信息向上傳遞。

圖2ORB接口結(jié)構(gòu)

Clinet使用DynamicInvocationinterface(與目標對象的接口無關)或OMGIDLstub(與目標對象接口有關的stub)來發(fā)出請求。由于某種原因，Client也可以直接與ORB聯(lián)系。對象實現(xiàn)使用OMGIDL生成的skeleton或動態(tài)skeleton以向上傳送〔up-call〕的方式接受請求。對象實現(xiàn)也可以調(diào)用ObjectAdapter和ORB。可以用兩種方式來定義對象接口：一是用OMGInterfaceDefinitionLanguage(OMGIDL)來定義接口。該語言根據(jù)可能對對象進行的操作和這些操作使用的參數(shù)來定義對象類型。第二種方法是，把接口〔interface〕放入InterfaceRepositoryservice中;該效勞把接口中的元素描述成一個對象。任何能實現(xiàn)ORB的軟件中，InterfaceDefinitionLanguage(可能根據(jù)文檔的內(nèi)容而改變)和InterfaceRepository具有相同的作用。一個client要使用ObjectReference完成請求，它必須知道對象的類型的及具體的操作。Client初始化請求有兩種方法，一是通過調(diào)用目標對象的stubroutines，二是動態(tài)的創(chuàng)造請求〔如圖3所示〕。

圖3Client使用Stub或DynamicInvocationInterface

不管使用Stub還是DynamicInvocationInterface來發(fā)出請求具有相同的語義，信息的接收者不能分辨出該請求是使用哪種方法來傳遞的。ORB確定適當?shù)膶崿F(xiàn)代碼，傳遞參數(shù)，通過IDLskeleton或dynamicskeleton(如圖Figure4所示)把控制傳給ObjectImplementation。每一個接口和objectadapter使用不同的Skeletons。為了完成請求，objectimplementation可能通過ObjectAdapter使用來自ORB的效勞。當完成請求后，控制和輸出結(jié)果返回給client。

圖4ObjectImplementation接受請求

ObjectImplementation選擇使用何種ObjectAdapter。它是根據(jù)ObjectImplementation需要效勞的種類來確定的。圖5顯示了clients和objectimplementations如何使用接口和實現(xiàn)信息。用OMGIDL或InterfaceRepository來定義接口；該定義用于產(chǎn)生clientStubs和objectimplementationSkeletons。

圖5Interface和ImplementationRepositories

在安裝時把objectimplementation信息放入ImplementationRepository中，以備請求使用。ORB結(jié)構(gòu)中的主要構(gòu)件

圖6.1CORBAORB結(jié)構(gòu)

1)ObjectImplementation(對象實現(xiàn)):它定義了實現(xiàn)一個CORBAIDL接口的操作。它可以用各種語言來寫，如C,C++,Java,Smalltalk和Ada。

圖6.2典型的ObjectImplementation結(jié)構(gòu)

2)Client(客戶):這是一個程序?qū)嶓w，它調(diào)用了某一個對象實現(xiàn)中操作。對調(diào)用這來講，訪問遠程對象server應該是透明的。它應該和調(diào)用對象中的方法一樣簡單，如，obj->op(args)。

Client只能根據(jù)對象的接口了解對象的邏輯結(jié)構(gòu)，雖然，我們一般都把client看作是一個程序或一個進程，但是，知道一個client都是某一個對象有關的。例如，一個對象的實現(xiàn)可能是其他對象的client。

圖7典型的Client結(jié)構(gòu)

Client通過語言映射〔languagemapping〕來使用對象和ORB接口。當這種映射關系改變時，不需要改變Client。Client不需要了解對象的實現(xiàn)方式，對象適配器及ORB。

3)ObjectRequestBroker(ORB):

ORB提供了一種機制，能實現(xiàn)client請求與目標對象實現(xiàn)之間的透明通信。它使得client請求就象一個本地過程調(diào)用一樣。當一個client引用一個操作，ORB負責找到對象實現(xiàn)，如果需要那么透明的激活它，然后把該請求遞交給該對象，最后返回應答給調(diào)用者。實現(xiàn)時，可以把ORB不作為單個成分，但它只能由它的接口來定義。任何ORB實現(xiàn)方式提供的接口都是可以接受的?？梢园呀涌谥械牟僮鞣譃槿悾?/p>

1.對于所有的ORB實現(xiàn)都一樣的操作

2.特定類型對象的操作

3.與對象實現(xiàn)種特定類別有關的操作

不同的ORB有不同的實現(xiàn)方式，但都包括有：IDL編譯器,倉庫〔repositories〕，各種ObjectAdapters，給client提供各種效勞集，具有不同屬性的對象實現(xiàn)等。

現(xiàn)在有各種不同的ORB實現(xiàn)。一個client可以同時訪問兩個由不同ORB實現(xiàn)管理的對象引用〔objectreferences〕當這兩個ORB需要一起工作時，它們能區(qū)分出各自的對象引用。Client不需要對此負責。ORBCore是ORB的一個組成局部，它提供對象的根本表示和與請求的通信。

有四種不同類型的ORB：

1．Client-andImplementation-residentORB

2．Server-basedORB

3．System-basedORB

4．Library-basedORB

ORBInterface:

一個ORB是一個邏輯實體〔logicalentity〕，它可以用各種方法實現(xiàn)〔如一個或多個過程，或一個libraries集合〕。為了減輕編寫程序的困難，CORBA標準定義了一個抽象的接口。該接口提供各種幫助函數(shù)。

CORBAIDLstubsandskeletons:

它相當于client、server應用程序和ORB之間的“膠水〞。由CORBAIDL編譯器自動實現(xiàn)CORBAIDL定義與目標編程語言之間的轉(zhuǎn)換。

使用編譯器可以減少clientstub和serverskeletons之間的潛在矛盾。

DynamicInvocationInterface(DII):

該接口允許client直接調(diào)用ORB所提供得最底層的請求機制。應用程序使用DII動態(tài)地把請求傳給對象而不需要IDL接口〔包括特定stub〕。與IDLstub〔它只允許RPC模式的請求〕不同，DII也允許clients使用無塊的延遲同步調(diào)用〔non-blockingdeferredsynchronous〕(發(fā)送操作是獨立的)和單向調(diào)用〔send-only〕。

DynamicSkeletonInterface(DSI):

與client端的DII類似的，位于server端的接口。DSI允許ORB把請求發(fā)送給對象實現(xiàn)，該對象實現(xiàn)不包含編譯時所需要的類型。發(fā)出請求的client不知道該實現(xiàn)是使用指定類型的IDLskeletons還是使用動態(tài)的skeletons。

ObjectAdapter:

它幫助ORB把請求傳給對象并激活該對象。更重要的是一個objectadapter總是與一個對象實現(xiàn)〔objectimplementations〕聯(lián)系的。Objectadapter可以被定義來支持特定的對象實現(xiàn)類型〔如OODBobjectadapters用于持續(xù)對象〔persistence〕而libraryobjectadapters用于非遠程對象〕。

圖8典型的ObjectAdapter結(jié)構(gòu)

它的作用有：

(1)產(chǎn)生和解釋對象引用

(2)Method調(diào)用

(3)相互作用的平安性

(4)對象和激活實現(xiàn)及撤銷實現(xiàn)

(5)把對象引用映射到相應的對象實現(xiàn)

(6)注冊對象實現(xiàn)3系統(tǒng)集成

圖9不同對象系統(tǒng)集成的方法4互操作

ORB的互操作性提供了種易于理解的、方便的途徑來支持網(wǎng)絡中的對象，這些對象由多樣的，不同種類的〔與CORBA兼容的〕ORB管理。由于CORBA中的元素能以很多方式結(jié)合在一起以滿足各種不同的需要，因此取得“interORBability〞的方法很方便。

1)支持互操作的元素

能支持互操作的元素有：:

1.ORB互操作結(jié)構(gòu)

2.Inter-ORB橋支持〔bridgesupport〕

3.GeneralandInternetinter-ORBProtocols(GIOPsandIIOPs)

而且，該結(jié)構(gòu)還支持environment-specificinter-ORBprotocols(ESIOP)，它能優(yōu)化特定領域如DCE〕

2)ORB互操作結(jié)構(gòu)

該結(jié)構(gòu)引入了ORB域中immediateandmediatedbridging〔直接橋接和間接橋接〕這兩個概念。IIOP是廣域網(wǎng)橋接的根底。而inter-ORB橋接既能用于直接橋接，也能用于“半橋接〞，使用半橋接能搭建用于間接橋接。使用這些橋接技術(shù)，ORB能互操作，而不需要知道彼此的實現(xiàn)細節(jié)，如，使用何種特殊的IPC或協(xié)議〔如ESIOP〕來實現(xiàn)CORBA標準。

使用能用IIOP通訊的“半橋接〞，兩個或多個ORB能相互橋接在一起。這種方法既能用于單機ORB，也能用于網(wǎng)絡ORB如ESIOP。IIOP也能用于實現(xiàn)ORB中的內(nèi)部消息機制。

3)Inter-ORBBridgeSupport

互操作結(jié)構(gòu)明確指出ORB中不同域的作用，這些域包括對象引用域〔objectreferencedomain〕，類型域〔typedomain〕，平安域〔safetydomain〕〔如thescopeofaPrincipalidentifier),事物域〔transactiondomain〕等等。

當兩個ORB位于同一個域中，它們能直接通訊，多數(shù)情況下，這是一個很好的方法。但由于各個機構(gòu)需要建造各自控制域，因此，這種方法不常使用。當需要的信息離開它的域時，就必須使用橋接來傳遞信息。橋接的作用是確保信息能完整的從一個ORB映射到另一個ORB。inter-ORB橋接支持也能提供與非CORBA系統(tǒng)(如Microsoft’sComponentObjectModel(COM))之間的互操作。

4)GeneralInter-ORBProtocol(GIOP)

GeneralInter-ORBProtocol(GIOP)元件提供了一個標準傳輸語法〔低層數(shù)據(jù)表示方法〕和ORB之間通信的信息格式集。GIOP只能用在ORB與ORB之間，而且，只能在符合理想條件的面向連接傳輸協(xié)議中使用。它不需要使用更高一層的RPC機制。這個協(xié)議是簡單的〔盡可能簡單，但不是簡單化〕，可升級的，使用方便。它被設計為可移動的、高效能的表現(xiàn)、較少依靠其它的低層傳輸協(xié)議。當然，由于不同傳輸使用不同版本的GIOP，它們可能不能直接協(xié)作工作，但它能很容易的連接網(wǎng)絡域。

5)InternetInter-ORBProtocol(IIOP)

InternetInter-ORBProtocol(IIOP)元件指出如何通過TCP/IP連接交換GIOP信息。IIOP為Internet提供了一個標準的協(xié)作工作協(xié)議，它使兼容的ORB能基于現(xiàn)在流行的協(xié)議和產(chǎn)品進行“outofthebox〞方式的協(xié)作工作。它也能被用于兩個半橋〔half-bridges〕之間的協(xié)議。該協(xié)議能用于任何ORB與IP〔InternetProtocol〕域之間的協(xié)作工作，除非ORB選擇了特殊的協(xié)議。這時，它是TCP/IP環(huán)境下根本的inter-ORB協(xié)議，最普遍的傳輸層。

IIOP與GIOP的關系就象特特殊語言與OMGIDL之間的關系；GIOP能被映射到不同層，它能指定協(xié)議。就象IDL不能見招完整的程序一樣，GIOP本身也不能提供完整的協(xié)作工作。IIOP和不同傳輸層上的其它相似映射，實現(xiàn)抽象的GIOP定義，如圖10所示。

圖10Inter-ORBProtocol關系

6)Environment-SpecificInter-ORBProtocols(ESIOPs)

它為使用Environment-SpecificInter-ORBProtocols(ESIOPs)的條件提出了解決方案。Suchprotocolswouldbeusedfor“outofthebox〞interoperationatusersiteswhereaparticularnetworkingordistributingcomputinginfrastructureisalreadyingeneraluse.Becauseoftheopportunitytoleverageandbuildonfacilitiesprovidedbythespecificenvironment,ESIOPsmightsupportspecializedcapabilitiessuchasthoserelatingtosecurityandadministration.WhileESIOPsmaybeoptimizedforparticularenvironments,allESIOPspecificationswillbeexpectedtoconformtothegeneralORBinteroperabilityarchitectureconventionstoenableeasybridging.Theinter-ORBbridgesupportenablesbridgestobebuiltbetweenORBdomainsthatusetheIIOPandORBdomainsthatuseaparticularESIOP.

7)Domain(域)

域把一個系統(tǒng)中的元素按照某種特征分成幾個局部。在本結(jié)構(gòu)中，域是一個范圍，一個對象的集合，對象是域的成員，這些成員有共同的特征。可以把域看作是一個對象，它本生也可能是其它域的一個成員。

圖11各種類型的域

CORBA中的域分為以下幾個局部：

Referencingdomain–對象引用范圍

Representationdomain–信息傳輸語法和協(xié)議范圍

Networkaddressingdomain–網(wǎng)絡地址范圍

Networkconnectivitydomain–可能的網(wǎng)絡信息范圍

Securitydomain–特殊平安策略

Typedomain–特殊標識符范圍

Transactiondomain–特定事物效勞范圍

有兩種方式使用域：一是嵌入，一個域包括在另一個域中；二是聯(lián)合，兩個域聯(lián)合起來使用。當兩個域的邊界上發(fā)生交互作用時，就需要使用一種映射機制〔如橋接〕在邊界處傳遞相關元素。這里有兩種方法，一是間接橋接〔mediatedbridging〕，一是直接橋接〔immediatebridging〕。

圖12兩種橋接技術(shù),都用于兩個域之間

7.1MediatedBridging

使用間接橋接時，在每一個域的邊界上，以一種協(xié)商的、通用的格式來傳遞與域有關的元素?？梢詮囊韵聨讉€方面來觀察間接橋接：

(1)公共格式的應用范圍可能與兩個ORB/域的私下約定不同。

(2)可能有多個公共格式，每一種格式對應一個應用目的。

(3)如果有多個可供選擇的公共格式，選擇方式可以分為兩種，一是靜態(tài)選擇〔兩個ORB開發(fā)商之間〕，二是動態(tài)選擇〔每一個對象各自選擇〕。

(4)這種方法隨著嵌入式編譯〔與stub相比〕或普通的庫代碼〔如加密例程〕的不同，它的格式不同

7.2ImmediateBridging

使用直接橋接時，在每一個域的邊界上，相關的元素直接從一個域的內(nèi)部格式轉(zhuǎn)到另一個域的內(nèi)部格式。

可以從以下幾個方面來觀察間接橋接：

(1)這種方法有被優(yōu)化的可能性〔這時交互不通過第三方〕但它是以犧牲靈活性和通用性來取得的。

(2)一般只當需要在與邊界傳遞純管理〔不交換技術(shù)〕才使用這種方法。例如，當需要在兩個相似ORB的平安管理域傳遞消息時，就不需要使用通用的間接標準。

綜上所述，當兩個ORB/域使用私有機制時，就比擬難于區(qū)分這兩種方法。

7.3Inter-DomainFunctionality的位置

從邏輯上講，不管是間接橋接還是直接橋接，只要是域間橋〔inter-domainbridge〕，它在兩個域中都有元素。但是，一方面，域可以跨越ORB邊界，而ORB也可以跨越機器和系統(tǒng)邊界；另一方面，一個機器或一個進程可能跨越多個ORB。從工程學的角度來講，這意味著一個域間橋中的元素根據(jù)ORB或系統(tǒng)的不同而采取分散或同處的分布方式。例如，如果一個ORB包括兩個平安域，那么，域間橋就可以在ORB的內(nèi)部實現(xiàn)。同樣的，也可能在一個進程或系統(tǒng)中實現(xiàn)兩個ORB或域間的橋。從工程學來講，這種情況下，域間橋是有限的，它局限于單個系統(tǒng)或進程。如果所有的橋都用這種方式實現(xiàn)，那么系統(tǒng)或進程之間的協(xié)作只能在單個域或ORB中發(fā)生。

7.4橋接級別〔BridgingLevel〕

橋接可以在ORB級或更高以及實現(xiàn)。它們分別叫做嵌入〔in-line〕級橋接和請求級〔request-level〕橋接。請求級橋接使用CORBAAPI，包括使用DynamicSkeletonInterface,來接受和流出〔issue〕請求。但是，也存在“implicitcontext〞類，它與某些引用聯(lián)合起來，持有如事物信息和平安信息等的ORBService信息，通常的API中部包括這種類。

7.5網(wǎng)絡中橋接的結(jié)構(gòu)

在網(wǎng)絡情況中的ORB，我們將引入“backbone〞ORB的概念。不管是大型網(wǎng)絡還是小規(guī)模網(wǎng)絡倒要用到它。大型網(wǎng)絡的制造商可以定義自己的中樞ORB，而小規(guī)模網(wǎng)絡那么選擇一個商業(yè)的ORB作為它的中樞。

圖13一個ORB作為中樞，它通過半橋和全橋連接其它的ORB

這種中樞結(jié)構(gòu)是一種標準的網(wǎng)絡管理技術(shù)。它能減少橋接又能滿足網(wǎng)絡館管理。對于大型網(wǎng)絡來講，增加ORB橋接并不需要給網(wǎng)絡線路增加新的節(jié)點〔hop〕。

8)橋接的種類

8.1In-lineBridg