長風聯(lián)盟電子政務

總體應用架構(gòu)設(shè)計指南研究報告

長風開放標準平臺軟件聯(lián)盟

二。o七年五月

目錄

第一章引論1

L1本指南的目的1

1.2本指南依據(jù)的長風聯(lián)盟參考文檔1

1.3什么是SOA電子政務總體應用架構(gòu)1

L4什么是SOA電子政務總體應用架構(gòu)設(shè)計2

1.5本指南的章節(jié)組織7

L6應用架構(gòu)設(shè)計的主要內(nèi)容7

1.7應用架構(gòu)分解結(jié)構(gòu)與參考架構(gòu)(RA)7

1.8應用架構(gòu)設(shè)計環(huán)境8

1.9應用架構(gòu)設(shè)計干系人8

L10應用架構(gòu)設(shè)計指南與長風聯(lián)盟其他文檔的關(guān)系9第二章應用架構(gòu)設(shè)計知識

領(lǐng)域、原則和過程組10

2.1應用架構(gòu)設(shè)計知識領(lǐng)域10

2.1.1SOA設(shè)計方法學。

2.1.2數(shù)據(jù)建模方法學數(shù)

2.1.3面向流程設(shè)計方法學11

2.1.4技術(shù)領(lǐng)域架構(gòu)設(shè)計方法學11

2.1.5通用架構(gòu)設(shè)計方法學13

2.1.6向?qū)ο笤O(shè)計方法學19

2.2服務設(shè)計原則21

2,2.1顯式定義邊界21

222自治性

2.2.3服務共享大綱和契約，但不共享類24

2.2.4服務兼容性基于策略27-

2.2.5訪問的開放性26

2.2.6隨時可用26

2.2.7127

228服務分級28

2.2.9松散耦合28

2210可重用的服務及服務接II設(shè)計管理29

2.2.11標準化的接II29

2212支持各種消息模式30

2.2.13精確定義服務接II30

2.3應用架構(gòu)設(shè)計過程組31

2.3,1架構(gòu)啟動過程組33

述_33

231.2務模型合理性初步分析34

231.3架構(gòu)范圍定義35

功能架構(gòu)35

231.5業(yè)務分類35

2.3.2架構(gòu)分析過程組36

1.1.2」概述荻"

2.322組織模型分析37

2.323數(shù)據(jù)模型分析38

2.324流程模型分析38

2.3255分析39

2.326外部接II分析39

2.327關(guān)鍵用例分析用

2.328關(guān)鍵技術(shù)點分析40

2.329服務定義40

2.327.10干系人分析40

2.3211外部接11設(shè)計過程41

2.3212月艮務設(shè)計過程42

2.3.3架構(gòu)設(shè)計過程組42

2.3.3」概述4廠

233.2總體架構(gòu)設(shè)計44

2.333框架選擇44

2.334數(shù)據(jù)模型設(shè)計44

2.335流程設(shè)計44

技術(shù)點設(shè)計44

2.337外部接II設(shè)計45

UI設(shè)計46

2.339服務設(shè)計過程46

LL1.10質(zhì)量設(shè)計46

1設(shè)計視圖分配46

2.3312部署視圖設(shè)計46

2.3313團隊開發(fā)管理設(shè)計47

2.3.4架構(gòu)實現(xiàn)過程組47

L1.4」概述萬-

1.2工作績效信息收集47

L3架構(gòu)實現(xiàn)47

235架構(gòu)測試過程組47

2.3.5」概述E

2.352測試規(guī)劃48

2.353服務測試48

2.354功能測試48

2.355性能測試49

2.356技術(shù)指標測試49

2.357架構(gòu)優(yōu)化49

2.3.6架構(gòu)監(jiān)控過程組49

1.1.6」概述49

2.362業(yè)務模型合理性跟蹤49

2.363績效報告50

237架構(gòu)收尾過程組50

1.2.7」概述

1.3鐘理收-50

1.4架構(gòu)進化50

第三章應用架構(gòu)分解結(jié)構(gòu)50

3.1總體架須0

3.2基礎(chǔ)支撐層51

3.2.1全景圖51

3.2.2硬件/網(wǎng)絡層設(shè)計52

3.221主機設(shè)計53

3.222網(wǎng)絡規(guī)劃55

3.223存儲/備份設(shè)計55

3.224其它硬件設(shè)備58

3.2.3系統(tǒng)軟件層設(shè)計58

323.1操作系統(tǒng)選型58

323.2應用服務器選型59

323.3數(shù)據(jù)庫服務器選型60

323.4其它系統(tǒng)軟件選型61

324支撐軟件層設(shè)計61

3.2.4」技術(shù)架構(gòu)選擇61

3.2.5軟件框架設(shè)計64

3.2.6基礎(chǔ)構(gòu)件/服務設(shè)計64

3.2.74其它構(gòu)件64

3.2.8與架構(gòu)其它層關(guān)系64

3.2.9相關(guān)規(guī)范與標準65

3.2.10務運行、管理和監(jiān)控環(huán)境65

3.3政務資源層65

3.3.1政務資源層總體架構(gòu)65

統(tǒng)資源層面臨的問題65

3.3.L2~架構(gòu)目標66

331.3架構(gòu)總圖及描述66

務資源層應用前景和趨勢67

3.3.2政務信息資源68

3.321政務信息資源的封裝68

3.322政務信息資源的接入69

3.323政務信息資源的管理69

3.324政務信息資源的訪問70

3.3.3部門業(yè)務應用資源71

3.3.3」應用資源的封裝71

333.2應用資源的接入72

3.333應用資源的管理72

3.334應用資源的統(tǒng)一訪問73

3.3.4政務目錄資源73

334」資源元數(shù)據(jù)描述74

334.2資源編目76

334.3安全管理77

3.344基于目贏資源共享體系77

3.4支撐服務層79

3.4.1全景圖79

3.4.2描述79

3.4.3服務構(gòu)成80

3.4.3」公共服務80

343.2領(lǐng)域服務87

3.5業(yè)務應用層89

3.5.1全景圖89

3.5.2描述89

3.5.3基于SOA業(yè)務應用層的業(yè)務應用模式90

353.1從軟基礎(chǔ)設(shè)施的視角研究模式分類91

353.2基于SOA的資源共享應用模式93—

3.533基于SOA的業(yè)務協(xié)同應用模式94

353.4基于SOA的不同服務渠道的應用模式94

3.5.4與其它各層的關(guān)系95

354.1業(yè)務應用層對基礎(chǔ)支撐層的要求95

3.542業(yè)務應用層對展現(xiàn)服務層的支持96

3.543業(yè)務應用層對安全保障體系的要求96

3.6展現(xiàn)服務層97

3.6.1全景圖97

362適酉己器98

363支撐運行環(huán)境98

3.6.4具體的展現(xiàn)服務99

365展現(xiàn)服務相關(guān)的標準體系、工具集、安全保障體系99

3.7工具集100

3.71全景圖101

3.722開發(fā)和部署服務101

3.721服務的體系架構(gòu)/模型103

3.722體系架構(gòu)說明體4

3.723功能模塊概述104

3.724功能模塊間關(guān)系概述105

3.725功能詳細說明105

3.726與其他服務關(guān)系108

3.8標準規(guī)范體系110

3.8.1全景圖110

3.8.2基礎(chǔ)支撐層110

3.8.3政務資源層113

