基本信息
原書名： Pattern-Oriented software architecture Volume 4: A Pattern Language for Distributed Computing
原出版社： Wiley
作者： (德)Frank Buschmann (英) Kevlin Henney (美)Douglas C. Schmidt
譯者： 肖鵬 陳立
叢書名： 圖靈程式設計叢書 軟體工程系列
出版社：人民郵電出版社
ISBN：9787115227737
上架時間：2010-6-28
出版日期：2010 年6月
開本：16開
頁碼：348
版次：1-1
內容簡介
本書關注分散式計算系統軟體的設計和實現。書中首先介紹理解本書內容所需的核心的模式概念，分散式計算的好處和挑戰；然後描述如何使用分散式計算模式語言，設計真實世界中倉庫管理流程控制系統；最後重點講述分散式計算模式語言，該語言陳述了創建分散式系統相關的技術主題。
本書適用於軟體架構師和開發人員。
編輯推薦
《面向模式的軟體架構:分散式計算的模式語言(卷4)》：迄今為止，人們提出的軟體開發模式有不少是關於分散式計算的，但人們始終無法以完整的視角了解分散式計算中各種模式是如何協同工作、取長補短的。構建複雜的分散式系統似乎成為了永遠也無法精通的一門手藝。《面向模式的軟體架構:分散式計算的模式語言(卷4)》的出版改變了這一切。
《面向模式的軟體架構:分散式計算的模式語言(卷4)》是經典的POSA系列的第4卷。介紹了一種模式設計語言。將分散式系統開發中的114個模式聯繫起來。書中首先介紹了一些分散式系統和模式語言的概念。然後通過一個倉庫管理流程控制系統的例子，介紹如何使用模式語言設計分散式系統，最後介紹模式語言本身。
使用這一模式語言，人們可以有效地解決許多與分散式系統開發相關的技術問題。如
·對象互動
·接口與組件劃分
·套用控制
·資源管理
·並發與同步
《面向模式的軟體架構:分散式計算的模式語言(卷4)》從實用角度展示了如何從現有的主要模式中整合出一門全面的模式語言，用於開發分散式計算中間件及應用程式。作為該領域在市場上唯一統攬全局的書，它將給讀者帶來醍醐灌頂的感覺！
媒體推薦
“作者很明智，在書中融入了實際案例。有了它，模式就不再是空中樓閣，模式語言的具體套用一目了然。”
——《計算機評論》
“關於架構和設計模式的書我有很多，不過一旦遇到問題，我首先求助的永遠都是這一本。”
——Dennis L. Hughes，Windows架構師
“這是用於分散式計算的模式聖經！值得每一位軟體架構師珍藏！”
——Amazon . com
作者簡介
作者：（德國）布施曼（Frank Buschmann） （英國）亨尼（Kevlin Henney） （美國）施密特（Douglas C.Schmidt） 譯者：肖鵬 陳立
布施曼（Frank Buschmann），是德國慕尼黑西門子公司總部技術部門的高級工程師。他的研究興趣包括對象技術、軟體體系結構、框架和模式。他在這些領域發表了很多文章，這些文章可以在他與人合著的POSA第1卷中找到。Frank於1992～1996年期間是ANSI C++標準化委員會X3J16的成員。Frank發起並組織了在歐洲舉辦的第一次關於模式的會議——EuroOLop 1996，他也是PLoPD叢書第三卷的主編之一。Frank參與了一些大規模工業軟體項目的設計與實現，這些項目包括商務信息、工業自動化以及電信系統。
工作之餘，Frank的生活豐富多彩。他喜歡陪著妻子Martina和女兒Anna享受家庭的快樂；他喜歡騎著馬兒Eddi外出遛彎，或者獨自跑到慕尼黑啤酒花園打發時間；他喜歡在觀看最愛的多特蒙德足球隊的比賽時盡灑激情，也偶爾在慕尼黑歌劇院裡的演出中盡情陶醉；臨睡前他還喜歡來杯珍藏的蘇格蘭純麥威士忌。
亨尼（Kevlin Henney），住在英國布里斯托，是一名獨立顧問。他主要從事自己感興趣的領域的教授、輔導和實踐，這些領域包括程式語言和技術、軟體架構、模式和敏捷開發。他的客戶既有全球化的公司，也有剛起步的小公司，所涉及的領域包括系統軟體、電信、嵌入式系統、中間件開發、業務信息和金融。
Kevlin經常在各種軟體會議上應邀演講，同時也參與了多個會議的組織工作，包括EuroPLoP。他通過英國標準學會（BSI）和ISO參與到c++的標準中來，同時也參與了其他語言的標準化工作。Kevlin也因其寫作受人關注，經常發表會議論文，主持各種出版物上定期的（和不定期的）專欄，比如Cl++Report、Cl/c++己lsers Journal.Java ReporT、JavasPektrum、Application DevelopmentAdvisor、The Register、EXE和Overload。
Kevlin的業餘時間則是與妻子Carolyn還有兩個孩子Stefan和Yannick度過的。他跟孩子擺擺積木，給孩子們修修玩具，看書，有時也啜幾口啤酒或者來一杯葡萄酒。
施密特（Doug Schmidt），是美國田納西州納什維爾市范德比爾特大學計算機科學教授，計算機科學與工程計畫副主席。他的研究領域包括模式和模式語言、最佳化原理，還包括對於支持服務質量（QoS）的組件中間件相關技術的實證分析（empirical analysis）和支持分散式實時嵌入式系統的模型驅動的工程工具。
Doug是國際公認的軟體開發方面的專家，尤其是模式、面向對象框架、實時中間件、建模工具和開源軟體開發等方面。他已經在各種頂級技術雜誌和會議上發表了300多篇論文；他與人合著了模式方面的著作[POSA2]和有關C++網路編程的[SH02][SH03]；同時他還與人合編過數本暢銷的書，比如模式方面有[PLoPDl]，框架方面有[FJS99a][FJS99b]。除了學術研究，Doug還領導了ACE、TAO、ciao和CoSMIC的開發，這些廣泛套用的開源的中間件框架和模型驅動的工程工具包含了一整套豐富的可重用的組件，這些組件的實現大量使用了本書中介紹的模式。
在他閒暇之隙，Doug總是跟妻子Lori和兒子Bronson待在一起，他們一起練練舉重、彈彈吉它、討論世界歷史和政治，或者開著他們的雪佛蘭corvette跑車四處兜風。
譯者簡介
肖鵬，thoughtworks高級諮詢師。敏捷過程教練。面向對象分析和面向對象設計專家。擁有6年以上軟體開發實踐經驗，多次擔任國內大中型企業敏捷流程改進、面向對象分析和面向對象設計諮詢和培訓。他長期關注設計模式、架構模式、敏捷軟體開發等領域。並致力於推廣軟體開發最佳實踐。他曾參與翻譯《ViSual Studio 2005技術大全》，主持翻譯《面向模式的軟體架構》第四卷和第五卷。
目錄
第一部分 概 念
第1章 模式與模式語言 2
1.1 模式 2
1.2 模式內幕 3
1.2.1 問題的環境 3
1.2.2 驅動因素：所有模式的核心 4
1.2.3 解決方案與結果 4
1.2.4 模式命名 4
1.2.5 模式表現形式概述 5
1.3 模式的關係 5
1.3.1 模式的互補 5
1.3.2 模式的組合 6
1.3.3 模式故事 6
1.3.4 模式序列 7
1.4 模式語言 7
1.4.1 從模式序列到模式語言 7
1.4.2 展現和使用模式語言 7
1.5 模式的連線 8
第2章 分散式系統 9
2.1 分散式的優點 9
.2.2 分散式的挑戰 11
2.3 用以支持分散式的技術 12
2.3.1分散式對象計算中間件 13
2.3.2 組件中間件 14
2.3.3 發布/訂閱中間件和面向訊息的中間件 15
2.3.4 面向服務架構和web服務 16
2.4 中間件技術的局限性 17
第3章 模式語言 18
3.1 意圖、範疇和對象 18
3.2 起源 18
3.3 結構和內容 19
3.4 模式的表現 24
3.5 實際套用 26
第二部分 模式故事
第4章 倉庫管理流程控制 33
4.1 系統範疇 33
4.2 倉庫管理流程控制 34
第5章 基線架構 37
5.1 架構環境 37
5.2 劃分大泥球 38
5.3 層次分解 38
5.4 訪問領域對象功能 40
5.5網路橋接41
5.6 分離用戶界面 43
5.7 功能分布 45
5.8 支持並發的領域對象訪問 47
5.9 獲得可擴展的並發性 48
5.10 將面向對象與關係型資料庫連線起來 49
5.11 領域對象的運行時配置 50
5.12 基線架構總結 51
第6章通信中間件54
6.1 分散式系統的中間件架構 54
6.2 對中間件的內部設計進行結構化 57
6.3 封裝底層系統機制 58
6.4 分離orb核心事件 59
6.5 orb連線管理 61
6.6 提高orb的可伸縮性 63
6.7 實現同步請求佇列65
6.8 可互換的內部orb機制 66
6.9 管理orb策略 68
6.10 orb動態配置 69
6.11 通信中間件總結 71
第7章 倉庫拓撲 74
7.1 倉庫拓撲基線 74
7.2 表現層次化的存儲結構 74
7.3 存儲結構導航 77
7.4 存儲屬性建模 78
7.5 不同的存儲單元行為 79
7.6 實現全局功能 81
7.7 遍歷倉庫拓撲 81
7.8 支持控制流擴展 83
7.9 連線資料庫 84
7.10 維護記憶體中的存儲單元數據 85
7.11 配置倉庫拓撲 86
7.12 細述顯式接口 88
7.13 倉庫拓撲總結 89
第8章 模式故事背後的故事 91
第三部分 模式語言
第9章 從混沌到結構 97
9.1 domain model** 106
9.2 layers** 108
9.3 model-view-controller** 109
9.4 presentation-abstraction-control 111
9.5Microkernel** 113
9.6 reflection* 114
9.7 pipes and filters** 116
9.8 shared repository** 117
9.9blackboard119
9.10 domain object** 121
第10章 分散式基礎設施 123
10.1 messaging** 129
10.2 message channel** 130
10.3 message endpoint** 132
10.4 message translator** 133
10.5 message router** 134
10.6 publisher-subscriber** 135
10.7 broker** 137
10.8 client proxy** 139
10.9 requestor** 140
10.10 invoker** 142
10.11 client request handler** 143
10.12 server request handler** 144
第11章 事件分離和分發 147
11.1 reactor** 150
11.2 proactor* 152
11.3 acceptor-connector** 154
11.4asynchronous completion token** 155
第12章 接口劃分 157
12.1 explicit interface** 163
12.2 extension interface** 165
12.3introspectiveinterface** 166
12.4 dynamicinvocationinterface* 167
12.5 proxy** 169
12.6 business delegate** 170
12.7 facade** 171
12.8 combined method** 172
12.9 iterator** 173
12.10 enumeration methond** 174
12.11 batch method** 175
第13章 組件劃分 177
13.1 encapsulated implementation** 181
13.2 whole-part** 183
13.3 composite** 185
13.4 master-slave** 186
13.5 half-object plus protocol** 188
13.6 replicated component group** 189
第14章 套用控制 191
14.1 page controller** 196
14.2 front controller** 197
14.3 application controller** 198
14.4 command processor** 199
14.5 template view** 200
14.6 transform view** 201
14.7 firewall proxy** 202
14.8 authorization** 204
第15章 並發 206
15.1 half-sync/half-async** 209
15.2 leader/followers** 211
15.3 active object** 212
15.4 monitor object** 214
第16章 同步 216
16.1guardedsuspension** 221
16.2 future** 223
16.3 thread-safe interface* 224
16.4 double-checked locking 225
16.5 strategized locking** 226
16.6 scoped locking** 227
16.7 thread-specific storage 228
16.8 copied value** 230
16.9immutablevalue** 231
第17章 對象間的互動 233
17.1 observer** 237
17.2 double dispatch ** 238
17.3 mediator* 239
17.4 command** 240
17.5 memento** 242
17.6 context object** 243
17.7 data transfer object** 244
17.8 message** 245
第18章 適配與擴展 247
18.1 bridge** 255
18.2 object adapter** 256
18.3 chain of responsibility* 257
18.4 interpreter 258
18.5 interceptor** 260
18.6 visitor** 261
18.7decorator262
18.8 execute-around object** 264
18.9 template method* 265
18.10 strategy** 266
18.11 null object** 267
18.12 wrapper facade** 269
18.13 declarative component
configuration* 270
第19章 模態行為 272
19.1 objects for states* 274
19.2 methods for states* 275
19.3 collections for states* 276
第20章 資源管理 278
20.1 container* 288
20.2 component configurator* 289
20.3 object manager** 291
20.4 lookup** 292
20.5 virtual proxy** 294
20.6 lifecycle callback** 295
20.7 task coordinator* 296
20.8 resource pool** 298
20.9 resource cache** 299
20.10 lazy acquisition** 300
20.11 eager acquisition** 301
20.12 partial acquisition* 303
20.13 activator** 304
20.14 evictor** 305
20.15 leasing** 306
20.16 automatedGarbage collection** 307
20.17 counting handles** 309
20.18 abstract factory** 311
20.19 builder* 312
20.20 factory method** 313
20.21 disposal method** 314
第21章 資料庫訪問 316
21.1 database access layer** 318
21.2 data mapper** 320
21.3 row data gateway** 321
21.4 table data gateway ** 323
21.5 active record 324
第22章 最後的思考 326
術語表 327
參考書目 340
序言
模式運動已經進行了十多年，從追捧到棒殺再到慢慢接受，模式已經經歷了這個常見的輪迴。Frank、Doug和Kevlin一直參與其中，受到過讚美，也遭遇過嘲諷，重要的是他們從中收集了大量好的想法，並將其描繪出來。POSA系列圖書被認為是模式相關文獻中最為堅實的基礎性著作之一，它的每一卷都在我的書架上占有一席之地。
POSA的前幾卷屬於傳統的模式書籍，描繪了某些特定領域中使用的模式，其中大部分以前均未有書面記錄。本書則不同。分散式計算是一個相當寬泛的主題，一捲圖書哪怕只是容納已知的模式也是遠遠不夠的。實際上這些模式分布在很多書裡面，包括POSA系列和一些別的書。本書的目的是要把它們聚在一起。所以，這裡列出的模式可能比你平時看到的要多，當然其描述也要簡潔得多。有些模式可能並不是主要關於分散式的，但是多少都會和分散式系統有些關係。因此，本書是以分散式系統為背景來介紹這些模式的用法，並加以總結。
本書並不是僅僅介紹每個獨立的模式的——同時也介紹它們之間的關係。在任何一個系統中都會同時使用多個模式，然而，就拿我的體會來說，講述其中的關係要比介紹單獨的模式難得多。本書沒有迴避這個問題，書中給出了很多關於在分散式場合下聯合使用多種模式的建議。
分散式往往是一個棘手的難題。事實上，經常有人引用我的所謂分散式對象設計第一定律的“名言”：“不要使用分散式對象。”我這樣說是有原因的——分散式使得軟體設計更困難，所以我一直建議儘可能地避免採用分散式設計。然而無論我如何強烈地質疑分散式設計的範圍，分散式畢竟是很多軟體系統重要的組成部分。
文摘
這一章，我們拋開倉庫管理流程控制系統的細節，再來回顧一下這個例子的全景，看看它是如何指導我們做出設計的。我們將討論這個例子是如何支持模式語言中的各種屬性，以及本書第三部分的分散式計算模式語言是如何支持和指導我們在這個例子選擇什麼樣的模式序列。
回顧一下我們為倉庫管理流程控制系統做架構設計的過程，你會發覺對模式的選擇和套用是非常自然的，好像本來就應該設計成這個樣子，甚至可能會認為是預先設計好的。這個故事自然流暢，我們很容易跟上它的節奏。所以，讓人覺得這個架構設計的過程非常直觀。
然而，這種感覺實際上是一種過於單純的錯覺，說明你沒有意識到存在某種微妙的東西使得設計行為不像轉門把手那么簡單。對模式序列的分析告訴我們，這是經過深思熟慮的選擇，而不是隨便拿一個就可以用的。最明顯的是，每個單獨的模式滿足了倉庫管理流程控制系統的某個特定需求——這當然是創建一個良好的軟體架構的必備條件。然而，僅僅選擇了正確的模式還不能保證就能設計出一個高效的、健壯的架構。這些模式必須按照合適的順序集成在一起，互為補充而不能互相打架。僅僅靠一套各自獨立的模式完不成這個任務，因為它們主要關注於解決自己針對的那個問題。
隨著設計慢慢地推進，每次引入一個模式，該系統架構的模式序列逐漸創建並顯現出來，它不僅是完整的，而且不同的部分互為補充——不僅從功能角度上看是這樣，對於成功至關重要的運營和開發方面亦是如此，比如吞吐量、可伸縮性、靈活性和可移植性。
在基線架構以及通信中間件和倉庫拓撲的基礎結構這個層次，模式序列中的這些模式用於解決系統級別戰略性的問題並定義架構主幹。像算法上的變化和控制流程這樣的局部的戰術上的問題則放到了模式序列的後面，等到各自穩定的戰略性設計中樞確定下來之後再做處理。我們在序列中每次增加一個模式，增加的時候我們先把它整合到已有的設計中，而不過早地關心起實現細節。換句話說，就是每增加一個新的模式都是將原來的設計進行增強和擴展，從而產生一個新的設計。
所有的這些模式基於其各自的角色集成在一起，它們之間的平衡保證各自能夠解決各自的問題，同時又能互相支持從而進一步地表現出各自的能力。例如，我們的基於CCM的ORB中的很多組件分別參與了幾個模式的實現。
