架構電子政務總體應用架構設計指引

1、長風聯(lián)盟電子政務總體應用架構設計指南研究報告長風開放標準平臺軟件聯(lián)盟二。七年五月目錄第一章引論1L1本指南的目的1本指南依據(jù)的長風聯(lián)盟參考文檔1什么是SOA電子政務總體應用架構1L4什么是SOA電子政務總體應用架構設計2本指南的章節(jié)組織7L6應用架構設計的主要內(nèi)容7應用架構分解結構與參考架構(RA)7應用架構設計環(huán)境8應用架構設計干系人8L10應用架構設計指南與長風聯(lián)盟其他文檔的關系9 第二章應用架構設計知識領域、原則和過程組10應用架構設計知識領域10SOA設計方法學10數(shù)據(jù)建模方法學10面向流程設計方法學11技術領域架構設計方法學11通用架構設計方法學13向?qū)ο笤O計方法學19服務設計原則2

2、1顯式定義邊界21自治性23服務共享大綱和契約，但不共享類24服務兼容性基于策略25訪問的開放性26隨時可用26I 27服務分級28松散耦合282210可重用的服務及服務接I I設計管理29標準化的接I I 29支持各種消息模式30精確定義服務接I I 30應用架構設計過程組31架構啟動過程組33述33務模型合理性初步分析34231.3架構范圍定義35功能架構35業(yè)務分類35架構分析過程組36.2概述36組織模型分析37數(shù)據(jù)模型分析38流程模型分析385 分析 39外部接I I分析392.327關鍵用例分析392.328關鍵技術點分析402.329服務定義40.10干系人分析402.3211外

3、部接I I設計過程412.3212服務設計過程42架構設計過程組422.3.3概述42233.2總體架構設計442.333框架選擇442.334數(shù)據(jù)模型設計442.335流程設計44技術點設計442.337外部接I I設計45UI 設計 462.339服務設計過程46質(zhì)量設計46設計視圖分配462.3312部署視圖設計462.3313團隊開發(fā)管理設計47架構實現(xiàn)過程組47.4概述47工作績效信息收集47架構實現(xiàn)47235架構測試過程組47概述472.352測試規(guī)劃482.353服務測試482.354功能測試482.355性能測試492.356技術指標測試492.357架構優(yōu)化49架構監(jiān)控過程組

4、49.6概述492.362業(yè)務模型合理性跟蹤492.363績效報告50237架構收尾過程組50.7概述50管理收尾50架構進化50第三章應用架構分解結構50總體架構50基礎支撐層51全景圖51硬件/網(wǎng)絡層設計52主機設計53網(wǎng)絡規(guī)劃55存儲/備份設計55其它硬件設備583.2.3系統(tǒng)軟件層設計58操作系統(tǒng)選型58應用服務器選型59數(shù)據(jù)庫服務器選型60其它系統(tǒng)軟件選型613.2.4支撐軟件層設計61技術架構選擇61軟件框架設計64基礎構件/服務設計64A其它構件64與架構其它層關系64相關規(guī)范與標準65務運行、管理和監(jiān)控環(huán)境653.3政務資源層65政務資源層總體架構65統(tǒng)資源層面臨的問題65架構

5、目標66架構總圖及描述66務資源層應用前景和趨勢67政務信息資源68政務信息資源的封裝68政務信息資源的接入69政務信息資源的管理69政務信息資源的訪問703.3.3部門業(yè)務應用資源71應用資源的封裝71333.2應用資源的接入723.333應用資源的管理723.334應用資源的統(tǒng)一訪問73政務目錄資源733.3.4資源元數(shù)據(jù)描述74334.2資源編目76334.3安全管理773.344基于目贏資源共享體系773.4支撐服務層79全景圖79描述 79服務構成803.4.3公共服務80343.2領域服務873.5業(yè)務應用層89全景圖89描述 89基于SOA業(yè)務應用層的業(yè)務應用模式90從軟基礎設施

6、的視角研究模式分類91基于SOA的資源共享應用模式933.533基于SOA的業(yè)務協(xié)同應用模式94基于SOA的不同服務渠道的應用模式943.5.4與其它各層的關系95354.1業(yè)務應用層對基礎支撐層的要求953.542業(yè)務應用層對展現(xiàn)服務層的支持963.543業(yè)務應用層對安全保障體系的要求96展現(xiàn)服務層97全景圖97362適配器98363支撐運行環(huán)境98具體的展現(xiàn)服務99365展現(xiàn)服務相關的標準體系、工具集、安全保障體系99工具集100全景圖1012開發(fā)和部署服務1013.721服務的體系架構/模型1033.722體系架構說明1043.723功能模塊概述1043.724功能模塊間關系概述1053

7、.725功能詳細說明1053.726與其他服務關系108標準規(guī)范體系110全景圖110基礎支撐層110政務資源層113支撐服務層114業(yè)務應用層118展現(xiàn)服務層118安全保障體系119安全保障體系121 全景圖121391.2安全在整個SOA體系中的作用和位置1233.9.L3安全保障體系的總體邏輯框架124391.4安全保障體系中采用的標準規(guī)范體系框架圖1253.9.2 SOA安全實施要點及方法125392.1端到端SOAP消息交換的安全1253.922 Web服務策略機制126392.3令牌轉換和信任域1273.924安全對話128392.5跨域的互信任操作1293.926 SOA系統(tǒng)的安

8、全管理制度130第四章 應用架構設計路線圖130全景圖130基礎 SOA132網(wǎng)絡化SOA132流程支撐的SOA133附錄A術語表136附錄B架構設計資料參考137附錄C案例描述-137 -第一章引論本指南的目的基本目的是識別SOA電子政務領域應用架構設計知識體系普遍公認為 良好做法的那一部分。識別,指一般概括性介紹，而非詳盡無遺漏的說明。哥遇公認，指介紹的知識和做法在絕大多數(shù)情況下適用于絕大多數(shù)的架 構設計，其價值和實用性也得到了人們的廣泛認同。良好做法指一致認為,正確應用這些技能、工具和技術能夠增加范圍 極為廣泛的各種不同架構設計成功的機會。良好做法并不是說這些知識和做 法一成不變地應用于

9、或應當應用于所有的架構設計：架構設計團隊負責架構的裁剪和擴展。本指南還旨在作為該職業(yè)和實踐一個共同的求通匚編，為討論、書寫和 應用架構設計方面的問題提供便利。這種術語匯編是一種職業(yè)必不可少的組 成部分。本指南還提供了一個參考的電子政務應用架癡并結合一個具體案例講 解如何在電子政務領域進行基于SOA的應用架構設計。本指南用來指導電子政務領域政務系統(tǒng)建設和政務系統(tǒng)之間的整合任務 的架構設計。而附錄B列出了架構設計資料的其他來源。本指南依據(jù)的長風聯(lián)盟參考文檔SOA-RA-TF制定的SOA參考架構白皮書SOA-AP-TF制定的SOA電子政務總體技術架構與解決方案什么是SOA電子政務總體應用架構長風聯(lián)盟