3.8.4支撐服務層114

3.8.5業(yè)務應用層118

3.8.6展現(xiàn)服務層118

3.8.7安全保障體系119

3.9安全保障體系121

［全景圖］121

391.2安全在整個SOA體系中的作用和位置123

3.9.L3安全保障體系的總體邏輯框架124

391.4安全保障體系中采用的標準規(guī)范體系框架圖125

3.9.2SOA安全實施要點及方法125

392.1端到端SOAP消息交換的安全125

3.922Web服務策略機制服1

392.3令牌轉(zhuǎn)換和信任域127

3.924安全對話128

392.5跨域的互信任操作129

3.926SOA系統(tǒng)的安全管理制度130

第四章應用架構(gòu)設(shè)計路線圖130

4.1全景圖130

4.2基礎(chǔ)SOA132

4.3網(wǎng)絡化SOA132

4.4流程支撐的SOA133

附錄A術(shù)語表136

附錄B架構(gòu)設(shè)計資料參考137

附錄C案例描述-137-

第一章引論

1.1本指南的目的

基本目的是識別SOA電子政務領(lǐng)域應用架構(gòu)設(shè)計知識體系普遍公認為良好

做法的那一部分。

深閱指一般概括性介紹，而非詳盡無遺漏的說明。

哥遇公認，指介紹的知識和做法在絕大多數(shù)情況下適用于絕大多數(shù)的架構(gòu)設(shè)

計，其價值和實用性也得到了人們的廣泛認同。

良好做法指一致認為,正確應用這些技能、工具和技術(shù)能夠增加范圍極為廣泛

的各種不同架構(gòu)設(shè)計成功的機會。良好做法并不是說這些知識和做法一成不變地

應用于或應當應用于所有的架構(gòu)設(shè)計：

架構(gòu)設(shè)計團隊負責架構(gòu)的裁剪和擴展。

本指南還旨在作為該職業(yè)和實踐一個共同的求通匚編，為討論、書寫和應用

架構(gòu)設(shè)計方面的問題提供便利。這種術(shù)語匯編是一種職業(yè)必不可少的組成部分。

本指南還提供了一個參考的電子政務應用架癡并結(jié)合一個具體案例講解如何

在電子政務領(lǐng)域進行基于SOA的應用架構(gòu)設(shè)計。

本指南用來指導電子政務領(lǐng)域政務系統(tǒng)建設(shè)和政務系統(tǒng)之間的整合任務的架

構(gòu)設(shè)計。

而附錄B列出了架構(gòu)設(shè)計資料的其他來源。

1.2本指南依據(jù)的長風聯(lián)盟參考文檔

?SOA-RA-TF制定的《SOA參考架構(gòu)白皮書》

?SOA-AP-TF制定的《SOA電子政務總體技術(shù)架構(gòu)與解決方案》

1.3什么是SOA電子政務總體應用架構(gòu)

長風聯(lián)盟依據(jù)《國家電子政務總體框架》，遵循國家電子政務標準，參照

《北京市電子政務總體技術(shù)框架》，結(jié)合長風聯(lián)盟SOA電子政務解決方案的實

際情況，制定出長風聯(lián)盟SOA總統(tǒng)技術(shù)架構(gòu)。目標是作為長風聯(lián)盟企業(yè)實施SOA

架構(gòu)的電子政務系統(tǒng)的標準型、指導性框架，實現(xiàn)未來電子政務系統(tǒng)的互聯(lián)互通、

資源共享，并使聯(lián)盟企業(yè)可以快速、流暢、高效地構(gòu)建各類政務應用系統(tǒng),保障以

該架構(gòu)為標準的各類政務應用通暢運行。該架構(gòu)將成為未來電子政務實施的重要

指導。該架構(gòu)乂稱為“五橫三縱架構(gòu)”。

1.4什么是SOA電子政務總體應用架構(gòu)設(shè)計

SOA電子政務總體應用架構(gòu)設(shè)計就是把各種知識、技能、手段和技術(shù)應用于

架構(gòu)活動中，以達到系統(tǒng)建設(shè)和系統(tǒng)整合的要求。

?架構(gòu)設(shè)計必須權(quán)衡質(zhì)量、時間、范圍和費用等方面的要求。

其中：

質(zhì)量屬性

（按各種角度分類的屬性。

譬如：

[1]按生命周期劃分會有設(shè)計期，開發(fā)期，運（行期，測試期，

維護期質(zhì)量

[2]定量屬性和定性屬性，可用性、可修改性、性能、安全、

有效性、可測試性、可監(jiān)控性、可追溯性、可升級性、可擴張性、可維護性、可管理

非功能.求性、可復用性、模塊獨立交付性等）

約束

卜面介紹幾個通常會在系統(tǒng)設(shè)計中涉及的質(zhì)量屬性。

1.性能

指系統(tǒng)提供的服務要滿足一定的性能衡量標準，這些標準可能包括系統(tǒng)反應時間

以及處理交易量的能力等。

通常可以根據(jù)每個用戶訪問的系統(tǒng)響應時間來衡量系統(tǒng)的整體性能；也可以通

過系統(tǒng)能夠處理的交易量（每秒）來衡量系統(tǒng)的性能。對于架構(gòu)設(shè)計師來說，無論采

取哪種衡量系統(tǒng)性能的方法來構(gòu)建系統(tǒng)架構(gòu)，這些對于性能的考慮對系統(tǒng)設(shè)計開發(fā)人

員來說都應該是透明的，也就是說對于系統(tǒng)整體架構(gòu)性能的考慮應該是架構(gòu)設(shè)計師的

工作，而不是系統(tǒng)設(shè)計開發(fā)人員應該關(guān)注的事情。

在較傳統(tǒng)的基于EJB或者XML-RPC的分布式計算模型中，它們的服務提供都

是通過函數(shù)調(diào)用的方式進行的，一個功能的完成往往需要通過客戶端和服務器來回很

多次的遠程函數(shù)調(diào)用才能完成。在Intranet的環(huán)境下，這些調(diào)用給系統(tǒng)的響應速度和

穩(wěn)定性帶來的影響都可以忽略不計，但如果我們在基于SOA的架構(gòu)中使用了很多Web

Service來作為服務提供點的話，我們就需要考慮性能的影響，尤其是在Internet環(huán)境

下，這些往往是決定整個系統(tǒng)是否能正常工作的一個關(guān)鍵決定因素。因此在基于SOA

的系統(tǒng)中，推薦采用大數(shù)據(jù)量低頻率訪問模式，也就是以大數(shù)據(jù)量的方式一次性進行

信息交換。這樣做可以在一定程度上提高系統(tǒng)的整體性能。

2.可升級性

指當系統(tǒng)負荷加大時，仍能夠確保所需的服務質(zhì)量，而不需要更改整個系統(tǒng)的架

構(gòu)。

當基于SOA的系統(tǒng)中負荷增大時，如果系統(tǒng)的響應時間仍能夠在可接受的限度

內(nèi)，那么我們就可以認為這個系統(tǒng)是具有可升級性的。要想理解可升級性，我們必須

首先了解系統(tǒng)容量或系統(tǒng)的承受能力，也就是一個系統(tǒng)在保證正常運行質(zhì)量的同時，

所能夠處理的最大進程數(shù)量或所能支持的最大用戶數(shù)量。如果系統(tǒng)運轉(zhuǎn)時已經(jīng)不能在

