初步了解 Corba 的模塊模型概況

2019-11-18 12:42:05

字體：大中小

來源：轉載

供稿：網友

　　介紹:
　　分布式計算中間件，如Corba，快速發展，當激烈的和全球的競爭使以傳統方式開發和維護復雜的系統越來越困難的時候。Corba 可以讓你調用在分布是對象上的操作，而不用關心它的應用底層的環境。傳統的Corbar定義了一個軟總線框架，制定了有標準接口的對象服務，利用Corba我們可以集成和組合大型，復雜的分布式應用系統。但傳統的Corba有它的缺點：
　　
　　No standard way to deploy object implementations:
　　
　　沒有標準的配置對象應用的方式。如：沒有標準的方式分布對象應用，在它們的執行上下文安裝，或在特定的ORB激活應用。因此，系統設計者必須用ad hoc策略去實例化在系統中的對象。進一步說，因為對象可能要互相依靠，實例化可能在一個大型的系統變得復雜。
　　
　　??Lack of support for common PRogramming idioms for CORBA servers:
　　
　　Corba 的說明提供了豐富的應用服務的特性。在某些的應用域，僅僅有限的特性被應用。結果，通過能自動產生應用普通應用實例Corba代碼的工具能支持必須的特性，是期望的。如：在Corba 2.2說明中，介紹了POA，它是一個引導客戶端的請求到具體的對象應用的機制。POA提供了標準的API去登記對象應用，去活，或激活對象應用。POA是靈活的Corba編程模型模塊，并且提供了大量的規則配置它的行為。然而，重要一類應用僅僅用其中的一部分，但是服務開發者不得不去學習如何配置許多的規則，為了得到想要的行為。
　　
　　??Difficulty extending object functionalities:
　　
　　傳統的Corba對象模型，對象僅能通過繼續來擴展它的應用。為了支持新的新的界面，應用開發者必須：1 定義新的，從要求的界面繼續，的IDL界面； 2 應用新的界面；3 分配應用到服務器端。然而，多重繼續在Corba Idl 是易碎的，因為重載在IDL是不可以的，因為像C的語言缺乏重載。
　　
　　因此，以上的介紹限制了應用。進一步說，應用可以需要暴露相同的IDL界面多次，為了答應開發者多個應用或多個服務的實例，通過一個入口點。相反，多重繼續使暴露相同的界面多次或決定哪一個是提供給客戶端最原始界面，提供成為不可能。
　　
　　??Availability of CORBA Object Services is not defined a priori:
　　
　　Corba說明沒用要求在運行時，哪一個對象服務是提供的。結果，對象開發者必須用 ad hoc 策略去配置和激活這些服務。
　　
　　??No standard object lifecycle management:
　　
　　雖然Corba對象服務定義了生命周期服務，但它并不是要求的。因此，客戶端要明顯內容去治理對象的生命周期，以 ad hoc　方式。進一步說，通過生命周期服務控制的Ｃｏｒｂａ對象的開發者必須明白這個事實，和必須定義附加的界面去控制對象生命周期。定義這些的界面使單調的過程，應該自動進行，但較早的Corba說明缺乏。
　　
　　CORBA說明的不足，早先的和包括在VERSION 2.3的，以上列出的，經常導致緊密的結合度，和難于設計，重用的，展開的，維護的和擴展的 ad-hoc 對象應用。
　　
　　為了彌補以上的不足，OMG接受了CORBA Component Model（CCM）作為CORBA 3的一部分。CCM擴展了傳統的CORBA對象模型，通過定義答應應用開發者去應用，治理，配置，和展開集成了Corba服務的模塊的特性和服務，如容忍度，安全事務和事件服務，在一個標準的環境。CCM標準不僅提高了服務器軟件重用性，也為動態的Corba應用配置提供了巨大的靈活性。隨著Corba的應用增加，CCM表現了出適合可升級的，應用要求嚴格的client/server應用。這章，我們描述CCM定義的主要的特性和服務，并圖示CCM結構的好處。
　　　初步了解 Corba 的模塊模型概況（圖一）

