架構(gòu)電子政務(wù)總體應(yīng)用架構(gòu)設(shè)計指引

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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