10、依據(jù)國家電子政務總體框架，遵循國家電子政務標準，參照北京市電子政務總體技術框架，結合長風聯(lián)盟SOA電子政務解決方案的 實際情況，制定出長風聯(lián)盟SOA總統(tǒng)技術架構。目標是作為長風聯(lián)盟企業(yè)實 施SOA架構的電子政務系統(tǒng)的標準型、指導性框架，實現(xiàn)未來電子政務系統(tǒng) 的互聯(lián)互通、資源共享，并使聯(lián)盟企業(yè)可以快速、流暢、高效地構建各類政 務應用系統(tǒng),保障以該架構為標準的各類政務應用通暢運行。該架構將成為未 來電子政務實施的重要指導。該架構乂稱為“五橫三縱架構”。什么是SOA電子政務總體應用架構設計SOA電子政務總體應用架構設計就是把各種知識、技能、手段和技術應 用于架構活動中，以達到系統(tǒng)建設和系統(tǒng)整合的要求

11、。其中:質(zhì)量屬性（按各種角度分類的屬性。譬如：1按生命周期劃分會有設計期，開發(fā)期，運 （行期，測試期，維護期質(zhì)量非功能需求2定量屬性和定性屬性，可用性、可修改性、 性能、安全、有效性、可測試性、可監(jiān)控 性、可追溯性、可升級性、可擴張性、可維 護性、可管理性、可復用性、模塊獨立交付 性等）約束卜面介紹幾個通常會在系統(tǒng)設計中涉及的質(zhì)量屬性。.性能指系統(tǒng)提供的服務要滿足一定的性能衡量標準，這些標準可能包括系統(tǒng) 反應時間以及處理交易量的能力等。通?？梢愿鶕?jù)每個用戶訪問的系統(tǒng)響應時間來衡量系統(tǒng)的整體性能；也 可以通過系統(tǒng)能夠處理的交易量（每秒）來衡量系統(tǒng)的性能。對于架構設計師 來說，無論采取哪種衡量系統(tǒng)

12、性能的方法來構建系統(tǒng)架構，這些對于性能的 考慮對系統(tǒng)設計開發(fā)人員來說都應該是透明的，也就是說對于系統(tǒng)整體架構 性能的考慮應該是架構設計師的工作，而不是系統(tǒng)設計開發(fā)人員應該關注的 事情。在較傳統(tǒng)的基于EJB或者XML-RPC的分布式計算模型中，它們的服務提 供都是通過函數(shù)調(diào)用的方式進行的，一個功能的完成往往需要通過客戶端和 服務器來回很多次的遠程函數(shù)調(diào)用才能完成。在Intranet的環(huán)境下，這些 調(diào)用給系統(tǒng)的響應速度和穩(wěn)定性帶來的影響都可以忽略不計，但如果我們在 基于SOA的架構中使用了很多Web Service來作為服務提供點的話,我們 就需要考慮性能的影響，尤其是在Internet環(huán)境下，這

13、些往往是決定整個 系統(tǒng)是否能正常工作的一個關鍵決定因素。因此在基于SOA的系統(tǒng)中，推 薦采用大數(shù)據(jù)量低頻率訪問模式，也就是以大數(shù)據(jù)量的方式一次性進行信息 交換。這樣做可以在一定程度上提高系統(tǒng)的整體性能。.可升級性指當系統(tǒng)負荷加大時，仍能夠確保所需的服務質(zhì)量，而不需要更改整個 系統(tǒng)的架構。當基于SOA的系統(tǒng)中負荷增大時，如果系統(tǒng)的響應時間仍能夠在可接 受的限度內(nèi)，那么我們就可以認為這個系統(tǒng)是具有可升級性的。要想理解可 升級性，我們必須首先了解系統(tǒng)容量或系統(tǒng)的承受能力，也就是一個系統(tǒng)在 保證正常運行質(zhì)量的同時，所能夠處理的最大進程數(shù)量或所能支持的最大用 戶數(shù)量。如果系統(tǒng)運轉時已經(jīng)不能在可接受時間范

14、圍內(nèi)反應，那么這個系統(tǒng) 已經(jīng)到達了它的最大可升級狀態(tài)。要想升級已達到最大負載能力的系統(tǒng)，你 必須增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升級 包括為現(xiàn)在的機器增加處理器、內(nèi)存或硬盤。水平升級包括在環(huán)境中添置新 的機器，從而增加系統(tǒng)的整體處理能力。作為一個系統(tǒng)架構設計師所設計出 來的架構必須能夠處理對硬件的垂直或者水平升級?；赟OA的系統(tǒng)架構 可以很好地保證整體系統(tǒng)的可升級性，這主要是因為系統(tǒng)中的功能模塊已經(jīng) 被抽象成不同的服務，所有的硬件以及底層平臺的信息都被屏蔽在服務之 下，因此不管是對已有系統(tǒng)的水平升級還是垂直升級，都不會影響到系統(tǒng)整 體的架構。.可靠性指確保各應用及其

15、相關的所有交易的完整性和一致性的能力。當系統(tǒng)負荷增加時，系統(tǒng)必須能夠持續(xù)處理需求訪問，并確保系統(tǒng)能夠 象負荷未增加以前一樣正確地處理各個進程。可靠性可能會在一定程度上限 制系統(tǒng)的可升級性。如果系統(tǒng)負荷增加時，不能維持它的可靠性，那么實際 上這個系統(tǒng)也并不具備可升級性。因此，一個真正可升級的系統(tǒng)必須是可靠 的系統(tǒng)。在基于SOA來構建系統(tǒng)架構的時候，可靠性也是必須要著重考慮 的問題。要在基于SOA架構的系統(tǒng)中保證一定的系統(tǒng)可靠性，就必須要首 先保證分布在系統(tǒng)中的不同服務的可靠性。而不同服務的可靠性一般可以由 其部署的應用服務器或Web服務器來保證。只有確保每一個SOA系統(tǒng)中的 服務都具有較高的可靠

16、性，我們才能保證系統(tǒng)整體的可靠性能夠得以保障。 4.可用性指確保一項服務或者資源應該總是可被訪問到的。可靠性可以增加系統(tǒng)的整體可用性，但即使系統(tǒng)部件出錯，有時卻并不 一定會影響系統(tǒng)的可用性。通過在環(huán)境中設置冗余組件和錯誤恢復機制，雖 然一個單獨的組件的錯誤會對系統(tǒng)的可靠性產(chǎn)生不良的影響，但由于系統(tǒng)冗 余的存在，使得整個系統(tǒng)服務仍然可用。在基于SOA來構建系統(tǒng)架構的時 候，對于關鍵性的服務需要更多地考慮其可用性需求，這可以由兩個層次的 技術實現(xiàn)來支持，第一種是利用不同服務的具體內(nèi)部實現(xiàn)內(nèi)部所基于的框架 的容錯或者冗余機制來實現(xiàn)對服務可用性的支持;第二種是通過UDDI等動態(tài) 查找匹配方式來支持系統(tǒng)

