第五章 基於CORBA的分佈式軟件開發
5.1 分佈式技術的基本原理
5.1.1傳統的面向對象分析與面向對象設計方法。
常規的OOA和OOD方法可以直接應用於分佈式系統的分析和設計，然而傳統的OOP環境（例如C＋＋或object pascal）在直接用於分佈式應用系統的程序設計時遇到了問題。傳統的對象與訪問該對象的程序只能存在於同一進程中，並且只有相關程序設計語言的編譯器才能創建這些對象並感知這些對象的存在，而外部進程無法瞭解和訪問這些對象。這意味着在常規的分佈式客戶/服務器應用中，客戶進程不可能直接訪問異地服務進程中的常規對象。爲了解決這個問題，人們提出了分佈式對象的概念。
5.1.2分佈式對象技術
分佈式對象存在於網絡的任何地方，可被遠程客戶應用以方法調用的形式訪問。至於分佈式對象是使用何種程序設計語言和編譯器所創建，對客戶對象來說是透明的。客戶應用不必知道它所訪問的分佈式對象在網絡中的具體位置以及運行在何種操作系統上，該分佈對象與客戶應用可能在同一臺計算機上，也可能分佈在由廣域網（如Internet）相連的不同計算機上。分佈對象具有動態性，它們可以在網絡上到處移動。獨立於特定的程序設計語言和應用系統、可重用和自包含的軟件成分稱爲軟構件。分佈式對象是一種典型的軟構件。基於分佈對象技術的分佈式應用開發就是分佈式對象的開發和組裝。
分佈對象技術採用面向對象的多層客戶/服務器計算模型，該模型將分佈在網絡上的全部資源(無論是系統層還是應用層)都按照對象的概念來組織，每個對象都有定義明晰的訪問接口。創建和維護分佈對象實體的應用稱爲服務器，按照接口訪問該對象的應用稱爲客戶。服務器中的分佈對象不僅能夠被訪問，而且自身也可能作爲其他對象的客戶。因此在分佈對象技術中，客戶與服務器的角色劃分是相對的或多層次的。支持客戶訪問異地分佈對象的核心機制稱爲對象請求代理(Object Request Broker,ORB)。ORB處於分佈對象技術的核心位置。
通過重用已有的軟構件，使用構件對象模型的軟件開發者可以像搭積木一樣快速構造應用程序。這樣不僅可以節省時間和經費，提高工作效率，而且可以產生更加規範、更加可靠的應用軟件。
5.2 分佈式軟件構件具備以下幾個特徵
• 自描述構件必須能夠識別其屬性、存取方法和事件，這些信息可以使開發環境將第三方軟件構件無縫地結合起來；
• 可定製--提供一個典型的圖形方式環境，軟件構件的屬性只能通過控制面板來設置；
• 可集成--構件必須可以被編程語言直接控制。構件也可以和腳本語言連接或者與從代碼級訪問構件的環境連接，這個特性使得軟件構件可以在非可視化開發項目中使用；
• 連接機制--構件必須能產生事件或者具有讓程序員從語義上實現相互連接的其他機制。這意味着程序員可以很容易地向按鈕添加代碼，使點中按鈕就可以影響其他構件的動作。
構件模型是爲開發者定義軟件構件而建立的體系結構和API集，使開發者可通過軟件構件的動態組合來建立應用系統。構件模型由構件與容器兩種主要成份構成。構件是具有可重用特性的基本軟件部件。容器用於存放和安排構件，實現構件間的交互。容器也可以作爲另一個容器的構件使用。
5.3 分佈式對象的服務
分佈式對象服務包括支持分佈式系統正常工作的各類基本的系統級服務，例如名字管理、事件通告、對象事務管理、對象生命期、時間同步、併發控制等。公共設施包括支持分佈式系統高效開發和有效工作的各類面向領域的常規服務和工具，例如GUI服務、數據庫服務、電子郵件服務、系統管理服務以及面向電信、仿真和金融等應用領域的領域構架等等。應用對象涉及各種應用軟件，它在對象服務和公共設施的幫助下完成相應的應用邏輯；ORB如同一條總線（Bus）把分佈式系統中的各類對象和應用連接成相互作用的整體。
5.4 基於CORBA的分佈式應用
5.4.1分佈式應用程序設計的主要問題
分佈式應用程序設計的主要問題是確定建立在對象級上的客戶與服務對象的關係。從其最根本的功能來講，服務對象提供遠程接口，客戶對象調用遠程接口，客戶對象不需要了解遠程對象的位置以及實現細節，也不需要了解哪個ORB 用於對象之間的交互。按照實現過程，CORBA的實現分爲兩種方式：命名服務對象引用方式和字符串化對象引用方式。
下面介紹基於CORBA技術，用C++語言在網絡中建立分佈式應用的具體方法。……..~
5.4.2 Corba中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個數據後，另一個用戶也提出一個查詢，可能的情況是前面查詢的數據將丟失。在一個單進程的應用程序中，這不是一個問題。但是在分佈式編程和設計中。將會佔用很多的網絡帶寬和cpu的處理時間。
基於如上所述，圖一提供了一個客戶端和服務器端程序的交互相應的示意圖。客戶端的代理是個遠端的代理類，用於處理同遠端服務器程序的連接以及把客戶端的請求發送到服務器端。客戶端向提供所需服務的服務器端付出請求，服務器端返回一組產品的信息，如果這個結果中有n個產品，則N個元素經過參數轉換後在返回。初一看，這個設計是可行的，如果不發生前面所說的不可預料的情況的話。
企業級應用程序的設計比較複雜。前期的設計對以後系統的性能會有很大的影響。而在CORBA環境中，IDL的設計就顯得尤爲重要。好的IDL設計，充分利用JDK的API，如計時器，垃圾回收機制，集合框架能大大的提高系統的性能。從而能構造一個強壯的，高度可用的分佈式系統。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/helloworlder/archive/2003/07/03/20370.aspx