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

2、1顯式定義邊界21自治性23服務(wù)共享大綱和契約，但不共享類24服務(wù)兼容性基于策略25訪問的開放性26隨時(shí)可用26I 27服務(wù)分級(jí)28松散耦合282210可重用的服務(wù)及服務(wù)接I I設(shè)計(jì)管理29標(biāo)準(zhǔn)化的接I I 29支持各種消息模式30精確定義服務(wù)接I I 30應(yīng)用架構(gòu)設(shè)計(jì)過程組31架構(gòu)啟動(dòng)過程組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ù)點(diǎn)分析402.329服務(wù)定義40.10干系人分析402.3211外

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

4、49.6概述492.362業(yè)務(wù)模型合理性跟蹤492.363績效報(bào)告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è)計(jì)52主機(jī)設(shè)計(jì)53網(wǎng)絡(luò)規(guī)劃55存儲(chǔ)/備份設(shè)計(jì)55其它硬件設(shè)備583.2.3系統(tǒng)軟件層設(shè)計(jì)58操作系統(tǒng)選型58應(yīng)用服務(wù)器選型59數(shù)據(jù)庫服務(wù)器選型60其它系統(tǒng)軟件選型613.2.4支撐軟件層設(shè)計(jì)61技術(shù)架構(gòu)選擇61軟件框架設(shè)計(jì)64基礎(chǔ)構(gòu)件/服務(wù)設(shè)計(jì)64A其它構(gòu)件64與架構(gòu)其它層關(guān)系64相關(guān)規(guī)范與標(biāo)準(zhǔn)65務(wù)運(yùn)行、管理和監(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)用前景和趨勢(shì)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)用層對(duì)基礎(chǔ)支撐層的要求953.542業(yè)務(wù)應(yīng)用層對(duì)展現(xiàn)服務(wù)層的支持963.543業(yè)務(wù)應(yīng)用層對(duì)安全保障體系的要求96展現(xiàn)服務(wù)層97全景圖97362適配器98363支撐運(yùn)行環(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安全在整個(gè)SOA體系中的作用和位置1233.9.L3安全保障體系的總體邏輯框架124391.4安全保障體系中采用的標(biāo)準(zhǔn)規(guī)范體系框架圖1253.9.2 SOA安全實(shí)施要點(diǎn)及方法125392.1端到端SOAP消息交換的安全1253.922 Web服務(wù)策略機(jī)制126392.3令牌轉(zhuǎn)換和信任域1273.924安全對(duì)話128392.5跨域的互信任操作1293.926 SOA系統(tǒng)的安

8、全管理制度130第四章 應(yīng)用架構(gòu)設(shè)計(jì)路線圖130全景圖130基礎(chǔ) SOA132網(wǎng)絡(luò)化SOA132流程支撐的SOA133附錄A術(shù)語表136附錄B架構(gòu)設(shè)計(jì)資料參考137附錄C案例描述-137 -第一章引論本指南的目的基本目的是識(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)用于

9、或應(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è)共同的求通匚編，為討論、書寫和 應(yīng)用架構(gòu)設(shè)計(jì)方面的問題提供便利。這種術(shù)語匯編是一種職業(yè)必不可少的組 成部分。本指南還提供了一個(gè)參考的電子政務(wù)應(yīng)用架癡并結(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)盟

10、依據(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)整合的要求

11、。其中:質(zhì)量屬性（按各種角度分類的屬性。譬如：1按生命周期劃分會(huì)有設(shè)計(jì)期，開發(fā)期，運(yùn) （行期，測(cè)試期，維護(hù)期質(zhì)量非功能需求2定量屬性和定性屬性，可用性、可修改性、 性能、安全、有效性、可測(cè)試性、可監(jiān)控 性、可追溯性、可升級(jí)性、可擴(kuò)張性、可維 護(hù)性、可管理性、可復(fù)用性、模塊獨(dú)立交付 性等）約束卜面介紹幾個(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)

12、性能的方法來構(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è)?基于SOA的架構(gòu)中使用了很多Web Service來作為服務(wù)提供點(diǎn)的話,我們 就需要考慮性能的影響，尤其是在Internet環(huán)境下，這

13、些往往是決定整個(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í)間范

14、圍內(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í)。基于SOA的系統(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)用及其

15、相關(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ù)都具有較高的可靠

16、性，我們才能保證系統(tǒng)整體的可靠性能夠得以保障。 4.可用性指確保一項(xiàng)服務(wù)或者資源應(yīng)該總是可被訪問到的。可靠性可以增加系統(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)

17、整體的高可用性。在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ù)能具有較高的可用性。.可擴(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è)要素:低耦合，界面(mteifaces)以及封裝。當(dāng)架構(gòu)設(shè)計(jì)師 基于SOA來構(gòu)建企業(yè)系統(tǒng)架構(gòu)時(shí)，就已經(jīng)隱含地解決了這幾個(gè)可擴(kuò)展性方 面的要素。