17、整體的高可用性。在SOA架構設計師構建企業(yè)系 統(tǒng)架構的時候，應該綜合考慮這兩個方面的內(nèi)容，盡量保證所構建的SOA系 統(tǒng)架構中的關鍵性業(yè)務能具有較高的可用性。.可擴展性指在不影響現(xiàn)有系統(tǒng)功能的基礎上，為系統(tǒng)添加新的功能或修改現(xiàn)有功 能的能力。當系統(tǒng)剛配置好的時候，你很難衡量它的可擴展性，直到第一次你必須 去擴展系統(tǒng)已有功能的時候，你才能真正去衡量和檢測整個系統(tǒng)的可擴展 性。任何一個架構設計師在構建系統(tǒng)架構時，為了確保架構設計的可擴展性, 都應該考慮下面幾個要素:低耦合，界面(mteifaces)以及封裝。當架構設計師 基于SOA來構建企業(yè)系統(tǒng)架構時，就已經(jīng)隱含地解決了這幾個可擴展性方 面的要素。

18、這是因為SOA架構中的不同服務之間本身就保持了一種無依賴 的低耦合關系;服務本身是通過統(tǒng)一的接口定義(可以是WSDL)語言來描述 具體的服務內(nèi)容，并且很好地封裝了底層的具體實現(xiàn)。.可維護性指在不影響系統(tǒng)其他部分的情況下修改現(xiàn)有系統(tǒng)功能中問題或缺陷的能 力。當系統(tǒng)剛被部署時，你很難判斷一個系統(tǒng)是否已經(jīng)具備了很好的可維護 性。當創(chuàng)建和設計系統(tǒng)架構時，要想提高系統(tǒng)的可維護性，你必須考慮下面 幾個要素:低耦合、模塊性以及系統(tǒng)文檔記錄。在企業(yè)系統(tǒng)可擴展性中我們已 經(jīng)提到了 SOA架構能為系統(tǒng)中暴露出來的各個子功能模塊也就是服務帶 來低耦合性和很好的模塊性。關于系統(tǒng)文檔紀錄，除了底層子系統(tǒng)的相關文 檔外，

19、基于SOA的系統(tǒng)還會引用到許多系統(tǒng)外部的由第三方提供的服務， 因此如果人力資源準許的話，應該增加專職的文檔管理員來專門負責有關整 個企業(yè)系統(tǒng)所涉及的所有外部服務相關文檔的收集、歸類和整理，這些相關 的文檔可能涉及到第三方服務的接口(可以是WSDL)、服務的質(zhì)量和級別、 具體性能測試結果等各種相關文檔?；谶@些文檔，就可以為SOA架構設 計師構建企業(yè)SOA架構提供很好的文檔參考和支持。.可管理性指管理系統(tǒng)以確保整個系統(tǒng)的可升級性、可靠性、可用性、性能和安全 性的能力。具有可管理性的系統(tǒng)，應具備對服務質(zhì)量需求(QoS)的系統(tǒng)監(jiān)控能力，通 過改變系統(tǒng)的配置從而可以動態(tài)地改善服務質(zhì)量，而不用改變整體系

20、統(tǒng)架構。一個好的系統(tǒng)架構必須能夠監(jiān)控整個系統(tǒng)的運行情況并具備動態(tài)系統(tǒng)配 置管理的功能。在對復雜系統(tǒng)進行系統(tǒng)架構建模時，SOA架構設計師應該 盡量考慮利用將系統(tǒng)整體架構構建在已有的成熟的底層系統(tǒng)框架 (Fiamewoik)_t。.安全性指確保系統(tǒng)安全不會被危及的能力。目前，安全性應該說是最困難的系統(tǒng)質(zhì)量控制點。這是因為安全性不僅 要求確保系統(tǒng)的保密和完整性，而且還要防止影響可用性的服務拒絕 (Denial-of-Service)攻擊。這就要求當SOA架構設計師在構建一個架構時， 應該把整體系統(tǒng)架構盡可能地分割成各個子功能模塊，在將一些子功能模塊 暴露為外部用戶可見的服務的時候，要圍繞各個子模塊構

21、建各自的安全區(qū)， 這樣更便于保證整體系統(tǒng)架構的安全。如果一個子模塊受到了安全攻擊，也 可以保證其他模塊相對安全。如果企業(yè)SOA架構中的一些服務是由 WebSemce實現(xiàn)的，在考慮這些服務安全性的時候也要同時考慮效率的問 題，因為WS-Secunty會為Web Seivice帶來一定的執(zhí)行效率損耗。高質(zhì)量的架構設計還考慮了技術風險應對的因素。應對變化，權衡不變與變化是架構設計永恒的主題。架構設計中還必須考慮SOA的獨特性,例如：服務分類方法等。臼按服務在系統(tǒng)建設中的用途劃分：2按服務的功能劃分：服務：數(shù)據(jù)中心的服務和邏輯中心的服務服務：技術網(wǎng)關、適配器、外觀、裝飾服務程為中心的服務企業(yè)服務：為跨

22、企業(yè)集成提供接口，例如SMS、Email等 員外應用程序前端是SOA的激活元素。本指南的章節(jié)組織主要分4章介紹。第1章引論第2章應用架構設計知識領域、設計原則和過程組第3章應用架構分解結構第4章 應用架構設計路線圖應用架構設計的主要內(nèi)容依據(jù)SOA-RA-TF的參考架構，解決電子政務應用領域如何產(chǎn)出一個SOA 應用架構的問題：架構的生命期構成整體架構設計過程組架構分解結構（五橫三縱架構）知識領域:服務參考模型架構側面系（生命周期模型和4+1視圖）應用架構分解結構與參考架構（RA）應用架構分解結構中的基礎支撐層中的系統(tǒng)軟件盡量按照RA標準實現(xiàn)，如 不能滿足，架構上應考慮松耦合的互連互通，保障符合R

23、A標準的服務庫和應用 系統(tǒng)能夠和本應用架構協(xié)同。另外RA為應用架構分解結構中的服務開發(fā)運行體系提供支撐機制，如ESB 等。應用架構設計環(huán)境本指南假定架構設計在項目環(huán)境下進行。應用架構設計受到一定環(huán)境因素的影響和約束，并反過來對這些因素產(chǎn)生影 響：應用領域標準規(guī)范組織過程資產(chǎn)公司戰(zhàn)略要求技術環(huán)境項目要求管理因素架構設計和項目管理和組織日常運作管理是密切相關的，但本指南不涉及相 關內(nèi)容，請參考相關書籍和文獻資料。應用架構設計干系人架構設計要考慮架構設計干系人的要求。高層管理人員項目發(fā)起人項目經(jīng)理架構設計師需求人員開發(fā)人員測試人員客戶1.10應用架構設計指南與長風聯(lián)盟其他文檔的關系第二章應用架構設計