可接受時間范圍內(nèi)反應，那么這個系統(tǒng)已經(jīng)到達了它的最大可升級狀態(tài)。要想升級已

達到最大負載能力的系統(tǒng)，你必須增加新的硬件。新添加的硬件可以以垂直或水平的

方式加入。垂直升級包括為現(xiàn)在的機器增加處理器、內(nèi)存或硬盤。水平升級包括在環(huán)

境中添置新的機器，從而增加系統(tǒng)的整體處理能力。作為一個系統(tǒng)架構(gòu)設(shè)計師所設(shè)計

出來的架構(gòu)必須能夠處理對硬件的垂直或者水平升級。基于SOA的系統(tǒng)架構(gòu)可以很

好地保證整體系統(tǒng)的可升級性，這主要是因為系統(tǒng)中的功能模塊已經(jīng)被抽象成不同的

服務，所有的硬件以及底層平臺的信息都被屏蔽在服務之下，因此不管是對已有系統(tǒng)

的水平升級還是垂直升級，都不會影響到系統(tǒng)整體的架構(gòu)。

3.可靠性

指確保各應用及其相關(guān)的所有交易的完整性和一致性的能力。

當系統(tǒng)負荷增加時，系統(tǒng)必須能夠持續(xù)處理需求訪問，并確保系統(tǒng)能夠象負荷未

增加以前一樣正確地處理各個進程。可靠性可能會在一定程度上限制系統(tǒng)的可升級性。

如果系統(tǒng)負荷增加時，不能維持它的可靠性，那么實際上這個系統(tǒng)也并不具備可升級

性。因此，一個真正可升級的系統(tǒng)必須是可靠的系統(tǒng)。在基于SOA來構(gòu)建系統(tǒng)架構(gòu)

的時候，可靠性也是必須要著重考慮的問題。要在基于SOA架構(gòu)的系統(tǒng)中保證一定

的系統(tǒng)可靠性，就必須要首先保證分布在系統(tǒng)中的不同服務的可靠性。而不同服務的

可靠性一般可以由其部署的應用服務器或Web服務器來保證。只有確保每一個SOA

系統(tǒng)中的服務都具有較高的可靠性，我們才能保證系統(tǒng)整體的可靠性能夠得以保障。

4.可用性

指確保一項服務或者資源應該總是可被訪問到的。

可靠性可以增加系統(tǒng)的整體可用性，但即使系統(tǒng)部件出錯，有時卻并不一定會影

響系統(tǒng)的可用性。通過在環(huán)境中設(shè)置冗余組件和錯誤恢復機制，雖然一個單獨的組件

的錯誤會對系統(tǒng)的可靠性產(chǎn)生不良的影響，但由于系統(tǒng)冗余的存在，使得整個系統(tǒng)服

務仍然可用。在基于SOA來構(gòu)建系統(tǒng)架構(gòu)的時候，對于關(guān)鍵性的服務需要更多地考

慮其可用性需求，這可以由兩個層次的技術(shù)實現(xiàn)來支持，第一種是利用不同服務的具

體內(nèi)部實現(xiàn)內(nèi)部所基于的框架的容錯或者冗余機制來實現(xiàn)對服務可用性的支持;第二

種是通過UDDI等動態(tài)查找匹配方式來支持系統(tǒng)整體的高可用性。在SOA架構(gòu)設(shè)計

師構(gòu)建企業(yè)系統(tǒng)架構(gòu)的時候，應該綜合考慮這兩個方面的內(nèi)容，盡量保證所構(gòu)建的

SOA系統(tǒng)架構(gòu)中的關(guān)鍵性業(yè)務能具有較高的可用性。

5.可擴展性

指在不影響現(xiàn)有系統(tǒng)功能的基礎(chǔ)上，為系統(tǒng)添加新的功能或修改現(xiàn)有功能的能力。

當系統(tǒng)剛配置好的時候，你很難衡量它的可擴展性，直到第一次你必須去擴展系

統(tǒng)已有功能的時候，你才能真正去衡量和檢測整個系統(tǒng)的可擴展性。任何一個架構(gòu)設(shè)

計師在構(gòu)建系統(tǒng)架構(gòu)時，為了確保架構(gòu)設(shè)計的可擴展性，都應該考慮下面幾個要素:低

耦合，界面(mteifaces)以及封裝。當架構(gòu)設(shè)計師基于SOA來構(gòu)建企業(yè)系統(tǒng)架構(gòu)時，就

已經(jīng)隱含地解決了這幾個可擴展性方面的要素。這是因為SOA架構(gòu)中的不同服務之

間本身就保持了一種無依賴的低耦合關(guān)系；服務本身是通過統(tǒng)一的接口定義(可以是

WSDL)語言來描述具體的服務內(nèi)容，并且很好地封裝了底層的具體實現(xiàn)。

6.可維護性

指在不影響系統(tǒng)其他部分的情況下修改現(xiàn)有系統(tǒng)功能中問題或缺陷的能力。

當系統(tǒng)剛被部署時，你很難判斷一個系統(tǒng)是否已經(jīng)具備了很好的可維護性。當創(chuàng)

建和設(shè)計系統(tǒng)架構(gòu)時，要想提高系統(tǒng)的可維護性，你必須考慮下面幾個要素:低耦合、

模塊性以及系統(tǒng)文檔記錄。在企業(yè)系統(tǒng)可擴展性中我們已經(jīng)提到了SOA架構(gòu)能為系

統(tǒng)中暴露出來的各個子功能模塊也就是服務帶來低耦合性和很好的模塊性。關(guān)于系統(tǒng)

文檔紀錄，除了底層子系統(tǒng)的相關(guān)文檔外，基于SOA的系統(tǒng)還會引用到許多系統(tǒng)外

部的由第三方提供的服務，因此如果人力資源準許的話，應該增加專職的文檔管理員

來專門負責有關(guān)整個企業(yè)系統(tǒng)所涉及的所有外部服務相關(guān)文檔的收集、歸類和整理,

這些相關(guān)的文檔可能涉及到第三方服務的接口(可以是WSDL)、服務的質(zhì)量和級別、

具體性能測試結(jié)果等各種相關(guān)文檔。基于這些文檔，就可以為SOA架構(gòu)設(shè)計師構(gòu)建

企業(yè)SOA架構(gòu)提供很好的文檔參考和支持。

7.可管理性

指管理系統(tǒng)以確保整個系統(tǒng)的可升級性、可靠性、可用性、性能和安全性的能力。

具有可管理性的系統(tǒng)，應具備對服務質(zhì)量需求(QoS)的系統(tǒng)監(jiān)控能力，通過改變

系統(tǒng)的配置從而可以動態(tài)地改善服務質(zhì)量，而不用改變整體系統(tǒng)架

構(gòu)。一個好的系統(tǒng)架構(gòu)必須能夠監(jiān)控整個系統(tǒng)的運行情況并具備動態(tài)系統(tǒng)配置管

理的功能。在對復雜系統(tǒng)進行系統(tǒng)架構(gòu)建模時，SOA架構(gòu)設(shè)計師應該盡量考慮利

用將系統(tǒng)整體架構(gòu)構(gòu)建在已有的成熟的底層系統(tǒng)框架(Fiamewoik)_to

8.安全性

指確保系統(tǒng)安全不會被危及的能力。

目前，安全性應該說是最困難的系統(tǒng)質(zhì)量控制點。這是因為安全性不僅要求