18、這是因?yàn)镾OA架構(gòu)中的不同服務(wù)之間本身就保持了一種無依賴 的低耦合關(guān)系;服務(wù)本身是通過統(tǒng)一的接口定義(可以是WSDL)語言來描述 具體的服務(wù)內(nèi)容，并且很好地封裝了底層的具體實(shí)現(xiàn)。.可維護(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)文 檔外，

19、基于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)提供很好的文檔參考和支持。.可管理性指管理系統(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ì)量，而不用改變整體系

20、統(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)框架 (Fiamewoik)_t。.安全性指確保系統(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)

21、建各自的安全區(qū)， 這樣更便于保證整體系統(tǒng)架構(gòu)的安全。如果一個(gè)子模塊受到了安全攻擊，也 可以保證其他模塊相對(duì)安全。如果企業(yè)SOA架構(gòu)中的一些服務(wù)是由 WebSemce實(shí)現(xiàn)的，在考慮這些服務(wù)安全性的時(shí)候也要同時(shí)考慮效率的問 題，因?yàn)閃S-Secunty會(huì)為Web Seivice帶來一定的執(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ù)分類方法等。臼按服務(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è)計(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)考慮松耦合的互連互通，保障符合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ā)運(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è)試人員客戶1.10應(yīng)用架構(gòu)設(shè)計(jì)指南與長風(fēng)聯(lián)盟其他文檔的關(guān)系第二章應(yīng)用架構(gòu)設(shè)計(jì)

24、知識(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ù)參考模型OASIS RM里的內(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ù)流程的角度來

25、看待數(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)證

26、及權(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)建在J2

27、EE應(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)軟件包括中

28、間件、數(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ì)

29、概括為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)

30、程，處理視圖比較關(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)衡(ade-off)。一個(gè)問題總是有多種的解決方案。而 我們要確定唯一的架構(gòu)設(shè)計(jì)的解決方案，就意味著我們要在不同的矛盾體之 間做出一個(gè)權(quán)衡。我們?cè)谠O(shè)計(jì)的過程總是

31、可以看到很多的矛盾體：開放和整 合，一致性和特殊化，穩(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)

32、在架構(gòu)重用上做了很多的工作，工作的成果稱為框 架(Frame work),比如說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)未來可能的變化。可是，如上所說，延展性和穩(wěn)定性，延展性和簡 單性都是矛盾的。因此我們需要權(quán)衡我們的投入/產(chǎn)出

33、比。以設(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)，是不是有必要使用E

34、JB技術(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è)

35、目的。所以，我們的程序中的類和方法的數(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è)類的研

36、究就可以集中在這個(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ù)。可是，如果需求極有可能變化，我們就需要 充分的考慮

37、類之間的耦合問題，我們可以想出各種各樣的辦法來降低耦合程度， 但是歸納起來，不外乎增加抽象的層次來隔離不同的類，這個(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的

38、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)用模式這

39、篇文章的寫作思路很多來源于對(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)

40、為這沒有一個(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)作的不好， 其原因是有變

41、化發(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è)硬性的解決方法，它只是 一種解決問題的思路。Ma

42、rtinFowlei-曾說：“模式和業(yè)務(wù)組件的區(qū)別就在于模式 會(huì)引發(fā)你的思考。”在分析模式一書中，MaihnFowle提到了分析和設(shè)計(jì)的區(qū)別。分析并不 僅僅只是用用例列出所有的需求，分析還應(yīng)該深入到表面需求的的背后，以得到 關(guān)于問題本質(zhì)的MentalModel。然后，他引出了概念模型的概念。概念模型就類 似于我們?cè)谟懻摰某橄蟆artinFowle提到了一個(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è)

43、量模式的案例可以很形象 的說明這個(gè)問題。架構(gòu)的一些誤解我們花了一些篇幅來介紹架構(gòu)的一些知識(shí)。現(xiàn)在回到我們的另一個(gè)主題上 來。對(duì)于一個(gè)敏捷開發(fā)過程，架構(gòu)意味著什么，我們?cè)撊绾蚊鎸?duì)架構(gòu)。這里我們 首先要澄清一些誤解：誤解L架構(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ā)和建筑工程做 類比。但是，這兩

44、者實(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í)，我們

45、雖然發(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ì)師和程序員的溝

46、通隔閡。有人說，UML不可以嗎？ UML 的設(shè)計(jì)理念是好的，可以減輕溝通障礙問題。可是要想完全解決這個(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)

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

48、法學(xué)面向?qū)ο蠓椒?Obj ect-Onented Method)是一種把面向?qū)ο蟮乃枷霊?yīng)用于 軟件開發(fā)過程中，指導(dǎo)開發(fā)活動(dòng)的系統(tǒng)方法，簡稱OO(Object-O口ented)方法, 是建立在“對(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)注和高度的重視，

49、它被譽(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ī)制

50、恰好可以 使得按照人們通常的思維方式來建立問題域的模型，設(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ù)描述一

51、組對(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ì)象者 的使用分開，使用者不

52、必知曉行為實(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ì)象

53、自行決定，如 是，同一消息即可調(diào)用不同的方法。例如：Punt消息被發(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)人們一般思維方式的描述范式。方法是允許 作用于該類

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

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

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

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

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

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

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