基於CORBA的分散式程式設計（七） (轉)[@more@]

的分散式開發

分散式技術的基本原理

傳統的面向分析與物件導向設計方法。

常規的和OOD方法可以直接應用於分散式的分析和設計，然而傳統的環境（例如C＋＋或 pascal）在直接用於分散式應用系統的設計時遇到了問題。傳統的物件與訪問該物件的程式只能存在於同一程式中，並且只有相關程式設計語言的才能建立這些物件並感知這些物件的存在，而外部程式無法瞭解和訪問這些物件。這意味著在常規的分散式客戶/應用中，客戶程式不可能直接訪問異地服務程式中的常規物件。為了解決這個問題，人們提出了分散式物件的概念。

分散式物件技術

分散式物件存在於的任何地方，可被客戶應用以方法的形式訪問。至於分散式物件是使用何種程式設計語言和編譯器所建立，對客戶物件來說是透明的。客戶應用不必知道它所訪問的分散式物件在網路中的具體位置以及執行在何種上，該分佈物件與客戶應用可能在同一臺上，也可能分佈在由（如Inte）相連的不同計算機上。分佈物件具有動態性，它們可以在網路上到處移動。獨立於特定的程式設計語言和應用系統、可重用和自包含的軟體成分稱為軟構件。分散式物件是一種典型的軟構件。基於分佈物件技術的分散式應用開發就是分散式物件的開發和組裝。

分佈物件技術採用物件導向的多層客戶/伺服器計算模型，該模型將分佈在網路上的全部資源(無論是系統層還是應用層)都按照物件的概念來組織，每個物件都有定義明晰的訪問介面。建立和維護分佈物件實體的應用稱為伺服器，按照介面訪問該物件的應用稱為客戶。伺服器中的分佈物件不僅能夠被訪問，而且自身也可能作為其他物件的客戶。因此在分佈物件技術中，客戶與伺服器的角色劃分是相對的或多層次的。支援客戶訪問異地分佈物件的核心機制稱為物件請求(Object Request Broker,ORB)。ORB處於分佈物件技術的核心位置。

透過重用已有的軟構件，使用構件物件模型的軟體開發者可以像搭積木一樣構造應用程式。這樣不僅可以節省時間和經費，提高工作，而且可以產生更加規範、更加可靠的應用軟體。

分散式軟體構件具備以下幾個特徵

• 自描述構件必須能夠識別其屬性、存取方法和事件，這些資訊可以使開發環境將第三方軟體構件無縫地結合起來；

• 可定製--提供一個典型的圖形方式環境，軟體構件的屬性只能透過控制皮膚來設定；

• 可整合--構件必須可以被語言直接控制。構件也可以和指令碼語言連線或者與從程式碼級訪問構件的環境連線，這個特性使得軟體構件可以在非視覺化開發專案中使用；

• 連線機制--構件必須能產生事件或者具有讓程式設計師從語義上實現相互連線的其他機制。這意味著程式設計師可以很容易地向按鈕新增程式碼，使點中按鈕就可以影響其他構件的動作。

構件模型是為開發者定義軟體構件而建立的體系結構和集，使開發者可透過軟體構件的動態組合來建立應用系統。構件模型由構件與容器兩種主要成份構成。構件是具有可重用特性的基本軟體部件。容器用於存放和安排構件，實現構件間的互動。容器也可以作為另一個容器的構件使用。

分散式物件的服務

　　分散式物件服務包括支援分散式系統正常工作的各類基本的系統級服務，例如名字管理、事件通告、物件事務管理、物件生命期、時間同步、併發控制等。公共設施包括支援分散式系統高效開發和有效工作的各類面向領域的常規服務和工具，例如GUI服務、服務、電子服務、服務以及面向、模擬和金融等應用領域的領域構架等等。應用物件涉及各種應用軟體，它在物件服務和公共設施的幫助下完成相應的應用邏輯；ORB如同一條匯流排（Bus）把分散式系統中的各類物件和應用連線成相互作用的整體。

