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

長風(fēng)開放標(biāo)準(zhǔn)平臺(tái)軟件聯(lián)盟ChangFengOpenStandardsPlatformSoftwareAlliancePAGE -PAGE142-長風(fēng)聯(lián)盟SOA-AP-TF-PAGEi-長風(fēng)聯(lián)盟電子政務(wù)總體應(yīng)用架構(gòu)設(shè)計(jì)指南研究報(bào)告長風(fēng)開放標(biāo)準(zhǔn)平臺(tái)軟件聯(lián)盟二○○七年五月目錄TOC\o"1-4"\h\z\u第一章引論 11.1本指南的目的 11.2本指南依據(jù)的長風(fēng)聯(lián)盟參考文檔 11.3什么是SOA電子政務(wù)總體應(yīng)用架構(gòu) 11.4什么是SOA電子政務(wù)總體應(yīng)用架構(gòu)設(shè)計(jì) 21.5本指南的章節(jié)組織 71.6應(yīng)用架構(gòu)設(shè)計(jì)的主要內(nèi)容 71.7應(yīng)用架構(gòu)分解結(jié)構(gòu)與參考架構(gòu)(RA) 71.8應(yīng)用架構(gòu)設(shè)計(jì)環(huán)境 81.9應(yīng)用架構(gòu)設(shè)計(jì)干系人 81.10應(yīng)用架構(gòu)設(shè)計(jì)指南與長風(fēng)聯(lián)盟其他文檔的關(guān)系 9第二章應(yīng)用架構(gòu)設(shè)計(jì)知識(shí)領(lǐng)域、原則和過程組 102.1應(yīng)用架構(gòu)設(shè)計(jì)知識(shí)領(lǐng)域 102.1.1SOA設(shè)計(jì)方法學(xué) 102.1.2數(shù)據(jù)建模方法學(xué) 102.1.3面向流程設(shè)計(jì)方法學(xué) 112.1.4技術(shù)領(lǐng)域架構(gòu)設(shè)計(jì)方法學(xué) 112.1.5通用架構(gòu)設(shè)計(jì)方法學(xué) 132.1.6面向?qū)ο笤O(shè)計(jì)方法學(xué) 192.2服務(wù)設(shè)計(jì)原則 212.2.1顯式定義邊界 212.2.2自治性 232.2.3服務(wù)共享大綱和契約，但不共享類 242.2.4服務(wù)兼容性基于策略 252.2.5訪問的開放性 262.2.6隨時(shí)可用 272.2.7粗粒度服務(wù)接口 272.2.8服務(wù)分級(jí) 282.2.9松散耦合 282.2.10可重用的服務(wù)及服務(wù)接口設(shè)計(jì)管理 292.2.11標(biāo)準(zhǔn)化的接口 302.2.12支持各種消息模式 302.2.13精確定義服務(wù)接口 312.3應(yīng)用架構(gòu)設(shè)計(jì)過程組 312.3.1架構(gòu)啟動(dòng)過程組 33概述 33業(yè)務(wù)模型合理性初步分析 34架構(gòu)范圍定義 35功能架構(gòu) 35業(yè)務(wù)分類 352.3.2架構(gòu)分析過程組 36概述 36組織模型分析 38數(shù)據(jù)模型分析 38流程模型分析 38UI分析 39外部接口分析 39關(guān)鍵用例分析 39關(guān)鍵技術(shù)點(diǎn)分析 40服務(wù)定義 400干系人分析 401外部接口設(shè)計(jì)過程 412服務(wù)設(shè)計(jì)過程 432.3.3架構(gòu)設(shè)計(jì)過程組 43概述 43總體架構(gòu)設(shè)計(jì) 45框架選擇 45數(shù)據(jù)模型設(shè)計(jì) 45流程設(shè)計(jì) 45關(guān)鍵技術(shù)點(diǎn)設(shè)計(jì) 45外部接口設(shè)計(jì) 46UI設(shè)計(jì) 48服務(wù)設(shè)計(jì)過程 480質(zhì)量設(shè)計(jì) 481設(shè)計(jì)視圖分配 482部署視圖設(shè)計(jì) 483團(tuán)隊(duì)開發(fā)管理設(shè)計(jì) 482.3.4架構(gòu)實(shí)現(xiàn)過程組 49概述 49工作績效信息收集 49架構(gòu)實(shí)現(xiàn) 492.3.5架構(gòu)測(cè)試過程組 49概述 49測(cè)試規(guī)劃 50服務(wù)測(cè)試 50功能測(cè)試 50性能測(cè)試 51技術(shù)指標(biāo)測(cè)試 51架構(gòu)優(yōu)化 512.3.6架構(gòu)監(jiān)控過程組 51概述 51業(yè)務(wù)模型合理性跟蹤 51績效報(bào)告 522.3.7架構(gòu)收尾過程組 52概述 52管理收尾 52架構(gòu)進(jìn)化 52第三章應(yīng)用架構(gòu)分解結(jié)構(gòu) 533.1總體架構(gòu) 533.2基礎(chǔ)支撐層 543.2.1全景圖 543.2.2硬件/網(wǎng)絡(luò)層設(shè)計(jì) 55主機(jī)設(shè)計(jì) 55網(wǎng)絡(luò)規(guī)劃 57存儲(chǔ)/備份設(shè)計(jì) 57其它硬件設(shè)備 603.2.3系統(tǒng)軟件層設(shè)計(jì) 60操作系統(tǒng)選型 61應(yīng)用服務(wù)器選型 62數(shù)據(jù)庫服務(wù)器選型 63其它系統(tǒng)軟件選型 643.2.4支撐軟件層設(shè)計(jì) 64技術(shù)架構(gòu)選擇 64軟件框架設(shè)計(jì) 67基礎(chǔ)構(gòu)件/服務(wù)設(shè)計(jì) 67其它構(gòu)件 673.2.5與架構(gòu)其它層關(guān)系 673.2.6相關(guān)規(guī)范與標(biāo)準(zhǔn) 673.2.7服務(wù)運(yùn)行、管理和監(jiān)控環(huán)境 673.3政務(wù)資源層 683.3.1政務(wù)資源層總體架構(gòu) 68傳統(tǒng)資源層面臨的問題 68架構(gòu)目標(biāo) 69架構(gòu)總圖及描述 69政務(wù)資源層應(yīng)用前景和趨勢(shì) 703.3.2政務(wù)信息資源 70政務(wù)信息資源的封裝 71政務(wù)信息資源的接入 71政務(wù)信息資源的管理 72政務(wù)信息資源的訪問 733.3.3部門業(yè)務(wù)應(yīng)用資源 73應(yīng)用資源的封裝 74應(yīng)用資源的接入 74應(yīng)用資源的管理 75應(yīng)用資源的統(tǒng)一訪問 753.3.4政務(wù)目錄資源 76資源元數(shù)據(jù)描述 77資源編目 79安全管理 79基于目錄的資源共享體系 803.4支撐服務(wù)層 813.4.1全景圖 813.4.2描述 813.4.3服務(wù)構(gòu)成 82公共服務(wù) 82領(lǐng)域服務(wù) 893.5業(yè)務(wù)應(yīng)用層 913.5.1全景圖 913.5.2描述 913.5.3基于SOA業(yè)務(wù)應(yīng)用層的業(yè)務(wù)應(yīng)用模式 92從軟基礎(chǔ)設(shè)施的視角研究模式分類 93基于SOA的資源共享應(yīng)用模式 95基于SOA的業(yè)務(wù)協(xié)同應(yīng)用模式 96基于SOA的不同服務(wù)渠道的應(yīng)用模式 963.5.4與其它各層的關(guān)系 97業(yè)務(wù)應(yīng)用層對(duì)基礎(chǔ)支撐層的要求 97業(yè)務(wù)應(yīng)用層對(duì)展現(xiàn)服務(wù)層的支持 98業(yè)務(wù)應(yīng)用層對(duì)安全保障體系的要求 983.6展現(xiàn)服務(wù)層 993.6.1全景圖 993.6.2適配器 1003.6.3支撐運(yùn)行環(huán)境 1003.6.4具體的展現(xiàn)服務(wù) 1013.6.5展現(xiàn)服務(wù)相關(guān)的標(biāo)準(zhǔn)體系、工具集、安全保障體系 1013.7工具集 1023.7.1全景圖 1033.7.2開發(fā)和部署服務(wù) 103服務(wù)的體系架構(gòu)/模型 105體系架構(gòu)說明 106功能模塊概述 106功能模塊間關(guān)系概述 107功能詳細(xì)說明 107與其他服務(wù)關(guān)系 1103.8標(biāo)準(zhǔn)規(guī)范體系 1123.8.1全景圖 1123.8.2基礎(chǔ)支撐層 1123.8.3政務(wù)資源層 1163.8.4支撐服務(wù)層 1183.8.5業(yè)務(wù)應(yīng)用層 1223.8.6展現(xiàn)服務(wù)層 1233.8.7安全保障體系 1243.9安全保障體系 126[全景圖] 126安全在整個(gè)SOA體系中的作用和位置 128安全保障體系的總體邏輯框架 129安全保障體系中采用的標(biāo)準(zhǔn)規(guī)范體系框架圖 1303.9.2SOA安全實(shí)施要點(diǎn)及方法 131端到端SOAP消息交換的安全 131Web服務(wù)策略機(jī)制 131令牌轉(zhuǎn)換和信任域 133安全對(duì)話 133跨域的互信任操作 134SOA系統(tǒng)的安全管理制度 135第四章應(yīng)用架構(gòu)設(shè)計(jì)路線圖 1364.1全景圖 1364.2基礎(chǔ)SOA 1374.3網(wǎng)絡(luò)化SOA 1384.4流程支撐的SOA 138附錄A術(shù)語表 141附錄B架構(gòu)設(shè)計(jì)資料參考 142附錄C案例描述 142第一章引論本指南的目的基本目的是識(shí)別SOA電子政務(wù)領(lǐng)域應(yīng)用架構(gòu)設(shè)計(jì)知識(shí)體系普遍公認(rèn)為良好做法的那一部分。識(shí)別，指一般概括性介紹，而非詳盡無遺漏的說明。普遍公認(rèn)，指介紹的知識(shí)和做法在絕大多數(shù)情況下適用于絕大多數(shù)的架構(gòu)設(shè)計(jì)，其價(jià)值和實(shí)用性也得到了人們的廣泛認(rèn)同。良好做法，指一致認(rèn)為，正確應(yīng)用這些技能、工具和技術(shù)能夠增加范圍極為廣泛的各種不同架構(gòu)設(shè)計(jì)成功的機(jī)會(huì)。良好做法并不是說這些知識(shí)和做法一成不變地應(yīng)用于或應(yīng)當(dāng)應(yīng)用于所有的架構(gòu)設(shè)計(jì)：架構(gòu)設(shè)計(jì)團(tuán)隊(duì)負(fù)責(zé)架構(gòu)的裁剪和擴(kuò)展。本指南還旨在作為該職業(yè)和實(shí)踐一個(gè)共同的術(shù)語匯編，為討論、書寫和應(yīng)用架構(gòu)設(shè)計(jì)方面的問題提供便利。這種術(shù)語匯編是一種職業(yè)必不可少的組成部分。本指南還提供了一個(gè)參考的電子政務(wù)應(yīng)用架構(gòu)，并結(jié)合一個(gè)具體案例講解如何在電子政務(wù)領(lǐng)域進(jìn)行基于SOA的應(yīng)用架構(gòu)設(shè)計(jì)。本指南用來指導(dǎo)電子政務(wù)領(lǐng)域政務(wù)系統(tǒng)建設(shè)和政務(wù)系統(tǒng)之間的整合任務(wù)的架構(gòu)設(shè)計(jì)。而附錄B列出了架構(gòu)設(shè)計(jì)資料的其他來源。本指南依據(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)盟依據(jù)《國家電子政務(wù)總體框架》，遵循國家電子政務(wù)標(biāo)準(zhǔn)，參照《北京市電子政務(wù)總體技術(shù)框架》，結(jié)合長風(fēng)聯(lián)盟SOA電子政務(wù)解決方案的實(shí)際情況，制定出長風(fēng)聯(lián)盟SOA總統(tǒng)技術(shù)架構(gòu)。目標(biāo)是作為長風(fēng)聯(lián)盟企業(yè)實(shí)施SOA架構(gòu)的電子政務(wù)系統(tǒng)的標(biāo)準(zhǔn)型、指導(dǎo)性框架，實(shí)現(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)用通暢運(yùn)行。該架構(gòu)將成為未來電子政務(wù)實(shí)施的重要指導(dǎo)。該架構(gòu)又稱為“五橫三縱架構(gòu)”。什么是SOA電子政務(wù)總體應(yīng)用架構(gòu)設(shè)計(jì)SOA電子政務(wù)總體應(yīng)用架構(gòu)設(shè)計(jì)就是把各種知識(shí)、技能、手段和技術(shù)應(yīng)用于架構(gòu)活動(dòng)中，以達(dá)到系統(tǒng)建設(shè)和系統(tǒng)整合的要求。架構(gòu)設(shè)計(jì)必須權(quán)衡質(zhì)量、時(shí)間、范圍和費(fèi)用等方面的要求。其中：下面介紹幾個(gè)通常會(huì)在系統(tǒng)設(shè)計(jì)中涉及的質(zhì)量屬性。性能指系統(tǒng)提供的服務(wù)要滿足一定的性能衡量標(biāo)準(zhǔn)，這些標(biāo)準(zhǔn)可能包括系統(tǒng)反應(yīng)時(shí)間以及處理交易量的能力等。通?？梢愿鶕?jù)每個(gè)用戶訪問的系統(tǒng)響應(yīng)時(shí)間來衡量系統(tǒng)的整體性能;也可以通過系統(tǒng)能夠處理的交易量(每秒)來衡量系統(tǒng)的性能。對(duì)于架構(gòu)設(shè)計(jì)師來說，無論采取哪種衡量系統(tǒng)性能的方法來構(gòu)建系統(tǒng)架構(gòu)，這些對(duì)于性能的考慮對(duì)系統(tǒng)設(shè)計(jì)開發(fā)人員來說都應(yīng)該是透明的，也就是說對(duì)于系統(tǒng)整體架構(gòu)性能的考慮應(yīng)該是架構(gòu)設(shè)計(jì)師的工作，而不是系統(tǒng)設(shè)計(jì)開發(fā)人員應(yīng)該關(guān)注的事情。在較傳統(tǒng)的基于EJB或者XML-RPC的分布式計(jì)算模型中，它們的服務(wù)提供都是通過函數(shù)調(diào)用的方式進(jìn)行的，一個(gè)功能的完成往往需要通過客戶端和服務(wù)器來回很多次的遠(yuǎn)程函數(shù)調(diào)用才能完成。在Intranet的環(huán)境下，這些調(diào)用給系統(tǒng)的響應(yīng)速度和穩(wěn)定性帶來的影響都可以忽略不計(jì)，但如果我們?cè)诨赟OA的架構(gòu)中使用了很多WebService來作為服務(wù)提供點(diǎn)的話，我們就需要考慮性能的影響，尤其是在Internet環(huán)境下，這些往往是決定整個(gè)系統(tǒng)是否能正常工作的一個(gè)關(guān)鍵決定因素。因此在基于SOA的系統(tǒng)中，推薦采用大數(shù)據(jù)量低頻率訪問模式，也就是以大數(shù)據(jù)量的方式一次性進(jìn)行信息交換。這樣做可以在一定程度上提高系統(tǒng)的整體性能?？缮?jí)性指當(dāng)系統(tǒng)負(fù)荷加大時(shí)，仍能夠確保所需的服務(wù)質(zhì)量，而不需要更改整個(gè)系統(tǒng)的架構(gòu)。當(dāng)基于SOA的系統(tǒng)中負(fù)荷增大時(shí)，如果系統(tǒng)的響應(yīng)時(shí)間仍能夠在可接受的限度內(nèi)，那么我們就可以認(rèn)為這個(gè)系統(tǒng)是具有可升級(jí)性的。要想理解可升級(jí)性，我們必須首先了解系統(tǒng)容量或系統(tǒng)的承受能力，也就是一個(gè)系統(tǒng)在保證正常運(yùn)行質(zhì)量的同時(shí)，所能夠處理的最大進(jìn)程數(shù)量或所能支持的最大用戶數(shù)量。如果系統(tǒng)運(yùn)轉(zhuǎn)時(shí)已經(jīng)不能在可接受時(shí)間范圍內(nèi)反應(yīng)，那么這個(gè)系統(tǒng)已經(jīng)到達(dá)了它的最大可升級(jí)狀態(tài)。要想升級(jí)已達(dá)到最大負(fù)載能力的系統(tǒng)，你必須增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升級(jí)包括為現(xiàn)在的機(jī)器增加處理器、內(nèi)存或硬盤。水平升級(jí)包括在環(huán)境中添置新的機(jī)器，從而增加系統(tǒng)的整體處理能力。作為一個(gè)系統(tǒng)架構(gòu)設(shè)計(jì)師所設(shè)計(jì)出來的架構(gòu)必須能夠處理對(duì)硬件的垂直或者水平升級(jí)?；赟OA的系統(tǒng)架構(gòu)可以很好地保證整體系統(tǒng)的可升級(jí)性，這主要是因?yàn)橄到y(tǒng)中的功能模塊已經(jīng)被抽象成不同的服務(wù)，所有的硬件以及底層平臺(tái)的信息都被屏蔽在服務(wù)之下，因此不管是對(duì)已有系統(tǒng)的水平升級(jí)還是垂直升級(jí)，都不會(huì)影響到系統(tǒng)整體的架構(gòu)?？煽啃灾复_保各應(yīng)用及其相關(guān)的所有交易的完整性和一致性的能力。當(dāng)系統(tǒng)負(fù)荷增加時(shí)，系統(tǒng)必須能夠持續(xù)處理需求訪問，并確保系統(tǒng)能夠象負(fù)荷未增加以前一樣正確地處理各個(gè)進(jìn)程?？煽啃钥赡軙?huì)在一定程度上限制系統(tǒng)的可升級(jí)性。如果系統(tǒng)負(fù)荷增加時(shí)，不能維持它的可靠性，那么實(shí)際上這個(gè)系統(tǒng)也并不具備可升級(jí)性。因此，一個(gè)真正可升級(jí)的系統(tǒng)必須是可靠的系統(tǒng)。在基于SOA來構(gòu)建系統(tǒng)架構(gòu)的時(shí)候，可靠性也是必須要著重考慮的問題。要在基于SOA架構(gòu)的系統(tǒng)中保證一定的系統(tǒng)可靠性，就必須要首先保證分布在系統(tǒng)中的不同服務(wù)的可靠性。而不同服務(wù)的可靠性一般可以由其部署的應(yīng)用服務(wù)器或Web服務(wù)器來保證。只有確保每一個(gè)SOA系統(tǒng)中的服務(wù)都具有較高的可靠性，我們才能保證系統(tǒng)整體的可靠性能夠得以保障?？捎眯灾复_保一項(xiàng)服務(wù)或者資源應(yīng)該總是可被訪問到的?？煽啃钥梢栽黾酉到y(tǒng)的整體可用性，但即使系統(tǒng)部件出錯(cuò)，有時(shí)卻并不一定會(huì)影響系統(tǒng)的可用性。通過在環(huán)境中設(shè)置冗余組件和錯(cuò)誤恢復(fù)機(jī)制，雖然一個(gè)單獨(dú)的組件的錯(cuò)誤會(huì)對(duì)系統(tǒng)的可靠性產(chǎn)生不良的影響，但由于系統(tǒng)冗余的存在，使得整個(gè)系統(tǒng)服務(wù)仍然可用。在基于SOA來構(gòu)建系統(tǒng)架構(gòu)的時(shí)候，對(duì)于關(guān)鍵性的服務(wù)需要更多地考慮其可用性需求，這可以由兩個(gè)層次的技術(shù)實(shí)現(xiàn)來支持，第一種是利用不同服務(wù)的具體內(nèi)部實(shí)現(xiàn)內(nèi)部所基于的框架的容錯(cuò)或者冗余機(jī)制來實(shí)現(xiàn)對(duì)服務(wù)可用性的支持;第二種是通過UDDI等動(dòng)態(tài)查找匹配方式來支持系統(tǒng)整體的高可用性。在SOA架構(gòu)設(shè)計(jì)師構(gòu)建企業(yè)系統(tǒng)架構(gòu)的時(shí)候，應(yīng)該綜合考慮這兩個(gè)方面的內(nèi)容，盡量保證所構(gòu)建的SOA系統(tǒng)架構(gòu)中的關(guān)鍵性業(yè)務(wù)能具有較高的可用性?？蓴U(kuò)展性指在不影響現(xiàn)有系統(tǒng)功能的基礎(chǔ)上，為系統(tǒng)添加新的功能或修改現(xiàn)有功能的能力。當(dāng)系統(tǒng)剛配置好的時(shí)候，你很難衡量它的可擴(kuò)展性，直到第一次你必須去擴(kuò)展系統(tǒng)已有功能的時(shí)候，你才能真正去衡量和檢測(cè)整個(gè)系統(tǒng)的可擴(kuò)展性。任何一個(gè)架構(gòu)設(shè)計(jì)師在構(gòu)建系統(tǒng)架構(gòu)時(shí)，為了確保架構(gòu)設(shè)計(jì)的可擴(kuò)展性，都應(yīng)該考慮下面幾個(gè)要素:低耦合，界面(interfaces)以及封裝。當(dāng)架構(gòu)設(shè)計(jì)師基于SOA來構(gòu)建企業(yè)系統(tǒng)架構(gòu)時(shí)，就已經(jīng)隱含地解決了這幾個(gè)可擴(kuò)展性方面的要素。這是因?yàn)镾OA架構(gòu)中的不同服務(wù)之間本身就保持了一種無依賴的低耦合關(guān)系;服務(wù)本身是通過統(tǒng)一的接口定義(可以是WSDL)語言來描述具體的服務(wù)內(nèi)容，并且很好地封裝了底層的具體實(shí)現(xiàn)?？删S護(hù)性指在不影響系統(tǒng)其他部分的情況下修改現(xiàn)有系統(tǒng)功能中問題或缺陷的能力。當(dāng)系統(tǒng)剛被部署時(shí)，你很難判斷一個(gè)系統(tǒng)是否已經(jīng)具備了很好的可維護(hù)性。當(dāng)創(chuàng)建和設(shè)計(jì)系統(tǒng)架構(gòu)時(shí)，要想提高系統(tǒng)的可維護(hù)性，你必須考慮下面幾個(gè)要素:低耦合、模塊性以及系統(tǒng)文檔記錄。在企業(yè)系統(tǒng)可擴(kuò)展性中我們已經(jīng)提到了SOA架構(gòu)能為系統(tǒng)中暴露出來的各個(gè)子功能模塊也就是服務(wù)帶來低耦合性和很好的模塊性。關(guān)于系統(tǒng)文檔紀(jì)錄，除了底層子系統(tǒng)的相關(guān)文檔外，基于SOA的系統(tǒng)還會(huì)引用到許多系統(tǒng)外部的由第三方提供的服務(wù)，因此如果人力資源準(zhǔn)許的話，應(yīng)該增加專職的文檔管理員來專門負(fù)責(zé)有關(guān)整個(gè)企業(yè)系統(tǒng)所涉及的所有外部服務(wù)相關(guān)文檔的收集、歸類和整理，這些相關(guān)的文檔可能涉及到第三方服務(wù)的接口(可以是WSDL)、服務(wù)的質(zhì)量和級(jí)別、具體性能測(cè)試結(jié)果等各種相關(guān)文檔?；谶@些文檔，就可以為SOA架構(gòu)設(shè)計(jì)師構(gòu)建企業(yè)SOA架構(gòu)提供很好的文檔參考和支持?？晒芾硇灾腹芾硐到y(tǒng)以確保整個(gè)系統(tǒng)的可升級(jí)性、可靠性、可用性、性能和安全性的能力。具有可管理性的系統(tǒng)，應(yīng)具備對(duì)服務(wù)質(zhì)量需求(QoS)的系統(tǒng)監(jiān)控能力，通過改變系統(tǒng)的配置從而可以動(dòng)態(tài)地改善服務(wù)質(zhì)量，而不用改變整體系統(tǒng)架構(gòu)。一個(gè)好的系統(tǒng)架構(gòu)必須能夠監(jiān)控整個(gè)系統(tǒng)的運(yùn)行情況并具備動(dòng)態(tài)系統(tǒng)配置管理的功能。在對(duì)復(fù)雜系統(tǒng)進(jìn)行系統(tǒng)架構(gòu)建模時(shí)，SOA架構(gòu)設(shè)計(jì)師應(yīng)該盡量考慮利用將系統(tǒng)整體架構(gòu)構(gòu)建在已有的成熟的底層系統(tǒng)框架(Framework)上。安全性指確保系統(tǒng)安全不會(huì)被危及的能力。目前，安全性應(yīng)該說是最困難的系統(tǒng)質(zhì)量控制點(diǎn)。這是因?yàn)榘踩圆粌H要求確保系統(tǒng)的保密和完整性，而且還要防止影響可用性的服務(wù)拒絕(Denial-of-Service)攻擊。這就要求當(dāng)SOA架構(gòu)設(shè)計(jì)師在構(gòu)建一個(gè)架構(gòu)時(shí)，應(yīng)該把整體系統(tǒng)架構(gòu)盡可能地分割成各個(gè)子功能模塊，在將一些子功能模塊暴露為外部用戶可見的服務(wù)的時(shí)候，要圍繞各個(gè)子模塊構(gòu)建各自的安全區(qū)，這樣更便于保證整體系統(tǒng)架構(gòu)的安全。如果一個(gè)子模塊受到了安全攻擊，也可以保證其他模塊相對(duì)安全。如果企業(yè)SOA架構(gòu)中的一些服務(wù)是由WebService實(shí)現(xiàn)的，在考慮這些服務(wù)安全性的時(shí)候也要同時(shí)考慮效率的問題，因?yàn)閃S-Security會(huì)為WebService帶來一定的執(zhí)行效率損耗。高質(zhì)量的架構(gòu)設(shè)計(jì)還考慮了技術(shù)風(fēng)險(xiǎn)應(yīng)對(duì)的因素。應(yīng)對(duì)變化，權(quán)衡不變與變化是架構(gòu)設(shè)計(jì)永恒的主題。架構(gòu)設(shè)計(jì)中還必須考慮SOA的獨(dú)特性,例如：服務(wù)分類方法等。[1]按服務(wù)在系統(tǒng)建設(shè)中的用途劃分：[2]按服務(wù)的功能劃分：基本服務(wù)：數(shù)據(jù)中心的服務(wù)和邏輯中心的服務(wù)中介服務(wù)：技術(shù)網(wǎng)關(guān)、適配器、外觀、裝飾服務(wù)以流程為中心的服務(wù)公共企業(yè)服務(wù)：為跨企業(yè)集成提供接口，例如SMS、Email等另外應(yīng)用程序前端是SOA的激活元素。本指南的章節(jié)組織主要分4章介紹。第1章引論第2章應(yīng)用架構(gòu)設(shè)計(jì)知識(shí)領(lǐng)域、設(shè)計(jì)原則和過程組第3章應(yīng)用架構(gòu)分解結(jié)構(gòu)第4章應(yīng)用架構(gòu)設(shè)計(jì)路線圖應(yīng)用架構(gòu)設(shè)計(jì)的主要內(nèi)容依據(jù)SOA-RA-TF的參考架構(gòu)，解決電子政務(wù)應(yīng)用領(lǐng)域如何產(chǎn)出一個(gè)SOA應(yīng)用架構(gòu)的問題：架構(gòu)的生命期構(gòu)成整體架構(gòu)設(shè)計(jì)過程組架構(gòu)分解結(jié)構(gòu)(五橫三縱架構(gòu))知識(shí)領(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)實(shí)現(xiàn)，如不能滿足，架構(gòu)上應(yīng)考慮松耦合的互連互通，保障符合RA標(biāo)準(zhǔn)的服務(wù)庫和應(yīng)用系統(tǒng)能夠和本應(yīng)用架構(gòu)協(xié)同。另外RA為應(yīng)用架構(gòu)分解結(jié)構(gòu)中的服務(wù)開發(fā)運(yùn)行體系提供支撐機(jī)制，如ESB等。應(yīng)用架構(gòu)設(shè)計(jì)環(huán)境本指南假定架構(gòu)設(shè)計(jì)在項(xiàng)目環(huán)境下進(jìn)行。應(yīng)用架構(gòu)設(shè)計(jì)受到一定環(huán)境因素的影響和約束，并反過來對(duì)這些因素產(chǎn)生影響：應(yīng)用領(lǐng)域標(biāo)準(zhǔn)規(guī)范組織過程資產(chǎn)公司戰(zhàn)略要求技術(shù)環(huán)境項(xiàng)目要求管理因素架構(gòu)設(shè)計(jì)和項(xiàng)目管理和組織日常運(yùn)作管理是密切相關(guān)的，但本指南不涉及相關(guān)內(nèi)容，請(qǐng)參考相關(guān)書籍和文獻(xiàn)資料。應(yīng)用架構(gòu)設(shè)計(jì)干系人架構(gòu)設(shè)計(jì)要考慮架構(gòu)設(shè)計(jì)干系人的要求。高層管理人員項(xiàng)目發(fā)起人項(xiàng)目經(jīng)理架構(gòu)設(shè)計(jì)師需求人員開發(fā)人員測(cè)試人員客戶應(yīng)用架構(gòu)設(shè)計(jì)指南與長風(fēng)聯(lián)盟其他文檔的關(guān)系應(yīng)用架構(gòu)設(shè)計(jì)知識(shí)領(lǐng)域、原則和過程組應(yīng)用架構(gòu)設(shè)計(jì)知識(shí)領(lǐng)域SOA設(shè)計(jì)方法學(xué)SOA設(shè)計(jì)方法并非全新的方法論，而是繼承了傳統(tǒng)的面向?qū)ο蟮脑O(shè)計(jì)方法以及面向過程的設(shè)計(jì)方法，同時(shí)又增加了SCA,，SDO，BPEL等技術(shù)，融入了面向服務(wù)的設(shè)計(jì)方法，服務(wù)參考模型OASISRM里的內(nèi)容映射，具體內(nèi)容包括服務(wù)定義、服務(wù)設(shè)計(jì)、服務(wù)管理、服務(wù)開發(fā)、服務(wù)測(cè)試和服務(wù)部署。數(shù)據(jù)建模方法學(xué)傳統(tǒng)的數(shù)據(jù)建模方法學(xué)是面向一個(gè)應(yīng)用系統(tǒng)內(nèi)部的實(shí)體的建模方法學(xué)，而在當(dāng)前數(shù)據(jù)整合、應(yīng)用整合的需求下，數(shù)據(jù)建模還要考慮在不同系統(tǒng)間進(jìn)行數(shù)據(jù)交換和數(shù)據(jù)共享的需求。基于業(yè)務(wù)效率的考慮，從業(yè)務(wù)流程出發(fā)的思路改變了數(shù)據(jù)模型。只有你從業(yè)務(wù)流程的角度來看待數(shù)據(jù)的時(shí)候，數(shù)據(jù)模型才能算真正完成。面向流程設(shè)計(jì)方法學(xué)闡述了一種以實(shí)現(xiàn)流程優(yōu)化的流程系統(tǒng)設(shè)計(jì)思想。這種設(shè)計(jì)思想是面向業(yè)務(wù)流程的，不同于傳統(tǒng)MIS系統(tǒng)面向部門職能的設(shè)計(jì)思想。首先把系統(tǒng)設(shè)計(jì)區(qū)分為原理層設(shè)計(jì)和技術(shù)層設(shè)計(jì)兩個(gè)層次，然后從業(yè)務(wù)流程設(shè)計(jì)、數(shù)據(jù)模型設(shè)計(jì)和技術(shù)架構(gòu)設(shè)計(jì)三個(gè)方面論述了原理層設(shè)計(jì)的基本思想。技術(shù)領(lǐng)域架構(gòu)設(shè)計(jì)方法學(xué)大型IT系統(tǒng)的設(shè)計(jì)通常遵循七層架構(gòu)的設(shè)計(jì)方法，包括：界面層該層是直接面向用戶（包括公眾、企業(yè)、業(yè)務(wù)人員、行政管理人員、領(lǐng)導(dǎo)等使用者）的統(tǒng)一的系統(tǒng)界面。界面層利用業(yè)界主流的IT技術(shù)支持多種渠道接入和交互（如互聯(lián)網(wǎng)、電話、手機(jī)短信等接入方式），以及統(tǒng)一的身份認(rèn)證及權(quán)限管理。應(yīng)用層應(yīng)用層提供所有的信息應(yīng)用和系統(tǒng)管理的業(yè)務(wù)邏輯，分解業(yè)務(wù)請(qǐng)求，通過應(yīng)用支撐層進(jìn)行數(shù)據(jù)處理，并將返回信息組織成所需的格式提供給客戶端。應(yīng)用系統(tǒng)分為四大部分：面向公眾和企業(yè)的外網(wǎng)應(yīng)用——審批門戶（網(wǎng)上審批系統(tǒng)前臺(tái)），提供網(wǎng)上申報(bào)和反饋查詢等在線服務(wù)功能；面向公務(wù)員的審批服務(wù)平臺(tái)，實(shí)現(xiàn)業(yè)務(wù)審批、監(jiān)督檢察、業(yè)務(wù)調(diào)度、決策支持等功能；面向公務(wù)員的政府資源共享平臺(tái)（數(shù)據(jù)共享與交換平臺(tái)），實(shí)現(xiàn)基于審批業(yè)務(wù)的數(shù)據(jù)交換與基于委辦局現(xiàn)有信息資源的數(shù)據(jù)共享使用等功能。面向公務(wù)員的開放辦公平臺(tái)，實(shí)現(xiàn)基于開放的桌面辦公系統(tǒng)，實(shí)現(xiàn)對(duì)審批過程數(shù)據(jù)的保存及歸檔等。應(yīng)用支撐層應(yīng)用支撐層構(gòu)建在J2EE應(yīng)用服務(wù)器之上，提供了一個(gè)應(yīng)用基礎(chǔ)平臺(tái)DC-BPIP，并提供大量公共服務(wù)和業(yè)務(wù)構(gòu)件，提供構(gòu)件的運(yùn)行、開發(fā)和管理環(huán)境，最大限度提高開發(fā)效率，降低工程實(shí)施、維護(hù)的成本和風(fēng)險(xiǎn)。應(yīng)用支撐層采用了行業(yè)應(yīng)用的先進(jìn)體系結(jié)構(gòu)，以建立高性能、高可靠性、高擴(kuò)展性的應(yīng)用系統(tǒng)，滿足客戶快速發(fā)展的業(yè)務(wù)需求。信息資源層信息資源層是整個(gè)系統(tǒng)的信息資源中心，涵蓋全市所有與行政審批相關(guān)的結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。它是企業(yè)信息資源的存儲(chǔ)和積累，為系統(tǒng)應(yīng)用提供數(shù)據(jù)訪問服務(wù)、備份、存儲(chǔ)功能。IT基礎(chǔ)平臺(tái)層IT基礎(chǔ)平臺(tái)為系統(tǒng)的軟硬件以及網(wǎng)絡(luò)基礎(chǔ)平臺(tái)，分為三個(gè)部分：系統(tǒng)軟件、硬件支撐平臺(tái)、和網(wǎng)絡(luò)支撐平臺(tái)。其中，系統(tǒng)軟件包括中間件、數(shù)據(jù)庫服務(wù)器軟件等；硬件支撐平臺(tái)包括：主機(jī)、存儲(chǔ)、備份等硬件設(shè)備；網(wǎng)絡(luò)支撐為系統(tǒng)運(yùn)行所依賴的網(wǎng)絡(luò)環(huán)境。它對(duì)上層應(yīng)用起到技術(shù)支撐作用支撐體系層系統(tǒng)建設(shè)和推廣運(yùn)行僅僅依賴應(yīng)用系統(tǒng)建設(shè)、硬件網(wǎng)絡(luò)建設(shè)是不夠的，需要在系統(tǒng)安全方面、標(biāo)準(zhǔn)化方面、以及系統(tǒng)運(yùn)維三個(gè)不同層面的工作來共同支撐。只有這樣，才能使系統(tǒng)建設(shè)順利進(jìn)行，也才能保證系統(tǒng)能順利推廣、穩(wěn)定運(yùn)行。法律法規(guī)層以上各個(gè)層面的建設(shè)，需要依托于現(xiàn)有的法律、法規(guī)及一些規(guī)范才可成功運(yùn)行。系統(tǒng)的分析、設(shè)計(jì)、實(shí)施都必須充分考慮這些因素。只有切實(shí)符合這些規(guī)范，系統(tǒng)才能與建設(shè)單位共同發(fā)展，得到各級(jí)用戶的認(rèn)可。而利用RUP的設(shè)計(jì)思想，則將架構(gòu)設(shè)計(jì)概括為4+1視圖：邏輯視圖。邏輯視圖關(guān)注功能，不僅包括用戶可見的功能，還包括為實(shí)現(xiàn)用戶功能而必須提供的"輔助功能模塊"；它們可能是邏輯層、功能模塊等。開發(fā)視圖。開發(fā)視圖關(guān)注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運(yùn)行于其上的系統(tǒng)軟件或中間件。開發(fā)視圖和邏輯視圖之間可能存在一定的映射關(guān)系：比如邏輯層一般會(huì)映射到多個(gè)程序包等。處理視圖。處理視圖關(guān)注進(jìn)程、線程、對(duì)象等運(yùn)行時(shí)概念，以及相關(guān)的并發(fā)、同步、通信等問題。處理視圖和開發(fā)視圖的關(guān)系：開發(fā)視圖一般偏重程序包在編譯時(shí)期的靜態(tài)依賴關(guān)系，而這些程序運(yùn)行起來之后會(huì)表現(xiàn)為對(duì)象、線程、進(jìn)程，處理視圖比較關(guān)注的正是這些運(yùn)行時(shí)單元的交互問題。物理視圖。物理視圖關(guān)注"目標(biāo)程序及其依賴的運(yùn)行庫和系統(tǒng)軟件"最終如何安裝或部署到物理機(jī)器，以及如何部署機(jī)器和網(wǎng)絡(luò)來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。物理視圖和處理視圖的關(guān)系：處理視圖特別關(guān)注目標(biāo)程序的動(dòng)態(tài)執(zhí)行情況，而物理視圖重視目標(biāo)程序的靜態(tài)位置問題；物理視圖是綜合考慮軟件系統(tǒng)和整個(gè)IT系統(tǒng)相互影響的架構(gòu)視圖。場(chǎng)景視圖。關(guān)注業(yè)務(wù)的應(yīng)用場(chǎng)景。通用架構(gòu)設(shè)計(jì)方法學(xué)架構(gòu)設(shè)計(jì)是一種權(quán)衡（trade-off）。一個(gè)問題總是有多種的解決方案。而我們要確定唯一的架構(gòu)設(shè)計(jì)的解決方案，就意味著我們要在不同的矛盾體之間做出一個(gè)權(quán)衡。我們?cè)谠O(shè)計(jì)的過程總是可以看到很多的矛盾體：開放和整合，一致性和特殊化，穩(wěn)定性和延展性等等。任何一對(duì)矛盾體都源于我們對(duì)軟件的不同期望?？墒?，要滿足我們希望軟件穩(wěn)定運(yùn)行的要求，就必然會(huì)影響我們對(duì)軟件易于擴(kuò)展的期望。我們希望軟件簡單明了，卻增加了我們?cè)O(shè)計(jì)的復(fù)雜度。沒有一個(gè)軟件能夠滿足所有的要求，因?yàn)檫@些要求之間帶有天生的互斥性。而我們?cè)u(píng)價(jià)架構(gòu)設(shè)計(jì)的好壞的依據(jù)，就只能是根據(jù)不同要求的輕重緩急，在其間做出權(quán)衡的合理性。目標(biāo)我們希望一個(gè)好的架構(gòu)能夠：重用：為了避免重復(fù)勞動(dòng)，為了降低成本，我們希望能夠重用之前的代碼、之前的設(shè)計(jì)。重用是我們不斷追求的目標(biāo)之一，但事實(shí)上，做到這一點(diǎn)可沒有那么容易。在現(xiàn)實(shí)中，人們已經(jīng)在架構(gòu)重用上做了很多的工作，工作的成果稱為框架（Framework），比如說Windows的窗口機(jī)制、J2EE平臺(tái)等。但是在企業(yè)商業(yè)建模方面，有效的框架還非常的少。透明：有些時(shí)候，我們?yōu)榱颂岣咝?，把?shí)現(xiàn)的細(xì)節(jié)隱藏起來，僅把客戶需求的接口呈現(xiàn)給客戶。這樣，具體的實(shí)現(xiàn)對(duì)客戶來說就是透明的。一個(gè)具體的例子是我們使用JSP的tag技術(shù)來代替JSP的嵌入代碼，因?yàn)槲覀兊腍TML界面人員更熟悉tag的方式。延展：我們對(duì)延展的渴求源于需求的易變。因此我們需要架構(gòu)具有一定的延展性，以適應(yīng)未來可能的變化?？墒牵缟纤f，延展性和穩(wěn)定性，延展性和簡單性都是矛盾的。因此我們需要權(quán)衡我們的投入/產(chǎn)出比。以設(shè)計(jì)出具有適當(dāng)和延展性的架構(gòu)。簡明：一個(gè)復(fù)雜的架構(gòu)不論是測(cè)試還是維護(hù)都是困難的。我們希望架構(gòu)能夠在滿足目的的情況下盡可能的簡單明了。但是簡單明了的含義究竟是什么好像并沒有一個(gè)明確的定義。使用模式能夠使設(shè)計(jì)變得簡單，但這是建立在我熟悉設(shè)計(jì)模式的基礎(chǔ)上。對(duì)于一個(gè)并不懂設(shè)計(jì)模式的人，他會(huì)認(rèn)為這個(gè)架構(gòu)很復(fù)雜。對(duì)于這種情況，我只能對(duì)他說，去看看設(shè)計(jì)模式。高效：不論是什么系統(tǒng)，我們都希望架構(gòu)是高效的。這一點(diǎn)對(duì)于一些特定的系統(tǒng)來說尤其重要。例如實(shí)時(shí)系統(tǒng)、高訪問量的網(wǎng)站。這些值的是技術(shù)上的高效，有時(shí)候我們指的高效是效益上的高效。例如，一個(gè)只有幾十到一百訪問量的信息系統(tǒng)，是不是有必要使用EJB技術(shù)，這就需要我們綜合的評(píng)估效益了。安全：安全并不是我們文章討論的重點(diǎn)，卻是架構(gòu)的一個(gè)很重要的方面。規(guī)則為了達(dá)到上述的目的，我們通常需要對(duì)架構(gòu)設(shè)計(jì)制定一些簡單的規(guī)則：功能分解顧名思義，就是把功能分解開來。為什么呢？我們之所以很難達(dá)到重用目標(biāo)就是因?yàn)槲覀兙帉懙某绦蚪?jīng)常處于一種好像是重復(fù)的功能，但又有輕微差別的狀態(tài)中。我們很多時(shí)候就會(huì)經(jīng)不住誘惑，用拷貝粘貼再做少量修改的方式完成一個(gè)功能。這種行為在XP中是堅(jiān)決不被允許的。XP提倡"Onceandonlyonce"，目的就是為了杜絕這種拷貝修改的現(xiàn)象。為了做到這一點(diǎn)，我們通常要把功能分解到細(xì)粒度。很多的設(shè)計(jì)思想都提倡小類，為的就是這個(gè)目的。所以，我們的程序中的類和方法的數(shù)目就會(huì)大大增長，而每個(gè)類和方法的平均代碼卻會(huì)大大的下降?？墒?，我們?cè)趺粗肋@個(gè)度應(yīng)該要如何把握呢，關(guān)于這個(gè)疑問，并沒有明確的答案，要看個(gè)人的功力和具體的要求，但是一般來說，我們可以用一個(gè)簡單的動(dòng)詞短語來命名類或方法的，那就會(huì)是比較好的分類方法。我們使用功能分解的規(guī)則，有助于提高重用性，因?yàn)槲覀兠總€(gè)類和方法的精度都提高了。這是符合大自然的原則的，我們研究自然的主要的一個(gè)方向就是將物質(zhì)分解。我們的思路同樣可以應(yīng)用在軟件開發(fā)上。除了重用性，功能分解還能實(shí)現(xiàn)透明的目標(biāo)，因?yàn)槲覀兪褂昧斯δ芊纸獾囊?guī)則之后，每個(gè)類都有自己的單獨(dú)功能，這樣，我們對(duì)一個(gè)類的研究就可以集中在這個(gè)類本身，而不用牽涉到過多的類。根據(jù)實(shí)際情況決定不同類間的耦合度雖然我們總是希望類間的耦合度比較低，但是我們必須客觀的評(píng)價(jià)耦合度。系統(tǒng)之間不可能總是松耦合的，那樣肯定什么也做不了。而我們決定耦合的程度的依據(jù)何在呢？簡單的說，就是根據(jù)需求的穩(wěn)定性，來決定耦合的程度。對(duì)于穩(wěn)定性高的需求，不容易發(fā)生變化的需求，我們完全可以把各類設(shè)計(jì)成緊耦合的（我們雖然討論類之間的耦合度，但其實(shí)功能塊、模塊、包之間的耦合度也是一樣的），因?yàn)檫@樣可以提高效率，而且我們還可以使用一些更好的技術(shù)來提高效率或簡化代碼，例如Java中的內(nèi)部類技術(shù)?？墒?，如果需求極有可能變化，我們就需要充分的考慮類之間的耦合問題，我們可以想出各種各樣的辦法來降低耦合程度，但是歸納起來，不外乎增加抽象的層次來隔離不同的類，這個(gè)抽象層次可以是具體的類，也可以是接口，或是一組的類（例如Beans）。我們可以借用Java中的一句話來概括降低耦合度的思想："針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程。設(shè)計(jì)不同的耦合度有利于實(shí)現(xiàn)透明和延展。對(duì)于類的客戶（調(diào)用者）來說，他不需要知道過多的細(xì)節(jié)（實(shí)現(xiàn)），他只關(guān)心他感興趣的（接口）。這樣，目標(biāo)類對(duì)客戶來說就是一個(gè)黑盒子。如果接口是穩(wěn)定的，那么，實(shí)現(xiàn)再怎么擴(kuò)展，對(duì)客戶來說也不會(huì)有很大的影響。以前那種牽一發(fā)而動(dòng)全身的問題完全可以緩解甚至避免。其實(shí)，我們仔細(xì)的觀察GOF的23種設(shè)計(jì)模式，沒有一種模式的思路不是從增加抽象層次入手來解決問題的。同樣，我們?nèi)ビ^察Java源碼的時(shí)候，我們也可以發(fā)現(xiàn)，Java源碼中存在著大量的抽象層次，初看之下，它們什么都不干，但是它們對(duì)系統(tǒng)的設(shè)計(jì)起著重大的作用。夠用就好我們?cè)谏弦徽轮芯驼勥^敏捷方法很看重剛好夠用的問題，現(xiàn)在我們結(jié)合架構(gòu)設(shè)計(jì)來看：在同樣都能夠滿足需要的情況下，一項(xiàng)復(fù)雜的設(shè)計(jì)和一項(xiàng)簡單的設(shè)計(jì)，哪一個(gè)更好。從敏捷的觀點(diǎn)來看，一定是后者。因?yàn)槟壳暗男枨笾挥?0項(xiàng)，而你的設(shè)計(jì)能夠滿足100項(xiàng)的需求，只能說這是種浪費(fèi)。你在設(shè)計(jì)時(shí)完全沒有考慮成本問題，不考慮成本問題，你就是對(duì)開發(fā)組織的不負(fù)責(zé)，對(duì)客戶的不負(fù)責(zé)。應(yīng)用模式這篇文章的寫作思路很多來源于對(duì)模式的研究。因此，文章中到處都可以看到模式思想的影子。模式是一種整理、傳播思想的非常優(yōu)秀的途徑，我們可以通過模式的方式學(xué)習(xí)他人的經(jīng)驗(yàn)。一個(gè)好的模式代表了某個(gè)問題研究的成果，因此我們把模式應(yīng)用在架構(gòu)設(shè)計(jì)上，能夠大大增強(qiáng)架構(gòu)的穩(wěn)定性。抽象架構(gòu)的本質(zhì)在于其抽象性。它包括兩個(gè)方面的抽象：業(yè)務(wù)抽象和技術(shù)抽象。架構(gòu)是現(xiàn)實(shí)世界的一個(gè)模型，所以我們首先需要對(duì)現(xiàn)實(shí)世界有一個(gè)很深的了解，然后我們還要能夠熟練的應(yīng)用技術(shù)來實(shí)現(xiàn)現(xiàn)實(shí)世界到模型的映射。因此，我們?cè)趯?duì)業(yè)務(wù)或技術(shù)理解不夠深入的情況下，就很難設(shè)計(jì)出好的架構(gòu)。當(dāng)然，這時(shí)候我們發(fā)現(xiàn)一個(gè)問題：怎樣才能算是理解足夠深入呢。我認(rèn)為這沒有一個(gè)絕對(duì)的準(zhǔn)則。一次，一位朋友問我：他現(xiàn)在做的系統(tǒng)有很大的變化，原先設(shè)計(jì)的工作流架構(gòu)不能滿足現(xiàn)在的要求。他很希望能夠設(shè)計(jì)出足夠好的工作流架構(gòu)，以適應(yīng)不同的變化。但是他發(fā)現(xiàn)這樣做無異于重新開發(fā)一個(gè)lotusnotes。我聽了他的疑問之后覺得有兩點(diǎn)問題：首先，他的開發(fā)團(tuán)隊(duì)中并沒有工作流領(lǐng)域的專家。他的客戶雖然了解自己的工作流程，但是缺乏足夠的理論知識(shí)把工作流提到抽象的地步。顯然，他本身雖然有技術(shù)方面的才能，但就工作流業(yè)務(wù)本身，他也沒有足夠的經(jīng)驗(yàn)。所以，設(shè)計(jì)出象notes那樣的系統(tǒng)的前提條件并不存在。其次，開發(fā)一個(gè)工作流系統(tǒng)的目的是什么。原先的工作流系統(tǒng)運(yùn)作的不好，其原因是有變化發(fā)生。因此才有改進(jìn)工作流系統(tǒng)的動(dòng)機(jī)出現(xiàn)?？墒?，畢竟notes是為了滿足世界上所有的工作流系統(tǒng)而開發(fā)的，他目前的應(yīng)用肯定達(dá)不到這個(gè)層次。因此，雖然做不到最優(yōu)的業(yè)務(wù)抽象，但是我們完全可以在特定目的下，特定范圍內(nèi)做到最優(yōu)的業(yè)務(wù)抽象。比如說，我們工作流可能的變化是工組流路徑的變化。我們就完全可以把工作流的路徑做一個(gè)抽象，設(shè)計(jì)一個(gè)可以動(dòng)態(tài)改變路徑的工作流架構(gòu)。有些時(shí)候，我們雖然在技術(shù)上和業(yè)務(wù)上都有所欠缺，沒有辦法設(shè)計(jì)出好的架構(gòu)。但是我們完全可以借鑒他人的經(jīng)驗(yàn)，看看類似的問題別人是如何解決的。這就是我們前面提到的模式。我們不要把模式看成是一個(gè)硬性的解決方法，它只是一種解決問題的思路。MartinFowler曾說：“模式和業(yè)務(wù)組件的區(qū)別就在于模式會(huì)引發(fā)你的思考?！痹凇斗治瞿Ｊ健芬粫?，MartinFowler提到了分析和設(shè)計(jì)的區(qū)別。分析并不僅僅只是用用例列出所有的需求，分析還應(yīng)該深入到表面需求的的背后，以得到關(guān)于問題本質(zhì)的MentalModel。然后，他引出了概念模型的概念。概念模型就類似于我們?cè)谟懻摰某橄?。MartinFowler提到了一個(gè)有趣的例子，如果要開發(fā)一套軟件來模擬桌球游戲，那么，用用例來描述各種的需求，可能會(huì)導(dǎo)致大量的運(yùn)動(dòng)軌跡的出現(xiàn)。如果你沒有了解表面現(xiàn)象之后隱藏的運(yùn)動(dòng)定律的本質(zhì)，你可能永遠(yuǎn)無法開發(fā)出這樣一個(gè)系統(tǒng)。關(guān)于架構(gòu)和抽象的問題，在后面的文章中有一個(gè)測(cè)量模式的案例可以很形象的說明這個(gè)問題。架構(gòu)的一些誤解我們花了一些篇幅來介紹架構(gòu)的一些知識(shí)?，F(xiàn)在回到我們的另一個(gè)主題上來。對(duì)于一個(gè)敏捷開發(fā)過程，架構(gòu)意味著什么，我們?cè)撊绾蚊鎸?duì)架構(gòu)。這里我們首先要澄清一些誤解：誤解1：架構(gòu)設(shè)計(jì)需要很強(qiáng)的技術(shù)能力。從某種程度來說，這句話并沒有很大的錯(cuò)誤。畢竟，你的能力越強(qiáng)，設(shè)計(jì)出優(yōu)秀架構(gòu)的幾率也會(huì)上升。但是能力和架構(gòu)設(shè)計(jì)之間并沒有一個(gè)很強(qiáng)的聯(lián)系。即使是普通的編程人員，他一樣有能力設(shè)計(jì)出能實(shí)現(xiàn)目標(biāo)的架構(gòu)。誤解2：架構(gòu)由專門的設(shè)計(jì)師來設(shè)計(jì)，設(shè)計(jì)出的藍(lán)圖交由程序員來實(shí)現(xiàn)。我們之所以會(huì)認(rèn)為架構(gòu)是設(shè)計(jì)師的工作，是因?yàn)槲覀兿矚g把軟件開發(fā)和建筑工程做類比。但是，這兩者實(shí)際上是有著很大的區(qū)別的。關(guān)鍵之處在于，建筑設(shè)計(jì)已經(jīng)有很長的歷史，已經(jīng)發(fā)展出完善的理論，可以通過某些理論（如力學(xué)原理）來驗(yàn)證設(shè)計(jì)藍(lán)圖?？墒?，對(duì)軟件開發(fā)而言，驗(yàn)證架構(gòu)設(shè)計(jì)的正確性，只能夠通過寫代碼來驗(yàn)證。因此，很多看似完美的架構(gòu)，往往在實(shí)現(xiàn)時(shí)會(huì)出現(xiàn)問題。誤解3：在一開始就要設(shè)計(jì)出完善的架構(gòu)。這種方式是最傳統(tǒng)的前期設(shè)計(jì)方式。這也是為XP所摒棄的一種設(shè)計(jì)方式。主要的原因是，在一開始設(shè)計(jì)出完美的架構(gòu)根本就是在自欺欺人。因?yàn)檫@樣做的基本假設(shè)就是需求的不變性。但需求是沒有不變的（關(guān)于需求的細(xì)節(jié)討論，請(qǐng)參看拙作『需求的實(shí)踐』）。這樣做的壞處是，我們一開始就限制了整個(gè)的軟件的形狀。而到實(shí)現(xiàn)時(shí)，我們雖然發(fā)現(xiàn)原來的設(shè)計(jì)有失誤之處，但卻不愿意面對(duì)現(xiàn)實(shí)。這使得軟件畸形的生長。原本一些簡單的問題，卻因?yàn)閯e扭的架構(gòu)，變得非常的復(fù)雜。這種例子我們經(jīng)?？梢钥吹?，例如為兼容前個(gè)版本而導(dǎo)致的軟件復(fù)雜性。而2000年問題，TCP/IP網(wǎng)絡(luò)的安全性問題也從一個(gè)側(cè)面反映了這個(gè)問題的嚴(yán)重性。誤解4：架構(gòu)藍(lán)圖交給程序員之后，架構(gòu)設(shè)計(jì)師的任務(wù)就完成了。和誤解2一樣，我們借鑒了建筑工程的經(jīng)驗(yàn)。我們看到建筑設(shè)計(jì)師把設(shè)計(jì)好的藍(lán)圖交給施工人員，施工人員就會(huì)按照?qǐng)D紙建造出和圖紙一模一樣的大廈。于是，我們也企圖在軟件開發(fā)中使用這種模式。這是非常要命的。軟件開發(fā)中缺乏一種通用的語言，能夠充分的消除設(shè)計(jì)師和程序員的溝通隔閡。有人說，UML不可以嗎？UML的設(shè)計(jì)理念是好的，可以減輕溝通障礙問題?？墒且胪耆鉀Q這個(gè)問題，UML還做不到。首先，程序員都具有個(gè)性化的思維，他會(huì)以自己的思維方式去理解設(shè)計(jì)，因?yàn)閺脑O(shè)計(jì)到實(shí)現(xiàn)并不是一項(xiàng)機(jī)械的勞動(dòng)，還是屬于一項(xiàng)知識(shí)性的勞動(dòng)（這和施工人員的工作是不同的）。此外，對(duì)于程序員來說，他還極有可能按照自己的想法對(duì)設(shè)計(jì)圖進(jìn)行一定的修改，這是非常正常的一項(xiàng)舉動(dòng)。更糟的是，程序員往往都比較自負(fù)，他們會(huì)潛意識(shí)的排斥那些未經(jīng)過自己認(rèn)同的設(shè)計(jì)。架構(gòu)設(shè)計(jì)的過程模式通常我們認(rèn)為模式都是用在軟件開發(fā)、架構(gòu)設(shè)計(jì)上的。其實(shí)，這只是模式的一個(gè)方面。模式的定義告訴我們，模式描述了一個(gè)特定環(huán)境的解決方法，這個(gè)特定環(huán)境往往重復(fù)出現(xiàn)，制定出一個(gè)較好的解決方法有利于我們?cè)谖磥砟苡行У慕鉀Q類似的問題。其實(shí)，在管理學(xué)上，也存在這種類似的這種思維。稱為結(jié)構(gòu)性問題的程序化解決方法。所以呢，我們完全可以把模式的思想用在其它的方面，而目前最佳的運(yùn)用就是過程模式和組織模式。在我們的文章中，我們僅限于討論過程模式。我們討論的過程僅限于面向?qū)ο蟮能浖_發(fā)過程。我們稱之為OOSP（object-orientedsoftwareprocess）。因?yàn)槲覀兊倪^程需要面向?qū)ο筇匦缘闹С?。?dāng)然，我們的很多做法一樣可以用在非OO的開發(fā)過程中，但是為了達(dá)到最佳的效果，我建議您使用OO技術(shù)。面向?qū)ο笤O(shè)計(jì)方法學(xué)面向?qū)ο蠓椒?Object-OrientedMethod)是一種把面向?qū)ο蟮乃枷霊?yīng)用于軟件開發(fā)過程中，指導(dǎo)開發(fā)活動(dòng)的系統(tǒng)方法，簡稱OO(Object-Oriented)方法，是建立在“對(duì)象”概念基礎(chǔ)上的方法學(xué)。對(duì)象是由數(shù)據(jù)和容許的操作組成的封裝體，與客觀實(shí)體有直接對(duì)應(yīng)關(guān)系，一個(gè)對(duì)象類定義了具有相似性質(zhì)的一組對(duì)象。而每繼承性是對(duì)具有層次關(guān)系的類的屬性和操作進(jìn)行共享的一種方式。所謂面向?qū)ο缶褪腔趯?duì)象概念，以對(duì)象為中心，以類和繼承為構(gòu)造機(jī)制，來認(rèn)識(shí)、理解、刻畫客觀世界和設(shè)計(jì)、構(gòu)建相應(yīng)的軟件系統(tǒng)。面向?qū)ο蠓椒ㄗ鳛橐环N新型的獨(dú)具優(yōu)越性的新方法正引起全世界越來越廣泛的關(guān)注和高度的重視，它被譽(yù)為"研究高技術(shù)的好方法"，更是當(dāng)前計(jì)算機(jī)界關(guān)心的重點(diǎn)。十多年來，在對(duì)OO方法如火如荼的研究熱潮中，許多專家和學(xué)者預(yù)言：正像70年代結(jié)構(gòu)化方法對(duì)計(jì)算機(jī)技術(shù)應(yīng)用所產(chǎn)生的巨大影響和促進(jìn)那樣，90年代OO方法會(huì)強(qiáng)烈地影響、推動(dòng)和促進(jìn)一系列高技術(shù)的發(fā)展和多學(xué)科的綜合。用計(jì)算機(jī)解決問題需要用程序設(shè)計(jì)語言對(duì)問題求解加以描述（即編程），實(shí)質(zhì)上，軟件是問題求解的一種表述形式。顯然，假如軟件能直接表現(xiàn)人求解問題的思維路徑（即求解問題的方法），那么軟件不僅容易被人理解，而且易于維護(hù)和修改，從而會(huì)保證軟件的可靠性和可維護(hù)性，并能提高公共問題域中的軟件模塊和模塊重用的可靠性。面向?qū)ο蟮臋C(jī)能念和機(jī)制恰好可以使得按照人們通常的思維方式來建立問題域的模型，設(shè)計(jì)出盡可能自然地表現(xiàn)求解方法的軟件。面向?qū)ο蟮幕靖拍睿簩?duì)象：對(duì)象是要研究的任何事物。從一本書到一家圖書館，單的整數(shù)到整數(shù)列龐大的數(shù)據(jù)庫、極其復(fù)雜的自動(dòng)化工廠、航天飛機(jī)都可看作對(duì)象，它不僅能表示有形的實(shí)體，也能表示無形的（抽象的）規(guī)則、計(jì)劃或事件。對(duì)象由數(shù)據(jù)（描述事物的屬性）和作用于數(shù)據(jù)的操作（體現(xiàn)事物的行為）構(gòu)成一獨(dú)立整體。從程序設(shè)計(jì)者來看，對(duì)象是一個(gè)程序模塊，從用戶來看，對(duì)象為他們提供所希望的行為。在對(duì)內(nèi)的操作通常稱為方法。類：類是對(duì)象的模板。即類是對(duì)一組有相同數(shù)據(jù)和相同操作的對(duì)象的定義，一個(gè)類所包含的方法和數(shù)據(jù)描述一組對(duì)象的共同屬性和行為。類是在對(duì)象之上的抽象，對(duì)象則是類的具體化，是類的實(shí)例。類可有其子類，也可有其它類，形成類層次結(jié)構(gòu)。消息：消息是對(duì)象之間進(jìn)行通信的一種規(guī)格說明。一般它由三部分組成：接收消息的對(duì)象、消息名及實(shí)際變?cè)?。面向?qū)ο笾饕卣鳎悍庋b性：封裝是一種信息隱蔽技術(shù)，它體現(xiàn)于類的說明，是對(duì)象的重要特性。封裝使數(shù)據(jù)和加工該數(shù)據(jù)的方法（函數(shù)）封裝為一個(gè)整體，以實(shí)現(xiàn)獨(dú)立性很強(qiáng)的模塊，使得用戶只能見到對(duì)象的外特性（對(duì)象能接受哪些消息，具有那些處理能力），而對(duì)象的內(nèi)特性（保存內(nèi)部狀態(tài)的私有數(shù)據(jù)和實(shí)現(xiàn)加工能力的算法）對(duì)用戶是隱蔽的。封裝的目的在于把對(duì)象的設(shè)計(jì)者和對(duì)象者的使用分開，使用者不必知曉行為實(shí)現(xiàn)的細(xì)節(jié)，只須用設(shè)計(jì)者提供的消息來訪問該對(duì)象。繼承性：繼承性是子類自動(dòng)共享父類之間數(shù)據(jù)和方法的機(jī)制。它由類的派生功能體現(xiàn)。一個(gè)類直接繼職其它類的全部描述，同時(shí)可修改和擴(kuò)充。繼職具有傳達(dá)室遞性。繼職分為單繼承（一個(gè)子類只有一父類）和多重繼承（一個(gè)類有多個(gè)父類）。類的對(duì)象是各自封閉的，如果沒繼承性機(jī)制，則類對(duì)象中數(shù)據(jù)、方法就會(huì)出現(xiàn)大量重復(fù)。繼承不僅支持系統(tǒng)的可重用性，而且還促進(jìn)系統(tǒng)的可擴(kuò)充性。多態(tài)性：對(duì)象根據(jù)所接收的消息而做出動(dòng)作。同一消息為不同的對(duì)象接受時(shí)可產(chǎn)生完全不同的行動(dòng)，這種現(xiàn)象稱為多態(tài)性。利用多態(tài)性用戶可發(fā)送一個(gè)通用的信息，而將所有的實(shí)現(xiàn)細(xì)節(jié)都留給接受消息的對(duì)象自行決定，如是，同一消息即可調(diào)用不同的方法。例如：Print消息被發(fā)送給一圖或表時(shí)調(diào)用的打印方法與將同樣的Print消息發(fā)送給一正文文件而調(diào)用的打印方法會(huì)完全不同。多態(tài)性的實(shí)現(xiàn)受到繼承性的支持，利用類繼承的層次關(guān)系，把具有通用功能的協(xié)議存放在類層次中盡可能高的地方，而將實(shí)現(xiàn)這一功能的不同方法置于較低層次，這樣，在這些低層次上生成的對(duì)象就能給通用消息以不同的響應(yīng)。在OOPL中可通過在派生類中重定義基類函數(shù)（定義為重載函數(shù)或虛函數(shù)）來實(shí)現(xiàn)多態(tài)性。綜上可知，在OO方法中，對(duì)象和傳遞消息分別表現(xiàn)事物及事物間相互聯(lián)系的概念。類和繼承是是適應(yīng)人們一般思維方式的描述范式。方法是允許作用于該類對(duì)象上的各種操作。這種對(duì)象、類、消息和方法的程序設(shè)計(jì)范式的基本點(diǎn)在于對(duì)象的封裝性和類的繼承性。通過封