24、知識領域、原則 和過程組應用架構設計知識領域SOA設計方法學SOA設計方法并非全新的方法論，而是繼承了傳統(tǒng)的面向?qū)ο蟮脑O計方法 以及面向過程的設計方法，同時乂增加了 SCA, SDO, BPEL等技術，融入了 面向服務的設計方法，服務參考模型OASIS RM里的內(nèi)容映射，具體內(nèi)容包括 服務定義、服務設計、服務管理、服務開發(fā)、服務測試和服務部署。數(shù)據(jù)建模方法學傳統(tǒng)的數(shù)據(jù)建模方法學是面向一個應用系統(tǒng)內(nèi)部的實體的建模方法學，而在 當前數(shù)據(jù)整合、應用整合的需求下，數(shù)據(jù)建模還要考慮在不同系統(tǒng)間進行數(shù)據(jù)交 換和數(shù)據(jù)共享的需求?；跇I(yè)務效率的考慮，從業(yè)務流程出發(fā)的思路改變了數(shù)據(jù)模型。只有你從業(yè)務流程的角度來

25、看待數(shù)據(jù)的時候，數(shù)據(jù)模型才能算真正完成。面向流程設計方法學闡述了一種以實現(xiàn)流程優(yōu)化的流程系統(tǒng)設計思想。這種設計思想是面向業(yè)務 流程的，不同于傳統(tǒng)MIS系統(tǒng)面向部門職能的設計思想。首先把系統(tǒng)設計區(qū)分 為原理層設計和技術層設計兩個層次，然后從業(yè)務流程設計、數(shù)據(jù)模型設計和技 術架構設計三個方面論述了原理層設計的基本思想。技術領域架構設計方法學大型IT系統(tǒng)的設計通常遵循七層架構的設計方法，包括：界面層該層是直接面向用戶（包括公眾、企業(yè)、業(yè)務人員、行政管理人員、領導 等使用者）的統(tǒng)一的系統(tǒng)界面。界面層利用業(yè)界主流的IT技術支持多種渠道接 入和交互（如互聯(lián)網(wǎng)、電話、手機短信等接入方式），以及統(tǒng)一的身份認證

26、及權 限管理。應用層應用層提供所有的信息應用和系統(tǒng)管理的業(yè)務邏輯，分解業(yè)務請求，通過 應用支撐層進行數(shù)據(jù)處理，并將返回信息組織成所需的格式提供給客戶端。應 用系統(tǒng)分為四大部分： 面向公眾和企業(yè)的外網(wǎng)應用一一審批門戶（網(wǎng)上審批系統(tǒng)前臺），提供 網(wǎng)上申報和反饋查詢等在線服務功能；面向公務員的審批服務平臺，實現(xiàn)業(yè)務審批、監(jiān)督檢察、業(yè)務調(diào)度、決 策支持等功能；面向公務員的政府資源共享平臺（數(shù)據(jù)共享與交換平臺），實現(xiàn)基于審 批業(yè)務的數(shù)據(jù)交換與基于委辦局現(xiàn)有信息資源的數(shù)據(jù)共享使用等功能。面向公務員的開放辦公平臺，實現(xiàn)基于開放的桌面辦公系統(tǒng)，實現(xiàn)對審 批過程數(shù)據(jù)的保存及歸檔等。應用支撐層應用支撐層構建在J2

27、EE應用服務器之上，提供了一個應用基礎平臺DC-BPIP,并提供大量公共服務和業(yè)務構件，提供構件的運行、開發(fā)和管理環(huán)境, 最大限度提高開發(fā)效率，降低工程實施、維護的成本和風險。應用支撐層采用了 行業(yè)應用的先進體系結構，以建立高性能、高可靠性、高擴展性的應用系統(tǒng)，滿 足客戶快速發(fā)展的業(yè)務需求。信息資源層信息資源層是整個系統(tǒng)的信息資源中心，涵蓋全市所有與行政審批相關的 結構化和非結構化數(shù)據(jù)。它是企業(yè)信息資源的存儲和積累，為系統(tǒng)應用提供數(shù) 據(jù)訪問服務、備份、存儲功能。IT基礎平臺層IT基礎平臺為系統(tǒng)的軟硬件以及網(wǎng)絡基礎平臺，分為三個部分：系統(tǒng)軟件、 硬件支撐平臺、和網(wǎng)絡支撐平臺。其中，系統(tǒng)軟件包括中

28、間件、數(shù)據(jù)庫服務器軟 件等；硬件支撐平臺包括：主機、存儲、備份等硬件設備；網(wǎng)絡支撐為系統(tǒng)運行 所依賴的網(wǎng)絡環(huán)境。它對上層應用起到技術支撐作用 支撐體系層系統(tǒng)建設和推廣運行僅僅依賴應用系統(tǒng)建設、硬件網(wǎng)絡建設是不夠的，需要 在系統(tǒng)安全方面、標準化方面、以及系統(tǒng)運維三個不同層面的工作來共同支撐。 只有這樣，才能使系統(tǒng)建設順利進行，也才能保證系統(tǒng)能順利推廣、穩(wěn)定運行。 法律法規(guī)層以上各個層面的建設，需要依托于現(xiàn)有的法律、法規(guī)及一些規(guī)范才可成功運 行。系統(tǒng)的分析、設計、實施都必須充分考慮這些因素。只有切實符合這些規(guī)范, 系統(tǒng)才能與建設單位共同發(fā)展，得到各級用戶的認可。而利用RUP的設計思想，則將架構設計

29、概括為4+1視圖：邏輯視圖邏輯視圖關注功能，不僅包括用戶可見的功能，還包括為實現(xiàn)用 戶功能而必須提供的”輔助功能模塊”；它們可能是邏輯層、功能模塊等。 開發(fā)視圖。開發(fā)視圖關注程序包，不僅包括要編寫的源程序，還包括可以直 接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于其上的 系統(tǒng)軟件或中間件。開發(fā)視圖和邏輯視圖之間可能存在一定的映射關系：比 如邏輯層一般會映射到多個程序包等。處理視圖。處理視圖關注進程、線程、對象等運行時概念，以及相關的并發(fā)、 同步、通信等問題。處理視圖和開發(fā)視圖的關系：開發(fā)視圖一般偏重程序包 在編譯時期的靜態(tài)依賴關系，而這些程序運行起來之后會表現(xiàn)為對象、線程、 進

30、程，處理視圖比較關注的正是這些運行時單元的交互問題。物理視圖。物理視圖關注”目標程序及其依賴的運行庫和系統(tǒng)軟件”最終如何 安裝或部署到物理機器，以及如何部署機器和網(wǎng)絡來配合軟件系統(tǒng)的可靠 性、可伸縮性等要求。物理視圖和處理視圖的關系：處理視圖特別關注目標 程序的動態(tài)執(zhí)行情況，而物理視圖重視目標程序的靜態(tài)位置問題；物理視圖 是綜合考慮軟件系統(tǒng)和整個IT系統(tǒng)相互影響的架構視圖。場景視圖。關注業(yè)務的應用場景。通用架構設計方法學架構設計是一種權衡(ade-off)。一個問題總是有多種的解決方案。而 我們要確定唯一的架構設計的解決方案，就意味著我們要在不同的矛盾體之 間做出一個權衡。我們在設計的過程總是