確保系統(tǒng)的保密和完整性，而且還要防止影響可用性的服務拒絕(Denial-of-

Service)攻擊。這就要求當SOA架構(gòu)設(shè)計師在構(gòu)建一個架構(gòu)時，應該把整體系統(tǒng)

架構(gòu)盡可能地分割成各個子功能模塊，在將一些子功能模塊暴露為外部用戶可見

的服務的時候，要圍繞各個子模塊構(gòu)建各自的安全區(qū)，這樣更便于保證整體系統(tǒng)

架構(gòu)的安全。如果一個子模塊受到了安全攻擊，也可以保證其他模塊相對安全。

如果企業(yè)SOA架構(gòu)中的一些服務是由WebSemce實現(xiàn)的，在考慮這些服務安全性

的時候也要同時考慮效率的問題，因為WS-Secunty會為WebSeivice帶來一定的

執(zhí)行效率損耗。

?高質(zhì)量的架構(gòu)設(shè)計還考慮了技術(shù)風險應對的因素。

?應對變化，權(quán)衡不變與變化是架構(gòu)設(shè)計永恒的主題。

?架構(gòu)設(shè)計中還必須考慮SOA的獨特性,例如：服務分類方法等。

臼按服務在系統(tǒng)建設(shè)中的用途劃分：

⑵按服務的功能劃分：

1.1服務：數(shù)據(jù)中心的服務和邏輯中心的服務

1.2服務：技術(shù)網(wǎng)關(guān)、適配器、外觀、裝飾服務

1.3程為中心的服務

1.4企業(yè)服務：為跨企業(yè)集成提供接口，例如SMS、Email等員外應

用程序前端是SON的激活元素。

1.5本指南的章節(jié)組織

主要分4章介紹。

第1章引論

第2章應用架構(gòu)設(shè)計知識領(lǐng)域、設(shè)計原則和過程組

第3章應用架構(gòu)分解結(jié)構(gòu)

第4章應用架構(gòu)設(shè)計路線圖

1.6應用架構(gòu)設(shè)計的主要內(nèi)容

依據(jù)SOA-RA-TF的參考架構(gòu)，解決電子政務應用領(lǐng)域如何產(chǎn)出一個SOA應用

架構(gòu)的問題：

?架構(gòu)的生命期構(gòu)成

?整體架構(gòu)設(shè)計過程組

-架構(gòu)分解結(jié)構(gòu)（五橫三縱架構(gòu)）

?知識領(lǐng)域:服務參考模型

-架構(gòu)側(cè)面系（生命周期模型和4+1視圖）

1.7應用架構(gòu)分解結(jié)構(gòu)與參考架構(gòu)（RA）

應用架構(gòu)分解結(jié)構(gòu)中的基礎(chǔ)支撐層中的系統(tǒng)軟件盡量按照RA標準實現(xiàn)，如不能

滿足，架構(gòu)上應考慮松耦合的互連互通，保障符合RA標準的服務庫和應用系統(tǒng)能夠

和本應用架構(gòu)協(xié)同。

另外RA為應用架構(gòu)分解結(jié)構(gòu)中的服務開發(fā)運行體系提供支撐機制，如ESB

等。

1.8應用架構(gòu)設(shè)計環(huán)境

本指南假定架構(gòu)設(shè)計在項目環(huán)境下進行。

應用架構(gòu)設(shè)計受到一定環(huán)境因素的影響和約束，并反過來對這些因素產(chǎn)生影響:

?應用領(lǐng)域標準規(guī)范

?組織過程資產(chǎn)

?公司戰(zhàn)略要求

?技術(shù)環(huán)境

?項目要求

?管理因素

架構(gòu)設(shè)計和項目管理和組織日常運作管理是密切相關(guān)的，但本指南不涉及相關(guān)

內(nèi)容，請參考相關(guān)書籍和文獻資料。

1.9應用架構(gòu)設(shè)計干系人

架構(gòu)設(shè)計要考慮架構(gòu)設(shè)計干系人的要求。

?高層管理人員

?項目發(fā)起人

?項目經(jīng)理

?架構(gòu)設(shè)計師

?需求人員

?開發(fā)人員

?測試人員

?客戶

1.10應用架構(gòu)設(shè)計指南與長風聯(lián)盟其他文檔的關(guān)系

第二章應用架構(gòu)設(shè)計知識領(lǐng)域、原則和過

程組

2.1應用架構(gòu)設(shè)計知識領(lǐng)域

2.1.1SOA設(shè)計方法學

SOA設(shè)計方法并非全新的方法論，而是繼承了傳統(tǒng)的面向?qū)ο蟮脑O(shè)計方法以及

面向過程的設(shè)計方法，同時乂增加了SCA,,SDO,BPEL等技術(shù)，融入了面向服務的

設(shè)計方法，服務參考模型OASISRM里的內(nèi)容映射，具體內(nèi)容包括服務定義、服務設(shè)

計、服務管理、服務開發(fā)、服務測試和服務部署。

2.1.2數(shù)據(jù)建模方法學

傳統(tǒng)的數(shù)據(jù)建模方法學是面向一個應用系統(tǒng)內(nèi)部的實體的建模方法學，而在當前

數(shù)據(jù)整合、應用整合的需求下,數(shù)據(jù)建模還要考慮在不同系統(tǒng)間進行數(shù)據(jù)交換和數(shù)據(jù)

共享的需求。基于業(yè)務效率的考慮，從業(yè)務流程出發(fā)的思路改變了數(shù)據(jù)

模型。只有你從業(yè)務流程的角度來看待數(shù)據(jù)的時候，數(shù)據(jù)模型才能算真正完成。

2.1.3面向流程設(shè)計方法學

闡述了一種以實現(xiàn)流程優(yōu)化的流程系統(tǒng)設(shè)計思想。這種設(shè)計思想是面向業(yè)務流程

的，不同于傳統(tǒng)MIS系統(tǒng)面向部門職能的設(shè)計思想。首先把系統(tǒng)設(shè)計區(qū)分為原理層設(shè)

計和技術(shù)層設(shè)計兩個層次，然后從業(yè)務流程設(shè)計、數(shù)據(jù)模型設(shè)計和技術(shù)架構(gòu)設(shè)計三個

方面論述了原理層設(shè)計的基本思想。

2.1.4技術(shù)領(lǐng)域架構(gòu)設(shè)計方法學

大型IT系統(tǒng)的設(shè)計通常遵循七層架構(gòu)的設(shè)計方法，包括：

界面層

該層是直接面向用戶（包括公眾、企業(yè)、業(yè)務人員、行政管理人員、領(lǐng)導等使

用者）的統(tǒng)一的系統(tǒng)界面。界面層利用業(yè)界主流的IT技術(shù)支持多種渠道接入和交互

（如互聯(lián)網(wǎng)、電話、手機短信等接入方式），以及統(tǒng)一的身份認證及權(quán)限管理。

應用層

應用層提供所有的信息應用和系統(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ù)的保存及歸檔等。

應用支撐層

應用支撐層構(gòu)建在J2EE應用服務器之上，提供了一個應用基礎(chǔ)平臺

DC-BPIP,并提供大量公共服務和業(yè)務構(gòu)件，提供構(gòu)件的運行、開發(fā)和管理環(huán)境，最大

限度提高開發(fā)效率，降低工程實施、維護的成本和風險。應用支撐層采用了行業(yè)應用

