【正文】 到真正的分布式運行環(huán)境中。在分布式軟件開發(fā)領域也不例外。開發(fā)人員通過分析問題域中實體的屬性、行為、約束等，抽象出能描述這些實體共同結(jié)構(gòu)與特征的概念，然后在計算機中利用類建立這些概念的系統(tǒng)模型，再通過類創(chuàng)建具體的對象實例模擬問題域的實體行為。除了封裝與信息隱藏、數(shù)據(jù)抽象、模塊化等特征外，面向?qū)ο蠹夹g(shù)的最主要特色是繼承與多態(tài)性。多態(tài)性有十分廣泛的含義，這里主要是指運行期間程序表現(xiàn)出來的多態(tài)性，它建立在繼承與動態(tài)綁定的基礎上，使得一個對象可以具有多種不同的動態(tài)類型，從而大大提高了面向?qū)ο蟪绦虻谋磉_能力。例如由開放軟件基金會（OSF）于1992年發(fā)布的分布式計算環(huán)境（Distributed Computing Environment，縮寫為DCE）采用的是遠程過程調(diào)用（Remote Procedure Call，縮寫為RPC）技術(shù)，RPC支持開發(fā)人員進行結(jié)構(gòu)化程序設計，使得客戶程序可以像調(diào)用本地過程一樣調(diào)用服務程序中的過程。當前幾種主流的分布式軟件體系結(jié)構(gòu)均融合了分布式計算與面向?qū)ο蠹夹g(shù)，包括OMG的公共對象請求代理體系結(jié)構(gòu)（CORBA）、Microsoft的分布式組件對象模型（DCOM）、Sun Microsystems的企業(yè)版JavaBeans（EJB）等。軟件體系結(jié)構(gòu)關心的正是整個軟件系統(tǒng)的結(jié)構(gòu)，它決定一個軟件系統(tǒng)由什么樣的組件構(gòu)成，以及這些組件之間的交互關系如何，并提供一種模式指導組件的合成。典型的軟件體系結(jié)構(gòu)風格有設計圖形用戶界面（GUI）常用的事件驅(qū)動風格、設計操作系統(tǒng)常用的層次化設計風格、設計編譯程序常用的管道與過濾器風格、設計分布式應用程序常用的客戶機／服務器風格等。分布式軟件系統(tǒng)通?；诳蛻魴C／服務器（client/server）模型，因而組成系統(tǒng)的最核心組件是客戶程序與服務程序，然而不同的分布式軟件體系結(jié)構(gòu)還決定了各自不同的組件以及這些組件之間的交互方式。本書主要從軟件體系結(jié)構(gòu)的角度探討分布式軟件系統(tǒng)的有關課題。167。由于在客戶機／服務器數(shù)據(jù)庫系統(tǒng)中將系統(tǒng)的處理任務劃分為客戶系統(tǒng)與數(shù)據(jù)庫服務器兩端，因而大量的數(shù)據(jù)庫操作可在后端運行，工作站只需能夠運行前端軟件即可。其實客戶機／服務器體系結(jié)構(gòu)并不僅僅局限于數(shù)據(jù)庫應用，這種計算模型有著更廣義的定義。按照這一定義，局域網(wǎng)中的工作站與文件服務器之間是一種客戶機／服務器模型，其中工作站向文件服務器發(fā)送服務請求，例如要求訪問文件或網(wǎng)絡打印等，文件服務器接收這些請求后為工作站提供這些服務?？蛻魴C與服務器是一個相對的概念，一個服務器可能是另一個服務器的客戶機，一個客戶機也可能是另一個客戶機的服務器。一個常見的簡單例子是在過程式程序設計中，執(zhí)行函數(shù)調(diào)用表達式的子程序與實現(xiàn)函數(shù)體的子程序可看作一種客戶機／服務器模型，其中函數(shù)實現(xiàn)方是服務程序，函數(shù)調(diào)用方是客戶程序。在普通的函數(shù)調(diào)用中，對于函數(shù)實現(xiàn)與函數(shù)調(diào)用雙方最為重要的是兩者之間的接口（又稱界面，即函數(shù)原型說明）以及通信協(xié)議（例如雙方對調(diào)用風格的約定，決定采用C還是Pascal的調(diào)用風格）。函數(shù)原型一般都包含了函數(shù)名字、返回值類型、參數(shù)個數(shù)與類型等，更完善的接口還可能包括可能引發(fā)的異常、必須滿足的前置條件與后置條件等。分布式軟件系統(tǒng)絕大多數(shù)采用客戶機／服務器體系結(jié)構(gòu)，其中最重要的仍是上述接口與通信協(xié)議的問題，只不過由于客戶端與服務端在物理層次上的分離，導致通信協(xié)議更加復雜，并且可靠性、安全性、性能等因素顯得更加突出。雖然分布式軟件與集中式軟件在邏輯層次有許多方面是一致的，但在物理層次兩者仍有許多重大區(qū)別。首先，整個系統(tǒng)的所有計算任務可在客戶端與服務端兩邊進行負載重新分布，使得RISC工作站與微機建立的計算機網(wǎng)絡系統(tǒng)可以完成以前只有價格昂貴的大型機（mainframe）才可勝任的工作，實現(xiàn)企業(yè)計算規(guī)模的下行（downsizing）；而與傳統(tǒng)的基于局域網(wǎng)的應用系統(tǒng)相比，客戶端與服務端的分離大大減少了網(wǎng)絡傳輸?shù)臄?shù)據(jù)量，可有效地提高系統(tǒng)的運行效率，實現(xiàn)企業(yè)計算規(guī)模的上行（upsizing）。此外，采用客戶機／服務器計算模型的軟件系統(tǒng)具有更好的可擴充性，例如可在服務端功能不變的前提下對服務端程序進行改進或擴充，而這種改進與擴充不會影響到客戶端的應用程序。例如開發(fā)人員不得不分別開發(fā)客戶端與服務端的應用程序，并力求保持兩端應用程序的一致性，軟件系統(tǒng)的部署與維護也更加困難。本書將主要討論客戶機／服務器體系結(jié)構(gòu)設計中的這些復雜問題，包括如何更好地顯式表達客戶端與服務端雙方的公共接口，客戶端應用程序與服務端應用程序雙方如何進行通信，客戶端應用程序如何查找服務程序，如何保證服務端應用程序的可用性等等。在兩層模型的設計中，由客戶應用程序直接處理對數(shù)據(jù)庫的訪問。同時，數(shù)據(jù)庫由眾多客戶程序直接訪問，導致數(shù)據(jù)的完整性與安全性難以維護?？蛻舫绦蚺c數(shù)據(jù)庫的連接被中間層屏蔽，客戶程序只能通過中間層間接地訪問數(shù)據(jù)庫。這些位于中間層的中間件（middleware）又稱應用服務程序（application server），因為它們實際上表達了一個企業(yè)處理信息的主要業(yè)務邏輯（business logic），即企業(yè)的系統(tǒng)模型與功能模型，而客戶程序僅實現(xiàn)圖形用戶界面，完成終端用戶與業(yè)務邏輯之間的交互。與典型的兩層模型相比，三層模型或多層模型可更好地支持對企業(yè)業(yè)務邏輯的集中控制與管理。 一個簡單的例子 問題背景電信收費是當前老百姓關心的熱點問題，明明白白消費是每一個消費者的合理要求，但如果打印并郵寄每月話費清單無疑會額外花費大量的人力、物力與財力。本小節(jié)以一個簡化的電話計費查詢程序為例，向讀者介紹分布式應用程序的基本概念，并通過對這一簡單應用程序的討論引出分布式軟件體系結(jié)構(gòu)中需要考慮的更高級課題?？蛻舫绦蛑荒芡ㄟ^服務程序間接地訪問關系數(shù)據(jù)庫，因而該例子程序?qū)儆谝环N典型的三層設計模型。 數(shù)據(jù)庫Telephone 表TelephoneDirectorynumber 文本類型；電話號碼subscriber 文本類型；電話用戶姓名 表CallHistorynumber 文本類型；電話號碼（索引，允許重復）startTime 日期/時間類型；起始通話時間endTime 日期/時間類型；終止通話時間 話費查詢程序中的數(shù)據(jù)庫設計其中，表TelephoneDirectory記錄了所有用戶的電話號碼，以number為主關鍵碼；表CallHistory記錄了所有電話的通話歷史，其中number是外部關鍵碼，建立該屬性的允許重復的索引。由于同一名字的用戶可能登記多個電話號碼（例如一個用戶同時擁有兩部住宅電話和一部移動電話），因而電話計費查詢程序除了提供根據(jù)電話號碼查詢話費清單外，還可能提供以用戶名字進行查詢。程序中利用JDBC/ODBC訪問數(shù)據(jù)庫，因而支持使用多種不同的數(shù)據(jù)庫管理系統(tǒng)，只要這些數(shù)據(jù)庫管理系統(tǒng)提供了ODBC接口，如Microsoft Access、Microsoft SQL Server、Sybase、Oracle等。假設我們選用了Microsoft Access數(shù)據(jù)庫，則這一安裝步驟為：在Windows 98的控制面板中打開“ODBC數(shù)據(jù)源（32位）”，單擊“添加”按鈕后選擇一個驅(qū)動程序（此處應為“Microsoft Access Driver (*.mdb)”），然后為數(shù)據(jù)源命名并選擇相關聯(lián)的Access數(shù)據(jù)庫文件。數(shù)據(jù)獨立性使得在數(shù)據(jù)庫中表的屬性或表之間的關聯(lián)發(fā)生某些變化時，程序員無需對應用程序作任何修改。在不同的數(shù)據(jù)庫管理系統(tǒng)中，存儲過程可能有不同的名字，如保留過程、觸發(fā)器、查詢等。本節(jié)的例子程序利用該存儲過程實現(xiàn)對數(shù)據(jù)的查詢。 根據(jù)用戶名字查詢通話記錄的存儲過程 客戶程序與服務程序之間的通信客戶程序與服務程序之間需要通信以交換信息?？蛻舫绦蚶脠D形用戶界面與終端用戶進行交互，從終端用戶獲取電話用戶的名字并作為參數(shù)向服務程序發(fā)出查詢請求，然后將服務程序返回的查詢結(jié)果顯示給終端用戶瀏覽。一種更好的通信方式是使用遠程過程調(diào)用（RPC），它將客戶程序與服務程序之間的通信接口抽象為過程調(diào)用層次，程序員可像調(diào)用本地過程一樣去調(diào)用遠程過程，由RPC系統(tǒng)完成參數(shù)與返回值的打包、解包與傳輸?shù)鹊讓尤蝿?。本小?jié)的例子程序采用了抽象層次更高的遠程方法調(diào)用（RMI）。 遠程方法調(diào)用RMI可看作一種簡化的、專用于Java平臺的CORBA模型，由JDK 。RMI注冊表rmiregistry是運行在服務器上的一個后臺進程，必須在服務程序啟動之前就已啟動完畢，它相當于客戶程序與服務程序之間的通信網(wǎng)關。RMI體系結(jié)構(gòu)采用典型的層次設計風格，從上至下分別由樁／框架層、遠程引用層和傳輸層組成，各層之間明確定義了接口與協(xié)議。樁負責將遠程調(diào)用請求通過遠程引用層轉(zhuǎn)發(fā)給服務端的框架（skeleton），再由服務端的框架分派給真正的遠程對象實現(xiàn)。遠程引用層完成調(diào)用的語義，例如決定服務程序的對象是單個對象，還是需要與多個位置進行通信的復制對象，這些語義由遠程對象的實現(xiàn)提供。傳輸層負責建立與管理連接，跟蹤遠程對象，以及將調(diào)用請求分派給合適對象。遠程調(diào)用的返回值送回客戶端的路線是：首先經(jīng)過服務端的框架、遠程引用層和傳輸層，再向上經(jīng)過客戶端的傳輸層、遠程引用層和樁。首先，Java語言專用的對象串行化技術(shù)可將對象透明地傳送到不同地址空間，樁與框架利用對象串行化技術(shù)打包（marshal）與解包（unmarshal）遠程調(diào)用的參數(shù)與返回值。 接口定義一個基于RMI的多層模型分布式應用程序通常包括以下幾部分：①遠程接口，規(guī)定了客戶程序與服務程序進行交互的界面；②遠程對象實現(xiàn)，為遠程接口規(guī)定的每一個方法提供真正的實現(xiàn)；③服務程序，遠程對象并不是服務程序本身，它需要由服務程序創(chuàng)建并注冊，服務程序中的這些真正提供服務的對象實例又稱伺服對象（servant）；④客戶程序，利用服務程序中伺服對象提供的服務完成某一功能。Java提供了接口與類兩種機制：接口不含數(shù)據(jù)表示方法與操作的具體實現(xiàn)，因而適用于定義對象的規(guī)格說明（specification），一個接口可以同時繼承多個接口；類給出了數(shù)據(jù)表示方法與操作實現(xiàn)，因而適用于定義對象的實現(xiàn)（implementation），僅支持對類的單繼承。程序11給出了例子程序中通話記錄管理器的遠程接口定義。public interface CallManagerInterface extends { // 根據(jù)電話用戶名字查詢通話記錄。} 服務端程序程序12定義的類CallManager為遠程接口CallManagerInterface中的每一個遠程方法提供了具體實現(xiàn)。程序13所示ServerApplication是服務程序的主程序，它必須首先裝入安全管理器，用于保證動態(tài)裝載的類不會執(zhí)行某些敏感操作，如果未指定安全管理器則不允許裝入任何RMI類。public class CallManager extends implements CallManagerInterface{ // 屬性定義 protected database。 public CallManager() throws { database = new ()。 public synchronized getCallHistory(String subscriber) throws { String sql = 。 // 返回的二維表模型 (Respond to client request: + subscriber)。 + subscriber + 39。 rs = (sql)。 ()。 (1)。 }}程序13 // 服務程序的主程序public class ServerApplication{ final static String JDBC_DRIVER = 。 // 加載JDBC驅(qū)動程序 try { (JDBC_DRIVER)。 (1)。 // 用名字CallManagerServant001注冊伺服對象 (CallManagerServant001, callManager)。 (1)。 (1)。 }}程序14定義的DatabaseAccess類與程序15定義的DatabaseTableModel類均用于抽象JDBC訪問數(shù)據(jù)庫的行為，在實際應用中我們通常會設計更完善、更個性化的數(shù)據(jù)庫訪問程序包來包裝JDBC的API。DatabaseTableModel負責將數(shù)據(jù)庫查詢結(jié)果轉(zhuǎn)換為二維表數(shù)據(jù)模型的形式，方便利用Swing的二維表控件顯示查詢結(jié)果。程序14 // 實現(xiàn)JDBC與數(shù)據(jù)庫的連接package Database。public class DatabaseAccess{ // 常量定義 protected final String DATABASE_NAME = jdbc:odbc:Telephone。 // 為數(shù)據(jù)庫建立的連接 protected Statement statement。 // 將調(diào)用的SQL存儲過程語句 // 行為定義 // 構(gòu)造方法，建立與數(shù)據(jù)庫的連接。 // 如果連接成功則檢測是否有警告信息 SQLWarning warn = ()。 warn = ()。 callable = null。 (1)。