31、可以看到很多的矛盾體：開放和整 合，一致性和特殊化，穩(wěn)定性和延展性等等。任何一對矛盾體都源于我們對 軟件的不同期望?？墒?，要滿足我們希望軟件穩(wěn)定運行的要求，就必然會影 響我們對軟件易于擴展的期望。我們希望軟件簡單明了，卻增加了我們設計 的復雜度。沒有一個軟件能夠滿足所有的要求，因為這些要求之間帶有天生 的互斥性。而我們評價架構設計的好壞的依據(jù)，就只能是根據(jù)不同要求的輕 重緩急，在其間做出權衡的合理性。目標我們希望一個好的架構能夠：重用：為了避免重復勞動，為了降低成本，我們希望能夠重用之前的代碼、 之前的設計。重用是我們不斷追求的目標之一，但事實上，做到這一點可沒有那 么容易。在現(xiàn)實中，人們已經(jīng)

32、在架構重用上做了很多的工作，工作的成果稱為框 架(Frame work),比如說Windows的窗口機制、J2EE平臺等。但是在企業(yè)商業(yè) 建模方面，有效的框架還非常的少。透明：有些時候，我們?yōu)榱颂岣咝?，把實現(xiàn)的細節(jié)隱藏起來，僅把客戶需 求的接口呈現(xiàn)給客戶。這樣，具體的實現(xiàn)對客戶來說就是透明的。一個具體的例 子是我們使用JSP的tag技術來代替JSP的嵌入代碼，因為我們的HTML界面人 員更熟悉tag的方式。延展：我們對延展的渴求源于需求的易變。因此我們需要架構具有一定的延 展性，以適應未來可能的變化?？墒?，如上所說，延展性和穩(wěn)定性，延展性和簡 單性都是矛盾的。因此我們需要權衡我們的投入/產(chǎn)出

33、比。以設計出具有適當和 延展性的架構。簡明：一個復雜的架構不論是測試還是維護都是困難的。我們希望架構能夠 在滿足目的的情況下盡可能的簡單明了。但是簡單明了的含義究竟是什么好像并 沒有一個明確的定義。使用模式能夠使設計變得簡單，但這是建立在我熟悉設計 模式的基礎上。對于一個并不懂設計模式的人，他會認為這個架構很復雜。對于 這種情況，我只能對他說，去看看設計模式。高效：不論是什么系統(tǒng)，我們都希望架構是高效的。這一點對于一些特定的 系統(tǒng)來說尤其重要。例如實時系統(tǒng)、高訪問量的網(wǎng)站。這些值的是技術上的高效, 有時候我們指的高效是效益上的高效。例如，一個只有幾十到一百訪問量的信息 系統(tǒng)，是不是有必要使用E

34、JB技術，這就需要我們綜合的評估效益了。安全：安全并不是我們文章討論的重點，卻是架構的一個很重要的方面。 規(guī)則為了達到上述的目的，我們通常需要對架構設計制定一些簡單的規(guī)則：功能分解顧名思義，就是把功能分解開來。為什么呢？我們之所以很難達到重用目標 就是因為我們編寫的程序經(jīng)常處于一種好像是重復的功能，但乂有輕微差別的狀 態(tài)中。我們很多時候就會經(jīng)不住誘惑，用拷貝粘貼再做少量修改的方式完成一個 功能。這種行為在XP中是堅決不被允許的。XP提倡“Onceandonlyonce”，目的 就是為了杜絕這種拷貝修改的現(xiàn)象。為了做到這一點，我們通常要把功能分解到 細粒度。很多的設計思想都提倡小類，為的就是這個

35、目的。所以，我們的程序中的類和方法的數(shù)目就會大大增長，而每個類和方法的平 均代碼卻會大大的下降?？墒牵覀冊趺粗肋@個度應該要如何把握呢，關于這 個疑問，并沒有明確的答案，要看個人的功力和具體的要求，但是一般來說，我 們可以用一個簡單的動詞短語來命名類或方法的，那就會是比較好的分類方法。我們使用功能分解的規(guī)則，有助于提高重用性，因為我們每個類和方法的精 度都提高了。這是符合大自然的原則的，我們研究自然的主要的一個方向就是將 物質(zhì)分解。我們的思路同樣可以應用在軟件開發(fā)上。除了重用性，功能分解還能 實現(xiàn)透明的目標，因為我們使用了功能分解的規(guī)則之后，每個類都有自己的單獨 功能，這樣，我們對一個類的研

36、究就可以集中在這個類本身，而不用牽涉到過多 的類。根據(jù)實際情況決定不同類間的耦合度雖然我們總是希望類間的耦合度比較低，但是我們必須客觀的評價耦合度。 系統(tǒng)之間不可能總是松耦合的，那樣肯定什么也做不了。而我們決定耦合的程度 的依據(jù)何在呢？簡單的說，就是根據(jù)需求的穩(wěn)定性，來決定耦合的程度。對于穩(wěn) 定性高的需求，不容易發(fā)生變化的需求，我們完全可以把各類設計成緊耦合的（我 們雖然討論類之間的耦合度，但其實功能塊、模塊、包之間的耦合度也是一樣的）, 因為這樣可以提高效率，而且我們還可以使用一些更好的技術來提高效率或簡化 代碼，例如Java中的內(nèi)部類技術?？墒?，如果需求極有可能變化，我們就需要 充分的考慮

37、類之間的耦合問題，我們可以想出各種各樣的辦法來降低耦合程度， 但是歸納起來，不外乎增加抽象的層次來隔離不同的類，這個抽象層次可以是具 體的類，也可以是接口，或是一組的類（例如Beans）。我們可以借用Java中的 一句話來概括降低耦合度的思想：”針對接口編程，而不是針對實現(xiàn)編程。設計不同的耦合度有利于實現(xiàn)透明和延展。對于類的客戶（調(diào)用者）來說， 他不需要知道過多的細節(jié)（實現(xiàn)），他只關心他感興趣的（接口）。這樣，目標類 對客戶來說就是一個黑盒子。如果接口是穩(wěn)定的，那么，實現(xiàn)再怎么擴展，對客 戶來說也不會有很大的影響。以前那種牽一發(fā)而動全身的問題完全可以緩解共至 避免。其實，我們仔細的觀察GOF的

38、23種設計模式，沒有一種模式的思路不是從 增加抽象層次入手來解決問題的。同樣，我們?nèi)ビ^察Java源碼的時候，我們也 可以發(fā)現(xiàn)，Java源碼中存在著大量的抽象層次，初看之下，它們什么都不干，但 是它們對系統(tǒng)的設計起著重大的作用。夠用就好我們在上一章中就談過敏捷方法很看重剛好夠用的問題，現(xiàn)在我們結合架構 設計來看：在同樣都能夠滿足需要的情況下，一項復雜的設計和一項簡單的設計, 哪一個更好。從敏捷的觀點來看，一定是后者。因為目前的需求只有10項，而 你的設計能夠滿足100項的需求，只能說這是種浪費。你在設計時完全沒有考慮 成本問題，不考慮成本問題，你就是對開發(fā)組織的不負責，對客戶的不負責。應用模式這