的先進體系結(jié)構(gòu)，以建立高性能、高可靠性、高擴展性的應用系統(tǒng)，滿足客戶快速發(fā)

展的業(yè)務需求。

信息資源層

信息資源層是整個系統(tǒng)的信息資源中心，涵蓋全市所有與行政審批相關(guān)的結(jié)構(gòu)

化和非結(jié)構(gòu)化數(shù)據(jù)。它是企業(yè)信息資源的存儲和積累，為系統(tǒng)應用提供數(shù)據(jù)訪問服

務、備份、存儲功能。

IT基礎(chǔ)平臺層

IT基礎(chǔ)平臺為系統(tǒng)的軟硬件以及網(wǎng)絡基礎(chǔ)平臺，分為三個部分：系統(tǒng)軟件、硬件

支撐平臺、和網(wǎng)絡支撐平臺。其中，系統(tǒng)軟件包括中間件、數(shù)據(jù)庫服務器軟件等；硬

件支撐平臺包括：主機、存儲、備份等硬件設(shè)備；網(wǎng)絡支撐為系統(tǒng)運行所依賴的網(wǎng)絡

環(huán)境。它對上層應用起到技術(shù)支撐作用支撐體系層

系統(tǒng)建設(shè)和推廣運行僅僅依賴應用系統(tǒng)建設(shè)、硬件網(wǎng)絡建設(shè)是不夠的，需要在系

統(tǒng)安全方面、標準化方面、以及系統(tǒng)運維三個不同層面的工作來共同支撐。只有這樣，

才能使系統(tǒng)建設(shè)順利進行，也才能保證系統(tǒng)能順利推廣、穩(wěn)定運行。法律法規(guī)層

以上各個層面的建設(shè)，需要依托于現(xiàn)有的法律、法規(guī)及一些規(guī)范才可成功運行。

系統(tǒng)的分析、設(shè)計、實施都必須充分考慮這些因素。只有切實符合這些規(guī)范，系統(tǒng)才能

與建設(shè)單位共同發(fā)展，得到各級用戶的認可。

而利用RUP的設(shè)計思想，則將架構(gòu)設(shè)計概括為4+1視圖：

邏輯視圖邏輯視圖關(guān)注功能，不僅包括用戶可見的功能，還包括為實現(xiàn)用戶功能

而必須提供的”輔助功能模塊”；它們可能是邏輯層、功能模塊等。開發(fā)視圖。

開發(fā)視圖關(guān)注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方

SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于其上的系統(tǒng)軟件或中間件。開

發(fā)視圖和邏輯視圖之間可能存在一定的映射關(guān)系：比如邏輯層一般會映射到多個

程序包等。

處理視圖。處理視圖關(guān)注進程、線程、對象等運行時概念，以及相關(guān)的并發(fā)、同

步、通信等問題。處理視圖和開發(fā)視圖的關(guān)系：開發(fā)視圖一般偏重程序包在編譯時期

的靜態(tài)依賴關(guān)系，而這些程序運行起來之后會表現(xiàn)為對象、線程、進程，處理視圖比

較關(guān)注的正是這些運行時單元的交互問題。

物理視圖。物理視圖關(guān)注”目標程序及其依賴的運行庫和系統(tǒng)軟件”最終如何安

裝或部署到物理機器，以及如何部署機器和網(wǎng)絡來配合軟件系統(tǒng)的可靠性、可伸

縮性等要求。物理視圖和處理視圖的關(guān)系：處理視圖特別關(guān)注目標程序的動態(tài)執(zhí)

行情況，而物理視圖重視目標程序的靜態(tài)位置問題；物理視圖是綜合考慮軟件系

統(tǒng)和整個IT系統(tǒng)相互影響的架構(gòu)視圖。

場景視圖。關(guān)注業(yè)務的應用場景。

2.1.5通用架構(gòu)設(shè)計方法學

架構(gòu)設(shè)計是一種權(quán)衡("ade-off)。一個問題總是有多種的解決方案。而我們要

確定唯一的架構(gòu)設(shè)計的解決方案，就意味著我們要在不同的矛盾體之間做出一個

權(quán)衡。我們在設(shè)計的過程總是可以看到很多的矛盾體：開放和整合，一致性和特

殊化，穩(wěn)定性和延展性等等。任何一對矛盾體都源于我們對軟件的不同期望。可

是，要滿足我們希望軟件穩(wěn)定運行的要求，就必然會影響我們對軟件易于擴展的

期望。我們希望軟件簡單明了，卻增加了我們設(shè)計的復雜度。沒有一個軟件能夠

滿足所有的要求，因為這些要求之間帶有天生的互斥性。而我們評價架構(gòu)設(shè)計的

好壞的依據(jù)，就只能是根據(jù)不同要求的輕重緩急，在其間做出權(quán)衡的合理性。

目標

我們希望一個好的架構(gòu)能夠：

重用：為了避免重復勞動，為了降低成本，我們希望能夠重用之前的代碼、之前

的設(shè)計。重用是我們不斷追求的目標之一，但事實上，做到這一點可沒有那么容易。

在現(xiàn)實中，人們已經(jīng)在架構(gòu)重用上做了很多的工作，工作的成果稱為框架(Framework),

比如說Windows的窗口機制、J2EE平臺等。但是在企業(yè)商業(yè)建模方面，有效的框架

還非常的少。

透明：有些時候，我們?yōu)榱颂岣咝剩褜崿F(xiàn)的細節(jié)隱藏起來，僅把客戶需求的

接口呈現(xiàn)給客戶。這樣，具體的實現(xiàn)對客戶來說就是透明的。一個具體的例子是我們

使用JSP的tag技術(shù)來代替JSP的嵌入代碼，因為我們的HTML界面人員更熟悉tag

的方式。

延展：我們對延展的渴求源于需求的易變。因此我們需要架構(gòu)具有一定的延展性，

以適應未來可能的變化。可是，如上所說，延展性和穩(wěn)定性，延展性和簡單性都是矛

盾的。因此我們需要權(quán)衡我們的投入/產(chǎn)出比。以設(shè)計出具有適當和延展性的架構(gòu)。

簡明：一個復雜的架構(gòu)不論是測試還是維護都是困難的。我們希望架構(gòu)能夠在滿

足目的的情況下盡可能的簡單明了。但是簡單明了的含義究竟是什么好像并沒有一個

明確的定義。使用模式能夠使設(shè)計變得簡單，但這是建立在我熟悉設(shè)計模式的基礎(chǔ)上。

對于一個并不懂設(shè)計模式的人，他會認為這個架構(gòu)很復雜。對于這種情況，我只能對

他說，去看看設(shè)計模式。

高效：不論是什么系統(tǒng)，我們都希望架構(gòu)是高效的。這一點對于一些特定的系統(tǒng)

來說尤其重要。例如實時系統(tǒng)、高訪問量的網(wǎng)站。這些值的是技術(shù)上的高效，有時候我

們指的高效是效益上的高效。例如，一個只有幾十到一百訪問量的信息系統(tǒng)，是不是

有必要使用EJB技術(shù)，這就需要我們綜合的評估效益了。

安全：安全并不是我們文章討論的重點，卻是架構(gòu)的一個很重要的方面。規(guī)則

為了達到上述的目的，我們通常需要對架構(gòu)設(shè)計制定一些簡單的規(guī)則：

功能分解

