基本介紹
- 中文名：公共對象請求代理體系結構
- 外文名：Common ObjectRequest Broker Architecture
- 簡稱：CCRBA
- 優勢：易擴充和修改具有通用性和適應性
技術介紹,基本構件,公共設施,對象服務,套用對象,對象請求代理,接口定義語言,核心作用,對象的定位,編組與解組,初始服務,禁止協定,提供接口庫,工作方式,靜態方式,動態方式,套用,
技術介紹
CORBA是OMG組織在1991年提出的公用對象請求代理程式結構的技術規範。CORBA有很廣泛的套用，它易於集成各廠商的不同計算機，從大型機一直到微型內嵌式系統的終端桌面，是針對大中型企業套用的優秀的中間件。最重要的是，它使伺服器真正能夠實現高速度、高穩定性處理大量用戶的訪問。現在很多大型網站後端的伺服器都運行CORBA，其中有些網站您可能每天都在訪問。
CORBA的底層結構是基於面向對象模型的，由OMG接口描述語言(OMG Interface Definition Language，OMG IDL)、對象請求代理(Objec tRequest Broker，ORB)和IIOP標準協定（Internet Inter ORB Protocol，也稱網路ORB交換協定）3個關鍵模組組成。
使用接口描述語言編寫的對象接口，使得與語言無關的獨立性成為可能。IDL使得所有CORBA對象以一種方式被描述，僅僅需要一個由本地語言（C/C++、CORBA或Java）到IDL的“橋樑”。CORBA對象的互通信要以對象請求代理為中介，這種互通信可以在多種流行通信協定（如TCP/IP或IPX/SPX）之上實現。在TCP/IP上，來自於不同開發商的ORB用IIOP標準協定進行通訊。
我們知道，為了保持CORBA的商業中立性和語言中立性，必須有一個中介，存在於像C++CORBA伺服器代碼和JavaCORBA客戶機這樣的實體中間，這就是IDL。一個底層對象的若干相關方法和屬性被IDL集入一個單一接口。一旦IDL接口定義完成，它可以以Stub碼或框架代碼的形式編譯成所選用的語言。在所有的ORB中都有IDL編譯器。
值得注意的一點是，IDL不同於其他的面向對象程式設計語言，我們不能用它指定所定義的類或方法的具體實現。因此，僅僅將它作為一種定義底層對象接口的語言要好得多。
基本構件
CORBA結構示意圖如圖所示。
公共設施
公共設施分為兩類:
- 橫向設施(horizontal facilities)是指在通用領域內定義的對象。信息管理、網路管理、系統管理、任務管理和用戶接口等都屬於通用領域。
- 縱向設施(verticalfacilities)是指在專用領域內定義的對象。電信、財政、商務、衛生保健等都屬於專用領域。
對象服務
對象服務是為公共設施和各種套用對象提供的基本服務,如命名服務、事件服務、事務處理服務、通知服務、交易服務、生命周期服務和安全服務等等。
- 命名服務(naming service)。CORBA對象登記在命名服務中,它可根據對象的名字找出對應的伺服器中的對象引用。
- 事件服務(event service)。事件服務由一個或多個供應者(supplier)、消費者(consumer)以及事件通道(event channel)組成。後者是供應者和消費者之間傳送事件(訊息)的媒介。供應者把要送給消費者的訊息放到事件通道中,根據事件通道的工作方式———推模式(push)和拉模式(pull),這些訊息或者被推至消費者,或者由消費者主動將它們從通道拉出。
- 事務處理服務(transaction service)。它確保一個事務所包含的操作,要么全部成功執行,要么在失敗的情況下一個也不執行並恢復到初始狀態,以維持執行事務前後數據的一致性。
- 交易服務(trader service)。交易服務由出口者(exporter)、進口者(importer)和交易者(trader)組成。出口者向交易者給出服務的描述和通告,進口者向交易者查詢符合有關條件的服務信息,然後從出口者獲得所需要的服務。
- 生命周期服務(life cycle service)。通過直接面向對象的服務,如對象的建立、刪除、轉移和複製等來控制對象的生存期。
- 安全服務(security service)。CORBA一級安全服務提供鑒權、限權、授權、審計、加密以及登記註冊等服務,全面解決分布系統中的安全性問題。
- 通知服務(notification service)。它是事件服務功能上的擴充,增加了結構化事件,事件的過濾機制以及服務質量控制等功能。
套用對象
這是未經OMG標準化的、由各個套用開發者自行開發的實體,套用對象使用CORBA提供的各種對象服務。
對象請求代理
對象請求代理（ORB: Object Request Broker），它是CORBA的基礎,是在分布環境下,CORBA套用所使用的、基於對象模型的軟體匯流排。它的基本職責是解決對象引用的請求和建立套用對象之間的聯結,通過標準接口,使這種聯結獨立於所使用的硬體和軟體的平台,從而保證了對平台的透明性以及對作業系統、網路協定和程式語言的透明性。
接口定義語言
接口定義語言（Interface Definition Language，IDL）用來定義CORBA對象使用的、套用組件之間的接口。它不是過程語言,它只能定義接口,而不是去實現某個接口。IDL獨立於任何程式語言,用IDL編譯器可以將它映射為其他常用的語言,如C++,C,COBOL,Java等等。
IDL的框架主要包括四種元素:
- 模組(module)。它含有許多按功能進行分組的接口,形成附加的分層結構。因此,模組定義了一個命名空間。
- 接口(interface)。它定義了數據和操作(或稱為方法),供客戶調用。接口中可以包括類型、常量、屬性和異常的聲明。實際上,IDL接口定義了CORBA中的類。
- 操作(operation)。它表示客戶可以調用的、處於對象中的服務。操作特性(signature)指的是操作的參數和返回的結果類型。一個操作還可以包括可供選擇的異常事件和一組描述客戶語言環境的屬性。這樣,操作就定義了CORBA中的方法。
- 數據類型。它用來描述參數、屬性、返回值以及異常等的允許值。類型是一種可標識的實體,具有一個與其值相同的謂詞,如果它作用於某個實體得到的結果為真,那么,這個實體就滿足這種類型,稱為該類型的成員。CORBA所支持的數據類型可以是基本類型、模板類型、構造類型、複雜類型以及本地類型。
核心作用
對象的定位
當客戶端程式得到對象引用(Object Reference)之後,會調用該對象引用的操作。這時,客戶端的ORB會根據對象引用中的信息來定位對象的實現(具體定位的方法將在後面章節討論),並確保該對象實現可以接受請求。由於ORB可以根據對象引用來定位伺服器,因此客戶端程式不必關心對象是在哪裡實現的。客戶端對遠端對象發起調用,就好像調用本地對象一樣,從而實現了CORBA的位置透明的特性。
編組與解組
在客戶端發起調用的時候,輸入參數格式都與特定平台和特定語言有關,客戶端ORB負責將它們編碼成可以在網路上傳送的格式,或稱線上格式(on-wire format),這一過程稱為編組(marshalling)。這種“0101”的格式在網路上傳送後到達伺服器端的ORB,伺服器端的ORB負責將這些線上格式“還原”成本地所使用的特定平台和語言的格式,這一過程稱為解組(unmarshalling)。與此相反,當伺服器端調用結束以後,伺服器端ORB負責將輸出參數和返回參數編碼成線上格式,並經網路傳送到客戶端ORB,客戶端ORB再將這些線上格式“還原”成本地所使用的特定平台和語言的格式,作為輸出參數和返回參數送給客戶端程式。總的來說,編組與解組的重要性表現在:第一,它把對遠端對象的調用變成一維的有序碼流,有利於在網路上的傳送。第二,它提供了一個獨立於各平台和語言的“中間格式”,不同的平台上的不同語言通過這個“中間格式”進行“對話”“(中間格式”的規則,將在後面章節中敘述)。正是由於編組和解組的引入,使客戶端和伺服器端的平台和語言可以不同,帶來了CORBA的平台獨立與語言獨立的特性。
初始服務
在程式初啟的時候,需要得到一些通用的對象引用,如對象適配器、命名服務、接口庫的對象引用。由於處於程式初啟的特殊階段,這些對象引用很難用常規的方法得到。ORB可以通過偽對象接口CORBA∷ORB提供兩個操作以完成這項功能:list-initial-services()和resolve-initial-references()(詳見“ORB初始化”一節)。
禁止協定
ORB負責處理底層網路通信的細節,它可以使用不同的底層網路協定,例如TCP/IP,IPX,SS7等,從而將客戶與伺服器從複雜的網路編程中解脫出來。
提供接口庫
每個ORB都有一個接口庫,接口庫負責存儲用接口定義語言(IDL)定義的接口的信息,它還支持一些標準的API,用來遍歷或查詢系統中的接口信息,它是CORBA動態調用不可缺少的組成部分。此外,ORB還通過偽對象接口CORBA∷ORB提供其他的通用API,這部分API既可以為客戶程式使用,也可以由伺服器程式使用(有關這部分的內容,將在“ORB接口”一節詳細介紹)。基於以上的討論,可將ORB核心的作用歸納如下(見圖):
- 當客戶激活一個調用的操作時,操作中指出的目標對象的對象引用經碼根傳遞ORB核心。ORB核心代表客戶自動尋找對應的伺服器(即目標對象的對象實現)。找到伺服器以後,ORB要確保該伺服器做好接收請求的準備工作。
- 客戶端的ORB核心接收被調用操作(或方法)的參數,並將它組碼為網路可接收的格式。伺服器端的ORB核心將來自網路的操作參數進行解組,然後送給伺服器,並啟動伺服器執行所調用的操作。
- 執行完操作後,如有返回參數,ORB核心將它組碼後傳入網路。客戶端ORB核心對它進行解碼,並將操作結果返回客戶。
工作方式
靜態方式
為了更好地理解CORBA的工作方式,我們先看一個杜撰的比喻。
假設有一個國王,身邊有一群所謂的學者,如哲學家、數學家、神學家等等。實際上他們並沒有什麼知識,唯一的法寶就是每人都有一張神奇的“名片”,能幫助他們找到真正的答案。(參閱圖2.11所示的過程)。
有一天,國王突然對哲學發生了興趣,他找來最賞識的哲學家,向他提了一個問題(見圖中①)。
哲學家對這個問題一竅不通,於是他按照“名片”上的信息打了一個電話,電話通往一個遙遠的國度(見圖中②)。接電話的是一位哲學家的夥伴,其實他什麼也不懂,但他是一位真正“先知”的私人代表,他把這個問題轉達給了他的主人———那位隱居的“先知”(見圖中③)。
那位先知思考後,對問題作了詳盡的回答(見圖中④)。
哲學家的夥伴對著話筒轉達了全部的內容(見圖中⑤)。
第二天,哲學家對國王宣布了這個答案(見圖中⑥)。
如果把打電話改為寫信,那么這個杜撰的情節幾千年前就可能發生,其實,CORBA在“情節”上並不比它複雜。
那位國王就是客戶(client),他的哲學家就是碼根(stub),其它的“學者”們也都是碼根,只不過各自對應的接口(能解決的問題)不同。國王詢問哲學家,就是客戶調用碼根,那張神奇的“名片”就是對象引用(Object Reference),而負責通信的電話機就是ORB核心。哲學家根據名片,通過電話找到的那位哲學傢伙伴就是靜態框架(skeleton),而情節中那位隱居的“先知”,就是對象實現(Object Implementation)。
問題被一步步的傳遞,就是請求的過程,哲學家的夥伴接電話,就是接受請求的過程。先知在思考的時候,就是請求被執行的過程,答案被一步步傳遞,就是返回結果的過程。
在靜態方式中,碼根事先由IDL接口檔案編譯生成,它包括代理對象的定義和實現。代理對象的定義與IDL接口中的定義相一致,包括名字、操作、參數等等方面,代理對象的實現封裝在代理對象內部,它實際上並沒有執行客戶所期待的實現,而是把客戶的請求編組後交給ORB核心,等待遠端的對象實現執行這一操作。執行後得到的返回參數和結果將通過ORB核心傳回給碼根進行解組,然後由碼根以本地操作的方式把返回參數和結果送回給等待結果的客戶端程式。
客戶端程式通過對象引用直接調用碼根中定義的各項操作。在靜態方式中,框架事先由IDL接口檔案編譯生成,特定的框架接受特定的、對某個接口的請求。
動態方式
假設上面杜撰的情節發生了變化,國王新聘請了一位秘書,每當遇到問題,身邊又沒有一位學者可以“解答”時,國王就從名片簿中挑出一張他認為可以解決這個問題的專家的名片,將它遞給秘書,秘書並不宣稱自己是某個問題的專家,其工作只是按照國王的旨意,根據名片的內容給對方打電話,並將獲得的解答告訴國王。
這就是動態調用方式,那位全能的秘書就是DII,而存放名片信息的名片簿就是接口庫。
相對靜態方式而言,動態方式有以下幾個優點:
- 靈活。動態方式允許對任意對象進行操作,所需要的只是目標對象的對象引用。此外,通過接口庫的幫助,動態方式可以在運行時刻(run-time)查詢對象所支持的操作的信息,對以前不知道的對象進行操作。無論是操作的對象、發起調用的參數,還是發起調用的次數等等都可以由客戶程式在運行時刻視當時的環境和需要而決定。因此,動態方式相對靜態方式而言靈活性大大增強。
- 客戶程式的可移植性增強。從ORB的結構圖中可以看出,DII與客戶之間以及DSI與對象實現之間的接口都是標準的,無論ORB怎樣實現,這部分接口應與規範規定的保持一致。由於客戶和對象實現使用的是標準的接口,因此,在理論上由動態方式實現的代碼應該具有良好的可移植性。
- 可執行程式的“體積”小。與碼根和框架的方式不同,DII和DSI不需要為每個接口生成碼根和框架。在現有的實現方式下,這些碼根或框架都需要在編譯時分別連結到使用它們的客戶程式和對象實現中。而在動態方式下,無論程式中使用多少接口,所需要的只是一套支持DII和DSI的接口庫,如果這個庫是動態庫,那么可執行程式的“體積”會更小。
然而,與靜態方式相比,動態方式有以下的缺點:
- 使用複雜。使用靜態方式時,對目標對象的操作都施加在一個本地的代理對象上,相應對象支持的所有操作及其格式都已經預先定義在這個代理對象中,因而使用方便。但是動態方式下,程式設計師需要自己動手“,臨時”構建一個請求並傳送出去,在很多情況下,程式可能還需要查詢接口庫以獲得一個操作必要的信息,這些過程都較靜態方式複雜。
- 速度緩慢。從功能上而言,客戶端的DII與碼根,伺服器端的DSI與框架應完成相同的功能(發起或接受請求以及編解碼),但由於靜態方式下類型信息都是確定的,因此,其實現可謂“量身定做”,速度較快;而動態方式實現時,類型信息都是動態獲知,速度不可避免地要慢一些。此外,程式往往要花去大量的時間來查詢接口庫,尤其當被查詢的接口定義存放在遠端的時候,這些查詢還會引發遠端調用,致使動態方式的速度變得更慢。
上述動態方式與靜態方式的速度比較,只是定性的,其定量的比較,在很大程度上依賴於具體ORB的實現,在《Instant CORBA》一書中,作者實驗的結論是,動態方式大約比靜態方式慢40倍。因此,程式設計師在考慮採用動態方式之前,應適當平衡其對靈活性和速度的要求。通常,在客戶端頻繁地調用伺服器對象,且伺服器對象無變化的情況下,可以使用靜態預編解碼根的方式;而當客戶端很少調用伺服器對象,或者客戶端在運行時發現伺服器對象時,可以考慮使用動態調用方式。在同一個程式中,可以既使用動態方式,又使用靜態方式,如圖所示。
套用
電信領域套用-TMN
TMN（電信管理網），隨著網路信息技術的飛速發展,網路設備日趨先進,網路業務日趨豐富,網路結構日趨複雜,這一切都需要一個智慧型化的網路管理系統來加以管理。
不同的國際組織和論壇制定了許多網路管理方面的標準和規範,例如ITU-T(國際電聯)制定的用於電信網路管理的TMN,IETF制定的用於Internet網路管理的SNMP協定,W3C制定的用於計算機桌面管理的WBEM,等等。TMN標準由一組協定文檔組成,主要包括ITU-TX.700系列和ITU-TM.3100系列建議,它涵蓋了電信管理網的體系結構、功能需求、信息模型、協定、一致性和方法學等諸多方面。它實際上是由ITU-TStudyGroup7和ISO(國際標準化組織)最早於1988年共同制定的,此後經歷了多次的修訂和完善。TMN不僅用於管理OSI(開放系統互聯)協定,也用於管理整個網路。