39、篇文章的寫作思路很多來源于對模式的研究。因此，文章中到處都可以看 到模式思想的影子。模式是一種整理、傳播思想的非常優(yōu)秀的途徑，我們可以通 過模式的方式學習他人的經(jīng)驗。一個好的模式代表了某個問題研究的成果，因此 我們把模式應用在架構設計上，能夠大大增強架構的穩(wěn)定性。抽象架構的本質(zhì)在于其抽象性。它包括兩個方面的抽象：業(yè)務抽象和技術抽象。 架構是現(xiàn)實世界的一個模型，所以我們首先需要對現(xiàn)實世界有一個很深的了解， 然后我們還要能夠熟練的應用技術來實現(xiàn)現(xiàn)實世界到模型的映射。因此，我們在 對業(yè)務或技術理解不夠深入的情況下，就很難設計出好的架構。當然，這時候我 們發(fā)現(xiàn)一個問題：怎樣才能算是理解足夠深入呢。我認

40、為這沒有一個絕對的準則。一次，一位朋友問我：他現(xiàn)在做的系統(tǒng)有很大的變化，原先設計的工作流架 構不能滿足現(xiàn)在的要求。他很希望能夠設計出足夠好的工作流架構，以適應不同 的變化。但是他發(fā)現(xiàn)這樣做無異于重新開發(fā)一個lotusnotes。我聽了他的疑問之 后覺得有兩點問題：首先，他的開發(fā)團隊中并沒有工作流領域的專家。他的客戶雖然了解自己的 工作流程，但是缺乏足夠的理論知識把工作流提到抽象的地步。顯然，他本身雖 然有技術方面的才能，但就工作流業(yè)務本身，他也沒有足夠的經(jīng)驗。所以，設計 出象notes那樣的系統(tǒng)的前提條件并不存在。其次，開發(fā)一個工作流系統(tǒng)的目的是什么。原先的工作流系統(tǒng)運作的不好， 其原因是有變

41、化發(fā)生。因此才有改進工作流系統(tǒng)的動機出現(xiàn)?？墒牵吘筺otes 是為了滿足世界上所有的工作流系統(tǒng)而開發(fā)的，他目前的應用肯定達不到這個層 次。因此，雖然做不到最優(yōu)的業(yè)務抽象，但是我們完全可以在特定目的下，特定 范圍內(nèi)做到最優(yōu)的業(yè)務抽象。比如說，我們工作流可能的變化是工組流路徑的變 化。我們就完全可以把工作流的路徑做一個抽象，設計一個可以動態(tài)改變路徑的 工作流架構。有些時候，我們雖然在技術上和業(yè)務上都有所欠缺，沒有辦法設計出好的架 構。但是我們完全可以借鑒他人的經(jīng)驗，看看類似的問題別人是如何解決的。這 就是我們前面提到的模式。我們不要把模式看成是一個硬性的解決方法，它只是 一種解決問題的思路。Ma

42、rtinFowlei-曾說：“模式和業(yè)務組件的區(qū)別就在于模式 會引發(fā)你的思考。”在分析模式一書中，MaihnFowle提到了分析和設計的區(qū)別。分析并不 僅僅只是用用例列出所有的需求，分析還應該深入到表面需求的的背后，以得到 關于問題本質(zhì)的MentalModel。然后，他引出了概念模型的概念。概念模型就類 似于我們在討論的抽象。MartinFowle提到了一個有趣的例子，如果要開發(fā)一套 軟件來模擬桌球游戲，那么，用用例來描述各種的需求，可能會導致大量的運動 軌跡的出現(xiàn)。如果你沒有了解表面現(xiàn)象之后隱藏的運動定律的本質(zhì)，你可能永遠 無法開發(fā)出這樣一個系統(tǒng)。關于架構和抽象的問題，在后面的文章中有一個測

43、量模式的案例可以很形象 的說明這個問題。架構的一些誤解我們花了一些篇幅來介紹架構的一些知識?，F(xiàn)在回到我們的另一個主題上 來。對于一個敏捷開發(fā)過程，架構意味著什么，我們該如何面對架構。這里我們 首先要澄清一些誤解：誤解L架構設計需要很強的技術能力。從某種程度來說，這句話并沒有很 大的錯誤。畢竟，你的能力越強，設計出優(yōu)秀架構的幾率也會上升。但是能力和 架構設計之間并沒有一個很強的聯(lián)系。即使是普通的編程人員，他一樣有能力設 計出能實現(xiàn)目標的架構。誤解2：架構由專門的設計師來設計，設計出的藍圖交由程序員來實現(xiàn)。我 們之所以會認為架構是設計師的工作，是因為我們喜歡把軟件開發(fā)和建筑工程做 類比。但是，這兩

44、者實際上是有著很大的區(qū)別的。關鍵之處在于，建筑設計已經(jīng) 有很長的歷史，已經(jīng)發(fā)展出完善的理論，可以通過某些理論（如力學原理）來驗 證設計藍圖?？墒?，對軟件開發(fā)而言，驗證架構設計的正確性，只能夠通過寫代 碼來驗證。因此，很多看似完美的架構，往往在實現(xiàn)時會出現(xiàn)問題。誤解3：在一開始就要設計出完善的架構。這種方式是最傳統(tǒng)的前期設計方 式。這也是為XP所摒棄的一種設計方式。主要的原因是，在一開始設計出完美 的架構根本就是在自欺欺人。因為這樣做的基本假設就是需求的不變性。但需求 是沒有不變的（關于需求的細節(jié)討論，請參看拙作需求的實踐）。這樣做的壞 處是，我們一開始就限制了整個的軟件的形狀。而到實現(xiàn)時，我們

45、雖然發(fā)現(xiàn)原來 的設計有失誤之處，但卻不愿意面對現(xiàn)實。這使得軟件畸形的生長。原本一些簡 單的問題，卻因為別扭的架構，變得非常的復雜。這種例子我們經(jīng)?？梢钥吹?， 例如為兼容前個版本而導致的軟件復雜性。而2000年問題，TCP/IP網(wǎng)絡的安全 性問題也從一個側面反映了這個問題的嚴重性。誤解4：架構藍圖交給程序員之后，架構設計師的任務就完成了。和誤解2 一樣，我們借鑒了建筑工程的經(jīng)驗。我們看到建筑設計師把設計好的藍圖交給施 工人員，施工人員就會按照圖紙建造出和圖紙一模一樣的大廈。于是，我們也企 圖在軟件開發(fā)中使用這種模式。這是非常要命的。軟件開發(fā)中缺乏一種通用的語 言，能夠充分的消除設計師和程序員的溝