顧名思義，就是把功能分解開來。為什么呢？我們之所以很難達到重用目標就是

因為我們編寫的程序經(jīng)常處于一種好像是重復的功能，但乂有輕微差別的狀態(tài)中。我

們很多時候就會經(jīng)不住誘惑，用拷貝粘貼再做少量修改的方式完成一個功能。這種行

為在XP中是堅決不被允許的。XP提倡“Onceandonlyonce”,目的就是為了杜絕這種

拷貝修改的現(xiàn)象。為了做到這一點，我們通常要把功能分解到細粒度。很多的設(shè)計思

想都提倡小類，為的就是這個目的。

所以，我們的程序中的類和方法的數(shù)目就會大大增長，而每個類和方法的平均代

碼卻會大大的下降。可是，我們怎么知道這個度應該要如何把握呢，關(guān)于這個疑問，

并沒有明確的答案，要看個人的功力和具體的要求，但是一般來說，我們可以用一個

簡單的動詞短語來命名類或方法的，那就會是比較好的分類方法。

我們使用功能分解的規(guī)則，有助于提高重用性，因為我們每個類和方法的精度都

提高了。這是符合大自然的原則的，我們研究自然的主要的一個方向就是將物質(zhì)分解。

我們的思路同樣可以應用在軟件開發(fā)上。除了重用性，功能分解還能實現(xiàn)透明的目標，

因為我們使用了功能分解的規(guī)則之后，每個類都有自己的單獨功能，這樣，我們對一

個類的研究就可以集中在這個類本身，而不用牽涉到過多的類。

根據(jù)實際情況決定不同類間的耦合度

雖然我們總是希望類間的耦合度比較低，但是我們必須客觀的評價耦合度。系統(tǒng)

之間不可能總是松耦合的，那樣肯定什么也做不了。而我們決定耦合的程度的依據(jù)何

在呢？簡單的說，就是根據(jù)需求的穩(wěn)定性，來決定耦合的程度。對于穩(wěn)定性高的需求，

不容易發(fā)生變化的需求，我們完全可以把各類設(shè)計成緊耦合的（我們雖然討論類之間

的耦合度，但其實功能塊、模塊、包之間的耦合度也是一樣的），因為這樣可以提高效

率，而且我們還可以使用一些更好的技術(shù)來提高效率或簡化代碼，例如Java中的內(nèi)部

類技術(shù)。可是，如果需求極有可能變化，我們就需要充分的考慮類之間的耦合問題,

我們可以想出各種各樣的辦法來降低耦合程度，但是歸納起來，不外乎增加抽象的層

次來隔離不同的類，這個抽象層次可以是具體的類，也可以是接口，或是一組的類（例

如Beans）。我們可以借用Java中的一句話來概括降低耦合度的思想：”針對接口編

程，而不是針對實現(xiàn)編程。

設(shè)計不同的耦合度有利于實現(xiàn)透明和延展。對于類的客戶（調(diào)用者）來說，他不

需要知道過多的細節(jié)（實現(xiàn)），他只關(guān)心他感興趣的（接口）。這樣，目標類對客戶

來說就是一個黑盒子。如果接口是穩(wěn)定的，那么，實現(xiàn)再怎么擴展，對客戶來說也不

會有很大的影響。以前那種牽一發(fā)而動全身的問題完全可以緩解共至避免。

其實，我們仔細的觀察GOF的23種設(shè)計模式，沒有一種模式的思路不是從增加

抽象層次入手來解決問題的。同樣，我們?nèi)ビ^察Java源碼的時候，我們也可以發(fā)現(xiàn),

Java源碼中存在著大量的抽象層次，初看之下，它們什么都不干，但是它們對系統(tǒng)的

設(shè)計起著重大的作用。

夠用就好

我們在上一章中就談過敏捷方法很看重剛好夠用的問題，現(xiàn)在我們結(jié)合架構(gòu)設(shè)計

來看：在同樣都能夠滿足需要的情況下，一項復雜的設(shè)計和一項簡單的設(shè)計，哪一個

更好。從敏捷的觀點來看，一定是后者。因為目前的需求只有10項，而你的設(shè)計能夠

滿足100項的需求，只能說這是種浪費。你在設(shè)計時完全沒有考慮成本問題，不考慮

成本問題，你就是對開發(fā)組織的不負責，對客戶的不負責。

應用模式

這篇文章的寫作思路很多來源于對模式的研究。因此，文章中到處都可以看到模

式思想的影子。模式是一種整理、傳播思想的非常優(yōu)秀的途徑，我們可以通過模式的

方式學習他人的經(jīng)驗。一個好的模式代表了某個問題研究的成果，因此我們把模式應

用在架構(gòu)設(shè)計上，能夠大大增強架構(gòu)的穩(wěn)定性。

抽象

架構(gòu)的本質(zhì)在于其抽象性。它包括兩個方面的抽象：業(yè)務抽象和技術(shù)抽象。架構(gòu)

是現(xiàn)實世界的一個模型，所以我們首先需要對現(xiàn)實世界有一個很深的了解，然后我們

還要能夠熟練的應用技術(shù)來實現(xiàn)現(xiàn)實世界到模型的映射。因此，我們在對業(yè)務或技術(shù)

理解不夠深入的情況下，就很難設(shè)計出好的架構(gòu)。當然，這時候我們發(fā)現(xiàn)一個問題:

怎樣才能算是理解足夠深入呢。我認為這沒有一個絕對的準則。

一次，一位朋友問我：他現(xiàn)在做的系統(tǒng)有很大的變化，原先設(shè)計的工作流架構(gòu)不

能滿足現(xiàn)在的要求。他很希望能夠設(shè)計出足夠好的工作流架構(gòu)，以適應不同的變化。

但是他發(fā)現(xiàn)這樣做無異于重新開發(fā)一個lotusnotes。我聽了他的疑問之后覺得有兩點

問題：

首先，他的開發(fā)團隊中并沒有工作流領(lǐng)域的專家。他的客戶雖然了解自己的工作

流程，但是缺乏足夠的理論知識把工作流提到抽象的地步。顯然，他本身雖然有技術(shù)

方面的才能，但就工作流業(yè)務本身，他也沒有足夠的經(jīng)驗。所以，設(shè)計出象notes那

樣的系統(tǒng)的前提條件并不存在。

其次，開發(fā)一個工作流系統(tǒng)的目的是什么。原先的工作流系統(tǒng)運作的不好，其原

因是有變化發(fā)生。因此才有改進工作流系統(tǒng)的動機出現(xiàn)。可是，畢竟notes是為了滿足

世界上所有的工作流系統(tǒng)而開發(fā)的，他目前的應用肯定達不到這個層次。

因此，雖然做不到最優(yōu)的業(yè)務抽象，但是我們完全可以在特定目的下，特定范圍

內(nèi)做到最優(yōu)的業(yè)務抽象。比如說，我們工作流可能的變化是工組流路徑的變化。我們

就完全可以把工作流的路徑做一個抽象，設(shè)計一個可以動態(tài)改變路徑的工作流架構(gòu)。

有些時候，我們雖然在技術(shù)上和業(yè)務上都有所欠缺，沒有辦法設(shè)計出好的架構(gòu)。

但是我們完全可以借鑒他人的經(jīng)驗，看看類似的問題別人是如何解決的。這就是我們

前面提到的模式。我們不要把模式看成是一個硬性的解決方法，它只是一種解決問題

