Corba的模組模型概況

介紹:

　　分散式運算中介軟體，如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結構的好處。

 

　　模組開發人員定義模組應用支援的IDL介面；下一步，利用CCM提供的工具應用模組。結果的模組應用被打包進動態串連苦。最後，CCM提供的分配機制用於分配模組，在模組伺服器上（component server）。模組伺服器是通過處理過程主管應用，通過相關的DLL。因此，在模組伺服器上，模組執行和提供，去處理用戶端的請求。一個好處是，CCM標準了開發的流程，下面，我們在CCM中的描述模組，從用戶端的觀點和模組開發人員的觀點，而且，我們描述了為支援CCM，ORB的擴充。

　　Client View

　　下面，我們介紹從CLIENT的視點來看模組是什麼和如何應用模組。

 

　　一個模組 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介面的引導， 這時，調用正確的Factory 方法去建立或發現目標模組的指引.