基於CORBA的分散式應用

分散式應用程式設計的主要問題

分散式應用程式設計的主要問題是確定建立在物件級上的客戶與服務物件的關係。從其最根本的功能來講，服務物件提供遠端介面，客戶物件呼叫遠端介面，客戶物件不需要了解遠端物件的位置以及實現細節，也不需要了解哪個ORB 用於物件之間的互動。按照實現過程，CORBA的實現分為兩種方式：命名服務物件引用方式和字串化物件引用方式。

下面介紹基於CORBA技術，用C++語言在網路中建立分散式應用的具體方法。……..~

中IDL的設計

從技術的角度來講，把系統設計成n層結構需要解決系統管理上的一些問題，如網路的延時，系統的反應時間，服務的可用性，負載的管理，分散式的緩衝和分散式的垃圾回收等。而且，對於每一個能提高系統效率的新的解決方案，也會隨之帶來新的問題。但是這些在設計大型的分散式應用系統的技術上的問題，都可以透過使用一些基本的設計方法和技巧來加以解決。

透過使用迭代（Iterator）的設計來定義idl語言，從而解決corba程式中諸如管理，緩衝，分散式垃圾回收等問題。

一、效能上的問題

雖然corba的體系結構簡化了網路的內在的複雜性。但它不能保證一定可以構造一個高

效能，高效率的系統，要實現這個目標，整個系統的設計一定要考慮到網路固有的結構，主要是以下的三個因素。

1．遠端呼叫的數量。

2．資料傳輸的數量。

3．不同資料型別的轉換和包裝。

如果在系統設計的開始加以考慮，這些問題將會得到解決。

在基於corba的體統設計中，idl在的設計中起了很大的作用，應為它定義了服務端程式相互遵循的介面標準。

二、IDL的設計

一個通常在IDL設計中被忽視的問題是哪一個介面用於伺服器端的應用程式，以及暫時的（transient）和持久的（persisent）corba物件。

1．一個伺服器端的應用程式是一個用於實現物件方法的，與語言無關的物件。在corba程式的模型中，伺服器端的程式透過可移植物件介面卡（Portable Object Adaptor,即POA）向系統註冊，從而能一直接受對它的呼叫。

2．同伺服器端的物件相比，暫時的corba物件並不用POA向系統註冊，他們在使用者向系統請求的過程中由伺服器端的應用程式生成。這些暫時的corba物件的生命週期不會超過所在程式或生成該物件的執行緒的生命週期，而且他們的物件控制程式碼並不公開。

3．永續性的corba物件同永續性的狀態相關聯，有著特殊的用途。

以下主要討論使用暫時的corba物件來管理大量資料的傳輸。這個方法在處理可能丟失資料的程式時非常有用，如下例所示：

使用者要查詢大量的資料，在得到了前20個資料後，另一個使用者也提出一個查詢，可能的情況是前面查詢的資料將丟失。在一個單程式的應用程式中，這不是一個問題。但是在分散式程式設計和設計中。將會佔用很多的網路頻寬和的處理時間。

基於如上所述，圖一提供了一個客戶端和伺服器端程式的互動相應的示意圖。客戶端的代理是個遠端的代理類，用於處理同遠端伺服器程式的連線以及把客戶端的請求傳送到伺服器端。客戶端向提供所需服務的伺服器端付出請求，伺服器端返回一組產品的資訊，如果這個結果中有n個產品，則N個元素經過引數轉換後在返回。初一看，這個設計是可行的，如果不發生前面所說的不可預料的情況的話。

 企業級應用程式的設計比較複雜。前期的設計對以後系統的效能會有很大的影響。而在CORBA環境中，IDL的設計就顯得尤為重要。好的IDL設計，充分利用的API，如計時器，垃圾回收機制，集合能大大的提高系統的效能。從而能構造一個強壯的，高度可用的分散式系統。

 :namespace prefix = o ns = "urn:schemas--com::office" />