的思路。MartinFowlei-曾說：“模式和業(yè)務組件的區(qū)別就在于模式會引發(fā)你的思考。”

在《分析模式》一書中，MaihnFowle［提到了分析和設(shè)計的區(qū)別。分析并不僅僅

只是用用例列出所有的需求，分析還應該深入到表面需求的的背后，以得到關(guān)于問題

本質(zhì)的MentalModel。然后，他引出了概念模型的概念。概念模型就類似于我們在討

論的抽象。MartinFowle［提到了一個有趣的例子，如果要開發(fā)一套軟件來模擬桌球游

戲，那么，用用例來描述各種的需求，可能會導致大量的運動軌跡的出現(xiàn)。如果你沒

有了解表面現(xiàn)象之后隱藏的運動定律的本質(zhì)，你可能永遠無法開發(fā)出這樣一個系統(tǒng)。

關(guān)于架構(gòu)和抽象的問題，在后面的文章中有一個測量模式的案例可以很形象的說

明這個問題。

架構(gòu)的一些誤解

我們花了一些篇幅來介紹架構(gòu)的一些知識。現(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)目標

的架構(gòu)。

誤解2：架構(gòu)由專門的設(shè)計師來設(shè)計，設(shè)計出的藍圖交由程序員來實現(xiàn)。我們之

所以會認為架構(gòu)是設(shè)計師的工作，是因為我們喜歡把軟件開發(fā)和建筑工程做類比。但

是，這兩者實際上是有著很大的區(qū)別的。關(guān)鍵之處在于，建筑設(shè)計已經(jīng)有很長的歷史，

已經(jīng)發(fā)展出完善的理論，可以通過某些理論（如力學原理）來驗證設(shè)計藍圖。可是,

對軟件開發(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)于需求的細節(jié)討論，請參看拙作『需求的實踐」）。這樣做的壞處是，我們一開

始就限制了整個的軟件的形狀。而到實現(xiàn)時，我們雖然發(fā)現(xiàn)原來的設(shè)計有失誤之處,

但卻不愿意面對現(xiàn)實。這使得軟件畸形的生長。原本一些簡單的問題，卻因為別扭的

架構(gòu)，變得非常的復雜。這種例子我們經(jīng)常可以看到，例如為兼容前個版本而導致的

軟件復雜性。而2000年問題，TCP/IP網(wǎng)絡的安全性問題也從一個側(cè)面反映了這個問

題的嚴重性。

誤解4：架構(gòu)藍圖交給程序員之后，架構(gòu)設(shè)計師的任務就完成了。和誤解2一樣，

我們借鑒了建筑工程的經(jīng)驗。我們看到建筑設(shè)計師把設(shè)計好的藍圖交給施工人員，施

工人員就會按照圖紙建造出和圖紙一模一樣的大廈。于是，我們也企圖在軟件開發(fā)中

使用這種模式。這是非常要命的。軟件開發(fā)中缺乏一種通用的語言，能夠充分的消除

設(shè)計師和程序員的溝通隔閡。有人說，UML不可以嗎？UML的設(shè)計理念是好的，可

以減輕溝通障礙問題。可是要想完全解決這個問題，UML還做不到。首先，程序員都

具有個性化的思維，他會以自己的思維方式去理解設(shè)計，因為從設(shè)計到實現(xiàn)并不是一

項機械的勞動，還是屬于一項知識性的勞動(這和施工人員的工作是不同的)。此外，

對于程序員來說，他還極有可能按照自己的想法對設(shè)計圖進行一定的修改，這是非常

正常的一項舉動。更糟的是，程序員往往都比較自負，他們會潛意識的排斥那些未經(jīng)

過自己認同的設(shè)計。

架構(gòu)設(shè)計的過程模式

通常我們認為模式都是用在軟件開發(fā)、架構(gòu)設(shè)計上的。其實，這只是模式的一個

方面。模式的定義告訴我們，模式描述了一個特定環(huán)境的解決方法，這個特定環(huán)境往

往重復出現(xiàn)，制定出一個較好的解決方法有利于我們在未來能有效的解決類似的問題。

其實，在管理學上，也存在這種類似的這種思維。稱為結(jié)構(gòu)性問題的程序化解決方法。

所以呢，我們完全可以把模式的思想用在其它的方面，而目前最佳的運用就是過程模

式和組織模式。在我們的文章中，我們僅限于討論過程模式。

我們討論的過程僅限于面向?qū)ο蟮能浖_發(fā)過程。我們稱之為OOSP(object-

onentedsoftwarepiocess)o因為我們的過程需要面向?qū)ο筇匦缘闹С帧．斎唬覀兊暮?/p>

多做法一樣可以用在非00的開發(fā)過程中，但是為了達到最佳的效果，我建議您使用

00技術(shù)。

2.1.6面向?qū)ο笤O(shè)計方法學

面向?qū)ο蠓椒?Object-OnentedMethod)是一種把面向?qū)ο蟮乃枷霊糜谲?/p>

件開發(fā)過程中，指導開發(fā)活動的系統(tǒng)方法，簡稱00(0bject-0口ented)方法，是

建立在“對象”概念基礎(chǔ)上的方法學。對象是由數(shù)據(jù)和容許的操作組成的封裝體,

與客觀實體有直接對應關(guān)系，一個對象類定義了具有相似性質(zhì)的一組對象。而每

繼承性是對具有層次關(guān)系的類的屬性和操作進行共享的一種方式。所謂面向?qū)ο?/p>

就是基于對象概念，以對象為中心，以類和繼承為構(gòu)造機制，來認識、理解、刻

畫客觀世界和設(shè)計、構(gòu)建相應的軟件系統(tǒng)。

面向?qū)ο蠓椒ㄗ鳛橐环N新型的獨具優(yōu)越性的新方法正引起全世界越來越廣泛

的關(guān)注和高度的重視，它被譽為”研究高技術(shù)的好方法”，更是當前計算機界關(guān)

心的重點。十多年來，在對00方法如火如荼的研究熱潮中，許多專家和學者預

言：正像70年代結(jié)構(gòu)化方法對計算機技術(shù)應用所產(chǎn)生的巨大影響和促進那樣，90

年代00方法會強烈地影響、推動和促進一系列高技術(shù)的發(fā)展和多學科的綜合。

用計算機解決問題需要用程序設(shè)計語言對問題求解加以描述（即編程），實質(zhì)

上，軟件是問題求解的一種表述形式。顯然，假如軟件能直接表現(xiàn)人求解問題的

思維路徑（即求解問題的方法），那么軟件不僅容易被人理解，而且易于維護和修

改，從而會保證軟件的可靠性和可維護性，并能提高公共問題域中的軟件模塊和

模塊重用的可靠性。面向?qū)ο蟮臋C能念和機制恰好可以使得按照人們通常的思維

方式來建立問題域的模型，設(shè)計出盡可能自然地表現(xiàn)求解方法的軟件。

面向?qū)ο蟮幕靖拍睿?/p>

對象：對象是要研究的任何事物。從一本書到一家圖書館，單的整數(shù)到整數(shù)

列龐大的數(shù)據(jù)庫、極其復雜的自動化工廠、航天飛機都可看作對象，它不僅能表

示有形的實體，也能表示無形的（抽象的）規(guī)則、計劃或事件。對象由數(shù)據(jù)（描