　　模塊開發者定義模塊應用支持的IDL界面；下一步，利用CCM提供的工具應用模塊。結果的模塊應用被打包進動態連接苦。最后，CCM提供的分配機制用于分配模塊，在模塊服務器上（component server）。模塊服務器是通過處理過程主管應用，通過相關的DLL。因此，在模塊服務器上，模塊執行和提供，去處理客戶端的請求。一個好處是，CCM標準了開發的流程，下面，我們在CCM中的描述模塊，從客戶端的觀點和模塊開發者的觀點，而且，我們描述了為支持CCM，ORB的擴展。
　　
　　Client View
　　
　　下面，我們介紹從CLIENT的視點來看模塊是什么和如何應用模塊。
　　初步了解 Corba 的模塊模型概況（圖二）

　　一個模塊 Foo 實例的參考曾現給client端，像一個有規則的Corba對象指引到界面Foo的實例。因此，對模塊不清楚的Client端能調用操作，通過一個到模塊對象等價界面的對象指引，能唯一鑒別這個模塊實體。通過有規則的Corba對象，抹開的等價界面能從另外的界面繼續，稱作模塊的支持界面。如我們開始提到的，用繼續是難以擴展Corba對象的。因為對象不能和多個界面相連，用一個單一的應用實體。為了解決這個問題，CCM增加facets到模塊中，Facets，也是提供的界面，是模塊提供的界面，通過繼續不必要連接到模塊的支持界面。CCM多面體在設計上和Extension Interface 模式一致，類似于COM（Microsoft's Component Object Model）中的模塊界面。
　　
　　在Corba::CCMObject界面內，一個導航界面被定義，所有的等價的模塊界面繼續于它。Clients用在導航界面，列舉的所有模塊提供的多面體。因此，任何的擁有對多面體的指引的Client能用標準的get_component()操作取得到模塊等價界面的引導。
　　
　　增加多面體到CCM對象模型顯著提高了模塊的重用性。例如，新的界面能在新的模塊提供，不會影響到存在的模塊客戶端。進一步，新的客戶端能檢查是否一個模塊提供一定的界面，通過有標準的CCM瀏覽界面。因為 CCM答應幾個無關界面和一個模塊應用實體的綁定。客戶端不需要清楚知道模塊的應用細節，為了用它提供的可選擇界面。
　　
　　Component Lifecycle Management:
　　
　　對于模塊服務器，正確處理生命周期治理問題和對于客戶端，幫助模塊服務器治理它們的模塊實例的生命周期，是很重要的。例如：一個模塊能同時像多個Client端輸出多個服務。同樣，一個模塊服務器能容許多的模塊。而且，一個模塊服務器必須知道何時創建一個模塊實例和何時移去，為了防止資源的泄漏。雖然Corba對象服務說明定義了Liftcycle服務，但并不是一定要的，對于普通的Corba對象。因此，Corba開發者經常應用它們自己的 ad hoc生命周期治理策略。實際上，Corba說明的靈活性把客戶端和對象界面的特定應用緊密結合起來。為了標準化模塊生命周期治理界面，因此，CCM介紹了一個新詞，“home”，指明每一模塊的生命周期治理策略?？蛻舳四苡胉home'界面去控制它使用的每一模塊實例的生命周期。每一home界面準確治理一種模塊的類型。Home 可能是有鍵的或無鍵的。無鍵的 home 經常支持factory操作，創建新的模塊的實例。相反，有鍵的支持finder操作，客戶端能用索引進入持久模塊的實例，通過用客戶端提供的key。為了向模塊服務器表明一個特定的模塊不再需要，客戶端能調用remove_component()操作，在home策略界面上去通知模塊服務器，模塊服務器能決定如何去除模塊。
　　
　　Component Usage Scenarios:
　　
　　為了用模塊，客戶端必須先得到模塊`home'界面，然而，客戶端要求一個標準的啟動機制去定位模塊的home界面。為了簡化自舉過程，提供的模塊的home的指引，能存在中心數據庫。因此，所有的需要自舉自己的客戶端向中心數據庫得到指引。為了進入中心數據庫，CCM說明定義了HomeFinder 界面，和Corba的命名服務相似?？蛻舳碎_始用標準的Corba自舉API resolve_initial_references(“HomeFinder”)去得到對象到HomeFinder 界面的指引. CCM HomeFinder 應用客戶端用來定位的模塊home的目錄服務，得到對home界面的引導，這時，調用正確的工廠方法去創建或發現目標模塊的指引.

上一篇：用RMI編寫實時聊天程序

下一篇：J2EE、CORBA、DNA三種主流中間件平臺比較（1）