46、通隔閡。有人說，UML不可以嗎？ UML 的設計理念是好的，可以減輕溝通障礙問題?？墒且胪耆鉀Q這個問題，UML 還做不到。首先，程序員都具有個性化的思維，他會以自己的思維方式去理解設 計，因為從設計到實現(xiàn)并不是一項機械的勞動，還是屬于一項知識性的勞動（這 和施工人員的工作是不同的）。此外，對于程序員來說，他還極有可能按照自己 的想法對設計圖進行一定的修改，這是非常正常的一項舉動。更糟的是，程序員 往往都比較自負，他們會潛意識的排斥那些未經(jīng)過自己認同的設計。架構設計的過程模式通常我們認為模式都是用在軟件開發(fā)、架構設計上的。其實，這只是模式的 一個方面。模式的定義告訴我們，模式描述了一個特定環(huán)

47、境的解決方法，這個特 定環(huán)境往往重復出現(xiàn)，制定出一個較好的解決方法有利于我們在未來能有效的解 決類似的問題。其實，在管理學上，也存在這種類似的這種思維。稱為結構性問 題的程序化解決方法。所以呢，我們完全可以把模式的思想用在其它的方面，而 目前最佳的運用就是過程模式和組織模式。在我們的文章中，我們僅限于討論過 程模式。我們討論的過程僅限于面向?qū)ο蟮能浖_發(fā)過程。我們稱之為OOSP (object-onentedsoftwarepiocess)。因為我們的過程需要面向?qū)ο筇匦缘闹С?。?然，我們的很多做法一樣可以用在非OO的開發(fā)過程中，但是為了達到最佳的效 果，我建議您使用OO技術。面向?qū)ο笤O計方

48、法學面向?qū)ο蠓椒?Obj ect-Onented Method)是一種把面向?qū)ο蟮乃枷霊糜?軟件開發(fā)過程中，指導開發(fā)活動的系統(tǒng)方法，簡稱OO(Object-O口ented)方法, 是建立在“對象”概念基礎上的方法學。對象是由數(shù)據(jù)和容許的操作組成的 封裝體，與客觀實體有直接對應關系，一個對象類定義了具有相似性質(zhì)的一 組對象。而每繼承性是對具有層次關系的類的屬性和操作進行共享的一種方 式。所謂面向?qū)ο缶褪腔趯ο蟾拍?，以對象為中心，以類和繼承為構造機 制，來認識、理解、刻畫客觀世界和設計、構建相應的軟件系統(tǒng)。面向?qū)ο蠓椒ㄗ鳛橐环N新型的獨具優(yōu)越性的新方法正引起全世界越來 越廣泛的關注和高度的重視，

49、它被譽為”研究高技術的好方法”，更是當前計 算機界關心的重點。十多年來，在對OO方法如火如荼的研究熱潮中，許多 專家和學者預言：正像70年代結構化方法對計算機技術應用所產(chǎn)生的巨大 影響和促進那樣，90年代OO方法會強烈地影響、推動和促進一系列高技術 的發(fā)展和多學科的綜合。用計算機解決問題需要用程序設計語言對問題求解加以描述(即編程), 實質(zhì)上，軟件是問題求解的一種表述形式。顯然，假如軟件能直接表現(xiàn)人求 解問題的思維路徑(即求解問題的方法)，那么軟件不僅容易被人理解，而 且易于維護和修改，從而會保證軟件的可靠性和可維護性，并能提高公共問 題域中的軟件模塊和模塊重用的可靠性。面向?qū)ο蟮臋C能念和機制

50、恰好可以 使得按照人們通常的思維方式來建立問題域的模型，設計出盡可能自然地表 現(xiàn)求解方法的軟件。面向?qū)ο蟮幕靖拍睿簩ο螅簩ο笫且芯康娜魏问挛?。從一本書到一家圖書館，單的整數(shù)到 整數(shù)列龐大的數(shù)據(jù)庫、極其復雜的自動化工廠、航天飛機都可看作對象，它 不僅能表示有形的實體，也能表示無形的（抽象的）規(guī)則、計劃或事件。對 象由數(shù)據(jù)（描述事物的屬性）和作用于數(shù)據(jù)的操作（體現(xiàn)事物的行為）構成 一獨立整體。從程序設計者來看，對象是一個程序模塊，從用戶來看，對象 為他們提供所希望的行為。在對內(nèi)的操作通常稱為方法。類：類是對象的模板。即類是對一組有相同數(shù)據(jù)和相同操作的對象的定 義，一個類所包含的方法和數(shù)據(jù)描述一

51、組對象的共同屬性和行為。類是在對 象之上的抽象，對象則是類的具體化，是類的實例。類可有其子類，也可有 其它類，形成類層次結構。消息：消息是對象之間進行通信的一種規(guī)格說明。一般它由三部分組成: 接收消息的對象、消息名及實際變元。面向?qū)ο笾饕卣鳎悍庋b性：封裝是一種信息隱蔽技術，它體現(xiàn)于類的說明，是對象的重要 特性。封裝使數(shù)據(jù)和加工該數(shù)據(jù)的方法（函數(shù)）封裝為一個整體，以實現(xiàn)獨 立性很強的模塊，使得用戶只能見到對象的外特性（對象能接受哪些消息， 具有那些處理能力），而對象的內(nèi)特性（保存內(nèi)部狀態(tài)的私有數(shù)據(jù)和實現(xiàn)加 工能力的算法）對用戶是隱蔽的。封裝的目的在于把對象的設計者和對象者 的使用分開，使用者不

52、必知曉行為實現(xiàn)的細節(jié)，只須用設計者提供的消息來 訪問該對象。繼承性：繼承性是子類自動共享父類之間數(shù)據(jù)和方法的機制。它由類的 派生功能體現(xiàn)。一個類直接繼職其它類的全部描述，同時可修改和擴充。繼職具有傳達室遞性。繼職分為單繼承（一個子類只有一父類）和多重 繼承（一個類有多個父類）。類的對象是各自封閉的，如果沒繼承性機制， 則類對象中數(shù)據(jù)、方法就會出現(xiàn)大量重復。繼承不僅支持系統(tǒng)的可重用性， 而且還促進系統(tǒng)的可擴充性。多態(tài)性：對象根據(jù)所接收的消息而做出動作。同一消息為不同的對象接 受時可產(chǎn)生完全不同的行動，這種現(xiàn)象稱為多態(tài)性。利用多態(tài)性用戶可發(fā)送 一個通用的信息，而將所有的實現(xiàn)細節(jié)都留給接受消息的對象