述事物的屬性）和作用于數(shù)據(jù)的操作（體現(xiàn)事物的行為）構(gòu)成一獨立整體。從程

序設(shè)計者來看，對象是一個程序模塊，從用戶來看，對象為他們提供所希望的行

為。在對內(nèi)的操作通常稱為方法。

類：類是對象的模板。即類是對一組有相同數(shù)據(jù)和相同操作的對象的定義,

一個類所包含的方法和數(shù)據(jù)描述一組對象的共同屬性和行為。類是在對象之上的

抽象，對象則是類的具體化，是類的實例。類可有其子類，也可有其它類，形成

類層次結(jié)構(gòu)。

消息：消息是對象之間進行通信的一種規(guī)格說明。一般它由三部分組成：接

收消息的對象、消息名及實際變元。

面向?qū)ο笾饕卣鳎?/p>

封裝性：封裝是一種信息隱蔽技術(shù)，它體現(xiàn)于類的說明，是對象的重要特性。

封裝使數(shù)據(jù)和加工該數(shù)據(jù)的方法（函數(shù)）封裝為一個整體，以實現(xiàn)獨立性很強的

模塊，使得用戶只能見到對象的外特性（對象能接受哪些消息，具有那些處理能

力），而對象的內(nèi)特性（保存內(nèi)部狀態(tài)的私有數(shù)據(jù)和實現(xiàn)加工能力的算法）對用

戶是隱蔽的。封裝的目的在于把對象的設(shè)計者和對象者的使用分開，使用者不必

知曉行為實現(xiàn)的細節(jié)，只須用設(shè)計者提供的消息來訪問該對象。

繼承性：繼承性是子類自動共享父類之間數(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é)都留給接受消息的對象自行決定，如是，同一消息

即可調(diào)用不同的方法。例如：Punt消息被發(fā)送給一圖或表時調(diào)用的打印方法與將

同樣的Print消息發(fā)送給一正文文件而調(diào)用的打印方法會完全不同。多態(tài)性的實

現(xiàn)受到繼承性的支持，利用類繼承的層次關(guān)系，把具有通用功能的協(xié)議存放在類

層次中盡可能高的地方，而將實現(xiàn)這一功能的不同方法置于較低層次，這樣，在

這些低層次上生成的對象就能給通用消息以不同的響應。在OOPL中可通過在派

生類中重定義基類函數(shù)（定義為重載函數(shù)或虛函數(shù)）來實現(xiàn)多態(tài)性。

綜上可知，在00方法中，對象和傳遞消息分別表現(xiàn)事物及事物間相互聯(lián)系

的概念。類和繼承是是適應人們一般思維方式的描述范式。方法是允許作用于該

類對象上的各種操作。這種對象、類、消息和方法的程序設(shè)計范式的基本點在于

對象的封裝性和類的繼承性。通過封裝能將對象的定義和對象的實現(xiàn)分開，通過

繼承能體現(xiàn)類與類之間的關(guān)系，以及由此帶來的動態(tài)聯(lián)編和實體的多態(tài)性，從而

構(gòu)成了面向?qū)ο蟮幕咎卣鳌?/p>

2.2服務設(shè)計原則

2.2.1顯式定義邊界

通過跨越定義明確的邊界進行顯式消息傳遞，服務得以彼此交互。有時候,

跨越服務邊界可能要耗費很大的成本，這要視地理、信任或執(zhí)行因素而定。邊界

是指服務的公共接口與其內(nèi)部專用實現(xiàn)之間的界線。服務的邊界通過WSDL發(fā)

布，可能包括說明特定服務之期望的聲明。跨越邊界的代價是高吊的因為：

目標服務的物理位置可能是未知的因素。

安全和信任模型可能會在每次跨越邊界時發(fā)生改變。

在服務的公共表示和專用表示之間封送和轉(zhuǎn)換數(shù)據(jù)可能需要依賴額外的資

源：其中一些資源可能在服務之外。

服務的構(gòu)建要考量持久性，而服務配置的構(gòu)建則要考量變化性。這一事實暗

示著：由于網(wǎng)絡重新配置或者遷移到另一個物理位置，可靠的服務的性能可能會

突然降低。

服務的使用者通常不知道專用的內(nèi)部過程是如何實現(xiàn)的。特定服務的使

用者對正使用的服務的性能只能進行有限的控制。

服務調(diào)用可能會受到網(wǎng)絡滯后、網(wǎng)絡故障和分布式系統(tǒng)故障的影響，而本地

實現(xiàn)則不會。要預先考慮使用遠程對象接口的影響，就必須編寫大量的錯誤檢測

和更正邏輯。盡管跨越邊界是代價高昂的過程，但在部署用于將此類邊界跨越減

至最少的本地方法時，還是要格外謹慎。實現(xiàn)單一性本地方法和對象的系統(tǒng)可能

會獲得性能的改善，但功能性卻與先前定義的服務完全一樣。

?弄清邊界。服務提供一個契約來定義其提供的公共接口。與服務的所有

交互都通過公共接口進行。接口由公共進程和公共數(shù)據(jù)表示組成。公共進程是通

向服務內(nèi)部的入口點，而公共數(shù)據(jù)表示則是指該進程使用的消息。如果我們使用

WSDL代表一個簡單的契約，則＜message〉代表公共數(shù)據(jù)，而vportType〉代表

公共進程。文章”外部數(shù)據(jù)與內(nèi)部數(shù)據(jù)”（英文）更詳細地研究了這些問題。

?服務應易于使用。設(shè)計服務時，開發(fā)人員應使其易于其他開發(fā)人員使用。

設(shè)計的服務接口（契約）也應允許服務在不中斷與現(xiàn)有使用者之間的契約的情況

下進一步發(fā)展。（這一主題將在本系列的后續(xù)文章中更詳細地討論。）

?避免使用RPC接口。應采用顯式消息傳遞，而避免使用RPC之類的模

型。這種方法將使用者與服務實現(xiàn)的內(nèi)部隔離開來，使開發(fā)人員可以集中精力改

進他們的服務，同時將對服務使用者的影響降至最低（使用公共消息而不是公用

的方法進行封裝）。

?盡量減小服務的表面積。服務的公共接口越多，就越難以使用和維護。

應當少提供服務的定義明確的公共接口。這些接口應該相對簡單，主要用于接受

定義明確的輸入消息并以同樣定義明確的輸出消息進行響應。這些接口一旦定義,

即應保持不變。這些接口提供服務必須支持的“恒定不變”的設(shè)計要求，為服務

專用的內(nèi)部實現(xiàn)充當門面。

?內(nèi)部（專用）實現(xiàn)的細節(jié)不應泄露到服務邊界之外。如果將實現(xiàn)細節(jié)泄

露到服務邊界，很可能會使服務與服務使用者之間的耦合更加緊密。服務使用者

不應當獲知服務實現(xiàn)的內(nèi)部情況，因為這樣會使服務的版本更新或升級受到限制。

2.2.2自治性

服務是獨立進行部署、版本控制和管理的實體。開發(fā)人員應避免對服務邊界

之間的空間進行假設(shè)，因為此空間比邊界本身更容易改變。例如，服務邊界應當

是不變的，只有這樣才能將版本更新對使用者的影響降至最低。雖然服務邊界是

相當穩(wěn)定的，但策略、物理位置或網(wǎng)絡拓撲等服務部署選項卻很可能發(fā)生改變。

服務可以通過URI