53、自行決定，如 是，同一消息即可調(diào)用不同的方法。例如：Punt消息被發(fā)送給一圖或表時調(diào) 用的打印方法與將同樣的Print消息發(fā)送給一正文文件而調(diào)用的打印方法會 完全不同。多態(tài)性的實現(xiàn)受到繼承性的支持，利用類繼承的層次關系，把具 有通用功能的協(xié)議存放在類層次中盡可能高的地方，而將實現(xiàn)這一功能的不 同方法置于較低層次，這樣，在這些低層次上生成的對象就能給通用消息以 不同的響應。在OOPL中可通過在派生類中重定義基類函數(shù)（定義為重載函 數(shù)或虛函數(shù)）來實現(xiàn)多態(tài)性。綜上可知，在OO方法中，對象和傳遞消息分別表現(xiàn)事物及事物間相互 聯(lián)系的概念。類和繼承是是適應人們一般思維方式的描述范式。方法是允許 作用于該類

54、對象上的各種操作。這種對象、類、消息和方法的程序設計范式 的基本點在于對象的封裝性和類的繼承性。通過封裝能將對象的定義和對象 的實現(xiàn)分開，通過繼承能體現(xiàn)類與類之間的關系，以及由此帶來的動態(tài)聯(lián)編 和實體的多態(tài)性，從而構成了面向?qū)ο蟮幕咎卣?。服務設計原則顯式定義邊界通過跨越定義明確的邊界進行顯式消息傳遞，服務得以彼此交互。有時 候，跨越服務邊界可能要耗費很大的成本，這要視地理、信任或執(zhí)行因素而 定。邊界是指服務的公共接口與其內(nèi)部專用實現(xiàn)之間的界線。服務的邊界通 過WSDL發(fā)布，可能包括說明特定服務之期望的聲明。跨越邊界的代價是 高吊的因為：目標服務的物理位置可能是未知的因素。安全和信任模型可能會

55、在每次跨越邊界時發(fā)生改變。在服務的公共表示和專用表示之間封送和轉換數(shù)據(jù)可能需要依賴額外 的資源：其中一些資源可能在服務之外。服務的構建要考量持久性，而服務配置的構建則要考量變化性。這一事 實暗示著：由于網(wǎng)絡重新配置或者遷移到另一個物理位置，可靠的服務的性 能可能會突然降低。服務的使用者通常不知道專用的內(nèi)部過程是如何實現(xiàn)的。特定服務的使用者對正使用的服務的性能只能進行有限的控制。服務調(diào)用可能會受到網(wǎng)絡滯后、網(wǎng)絡故障和分布式系統(tǒng)故障的影響，而 本地實現(xiàn)則不會。要預先考慮使用遠程對象接口的影響，就必須編寫大量的 錯誤檢測和更正邏輯。盡管跨越邊界是代價高昂的過程，但在部署用于將此 類邊界跨越減至最少的

56、本地方法時，還是要格外謹慎。實現(xiàn)單一性本地方法 和對象的系統(tǒng)可能會獲得性能的改善，但功能性卻與先前定義的服務完全一 樣。弄清邊界。服務提供一個契約來定義其提供的公共接口。與服務的 所有交互都通過公共接口進行。接口由公共進程和公共數(shù)據(jù)表示組成。公共 進程是通向服務內(nèi)部的入口點，而公共數(shù)據(jù)表示則是指該進程使用的消息。 如果我們使用WSDL代表一個簡單的契約，則message代表公共數(shù)據(jù), 而vportType代表公共進程。文章”外部數(shù)據(jù)與內(nèi)部數(shù)據(jù)”（英文）更詳細 地研究了這些問題。服務應易于使用。設計服務時，開發(fā)人員應使其易于其他開發(fā)人員 使用。設計的服務接口（契約）也應允許服務在不中斷與現(xiàn)有使用

57、者之間的 契約的情況下進一步發(fā)展。（這一主題將在本系列的后續(xù)文章中更詳細地討 論。）避免使用RPC接口。應采用顯式消息傳遞，而避免使用RPC之類 的模型。這種方法將使用者與服務實現(xiàn)的內(nèi)部隔離開來，使開發(fā)人員可以集 中精力改進他們的服務，同時將對服務使用者的影響降至最低（使用公共消 息而不是公用的方法進行封裝）。盡量減小服務的表面積。服務的公共接口越多，就越難以使用和維 護。應當少提供服務的定義明確的公共接口。這些接口應該相對簡單，主要 用于接受定義明確的輸入消息并以同樣定義明確的輸出消息進行響應。這些 接口一旦定義，即應保持不變。這些接口提供服務必須支持的“恒定不變” 的設計要求，為服務專用的

58、內(nèi)部實現(xiàn)充當門面。內(nèi)部（專用）實現(xiàn)的細節(jié)不應泄露到服務邊界之外。如果將實現(xiàn)細 節(jié)泄露到服務邊界，很可能會使服務與服務使用者之間的耦合更加緊密。服 務使用者不應當獲知服務實現(xiàn)的內(nèi)部情況，因為這樣會使服務的版本更新或 升級受到限制。2.2.2自治性服務是獨立進行部署、版本控制和管理的實體。開發(fā)人員應避免對服務 邊界之間的空間進行假設，因為此空間比邊界本身更容易改變。例如，服務 邊界應當是不變的，只有這樣才能將版本更新對使用者的影響降至最低。雖 然服務邊界是相當穩(wěn)定的，但策略、物理位置或網(wǎng)絡拓撲等服務部署選項卻 很可能發(fā)生改變。服務可以通過URI動態(tài)尋址，使其底層位置和部署拓撲可以在幾乎不 影響服務

59、本身的情況下改變或演化（服務的通信通道也是如此）。盡管這些 更改對服務沒什么影響，但它們對使用服務的應用程序卻有著破壞性的影 響。如果您今天使用的服務明天被移動到新西蘭，將會怎樣呢？響應時間的 改變可能會對服務的使用者造成計劃之外或意料之外的影響。服務設計者對 于服務的使用方式應當采取謹慎的態(tài)度：服務將失敗，其相關的行為（服務 級別）可能會被更改。適當級別的例外處理和補償邏輯必須與任何服務調(diào)用 相關聯(lián)。此外，服務使用者可能需要修改其策略，以聲明要使用的最短服務 響應時間。例如，服務使用者可以對安全、性能、事務及許多其他因素請求 不同的服務級別?？膳渲玫牟呗栽试S單個服務支持多個有關服務調(diào)用的 S

60、LA （而其他策略可能主要關注版本更新、本地化及其他問題）。服務級的 通信性能期望始終是自治，因為服務彼此之間不需要熟悉對方的內(nèi)部實現(xiàn)。不止是服務使用者應該對性能采取謹慎的態(tài)度：服務提供者在預測其服 務的使用方式時也應同樣謹慎。應該預料到服務使用者有時候會失敗，卻乂 不通知服務本身。服務提供者也不能信任使用者總是“為所應為”。例如，使 用者可能會嘗試使用不正常的/惡意的消息進行通信，或者嘗試違反成功實現(xiàn) 服務交互所必需的其他策略。無論用戶意圖如何，服務內(nèi)部都必須嘗試對此 類不恰當?shù)氖褂眠M行補償。雖然服務是自治的，但任何服務都不是孤島。基于SOA的解決方案是 不規(guī)則的，由許多為特定解決方案配置的