SOA服务设计原则 中间有写字划线

图书标准信息

• 作者 [美]厄尔（Erl T） 著；郭耀 译
• 出版社 人民邮电出版社
• 出版时间 2009-06
• 版次 1
• ISBN 9787115204929
• 定价 55.00元
• 装帧 平装
• 开本 16开
• 纸张 胶版纸
• 页数 346页
• 字数 543千字
• 正文语种 简体中文

【内容简介】

　　本书首先简要介绍了SOA与面向服务的基本概念和关键目标，然后着重阐述了为实现SOA的目标需要遵守的8个核心设计原则：标准化服务合约、服务松散耦合、服务抽象、服务可复用性、服务自治、服务无状态性、服务可发现性和服务可组合性。本书结构清晰、行文简洁，并且在书中贯穿了具体的案例来形象地介绍这些相对比较抽象的设计原则。本书作者ThomasErl是业界公认的SOA领袖，本书以及他的其他著作被许多著名跨国公司的资深专家誉为“必备的SOA参考书”。
　　本书的读者对象是对面向服务架构感兴趣的IT开发人员、分析师与架构师。通过阅读本书，读者不仅可以更加深入地理解SOA的基本原理以及SOA能够带来的好处，更重要的是，可以更加深入地学习在实践SOA的过程中需要遵守的基本原则，并通过书中的实际案例来掌握如何在实践中运用这些原则。

【作者简介】

　　ThomasErl是全球最畅销的SOA类书籍的作者，“ThomaSErl面向服务计算系列”丛书的编辑，以及《SOA杂志》的编辑。ThomasErl同时也是SOA系统公司的创始人，这是一个专门提供SOA培训和策略咨询服务的公司。Thomas是一位经常参与私人和公众活动的演说家和讲师，发表过无数文章和论文，为许多新闻机构提供在线演讲，并接受他们的采访，其中包括《华尔街期刊》。

【目录】

第1章概述1
1.1本书的目标2
1.2读者对象3
1.3本书不涉及的内容3
1.3.1本丛书中包括的其他书3
1.3.2SOA的标准化努力4
1.4本书的组织结构4
1.4.1第1部分：基本原理5
1.4.2第2部分：设计原则6
1.4.3第3部分：补充内容8
1.4.4附录8
1.5符号、图形和风格约定9
1.5.1符号图例9
1.5.2服务的符号9
1.6附加说明11
1.6.1更新、勘误和资源11
1.6.2主术语表11
1.6.3参考规范11
1.6.4面向服务计算的海报11
1.6.5SOA杂志11
1.6.6通知服务12
1.6.7联系作者12

第2章案例研究13
2.1案例研究背景：CutitSaws公司14
2.1.1历史14
2.1.2技术基础设施和自动化环境14
2.1.3业务目标与障碍14

第1部分基本原理
第3章面向服务计算与SOA18
3.1设计的基本原理19
3.1.1设计特性19
3.1.2设计原则20
3.1.3设计范型21
3.1.4设计模式21
3.1.5设计模式语言22
3.1.6设计标准23
3.1.7最佳实践24
3.1.8一个基本设计框架25
3.2面向服务计算概述27
3.2.1面向服务架构27
3.2.2面向服务、服务以及面向服务方案逻辑28
3.2.3服务组合28
3.2.4服务库存29
3.2.5理解面向服务计算中的元素29
3.2.6服务模型31
3.2.7SOA和Web服务34
3.2.8服务库存蓝图37
3.2.9面向服务分析和服务建模37
3.2.10面向服务设计37
3.2.11Service-QrientedArchitecture：Concepts，Technology，andDesign39
3.3面向服务计算的目标和价值39
3.3.1内在互操作性的提高40
3.3.2联合的增强41
3.3.3厂商多样性选择的增加42
3.3.4业务和技术领域一致性的提高42
3.3.5投资回报率的提高43
3.3.6组织敏捷度的提高44
3.3.7IT负担的降低45
3.4案例研究背景46

第4章面向服务47
4.1面向服务概述48
4.1.1业务自动化中的服务49
4.1.2服务是能力的集合49
4.1.3面向服务作为一种设计范型49
4.1.4面向服务和互操作性51
4.2面向服务解决的问题52
4.2.1在面向服务到来之前53
4.2.2面向服务的必要性56
4.3面向服务带来的挑战58
4.3.1设计复杂性58
4.3.2对设计标准的需求59
4.3.3自顶向下的需求59
4.3.4支持敏捷方案交付的反敏捷服务交付60
4.3.5治理需求60
4.4其他考虑61
4.4.1它不是一个革命性的范例61
4.4.2不要求整个企业范围的标准化61
4.4.3复用不是一个绝对的需求62
4.5面向服务对企业的影响62
4.5.1面向服务和“应用程序”的概念62
4.5.2面向服务和“集成”的概念64
4.5.3服务组合65
4.5.4应用程序、集成和企业架构66
4.6面向服务的起源和影响67
4.6.1面向对象67
4.6.2Web服务67
4.6.3业务流程管理(BPM)67
4.6.4企业应用集成(EAI)68
4.6.5面向侧面的编程(AOP)68
4.7案例研究背景69

第5章理解设计原则71
5.1使用设计原则72
5.1.1在面向服务分析中应用这些原则72
5.1.2在正式的设计过程中应用这些原则73
5.1.3建立支持的设计标准74
5.1.4把原则应用到一个可行的程度74
5.2原则概要75
5.3设计模式引用76
5.4实现原则vs.调控原则76
5.5原则与服务实现媒介78
5.6原则与设计粒度79
5.6.1服务粒度79
5.6.2能力粒度79
5.6.3数据粒度79
5.6.4约束粒度80
5.6.5关于粒度级别的小节81
5.7案例研究背景81

第2部分设计原则
第6章服务合约(标准化与设计)86
6.1合约释义87
6.1.1技术合约简述87
6.1.2服务合约的起源88
6.2原则概要90
6.3服务合约标准化的类型91
6.3.1功能服务描述的标准化91
6.3.2服务数据表示的标准化92
6.3.3服务策略的标准化94
6.4合约与服务设计96
6.4.1数据表示标准化和转换的避免96
6.4.2标准化与粒度97
6.4.3标准化服务合约与服务模型99
6.4.4标准化服务合约设计如何影响其他原则99
6.5服务合约设计的相关风险102
6.5.1版本化102
6.5.2技术依赖103
6.5.3开发工具缺陷103
6.6服务合约的进一步介绍104
6.6.1非技术性服务合约文档105
6.6.2“针对SOA的Web服务合约设计”105
6.7案例研究105
6.7.1计划中的服务105
6.7.2设计标准106
6.7.3标准化的WSDL定义概要106
6.7.4标准化的XMLSchema定义107
6.7.5标准化的服务和数据表示层107
6.7.6服务描述108
6.7.7小结109

第7章服务耦合(服务内及消费者依赖)110
7.1耦合释义111
7.1.1耦合简述111
7.1.2软件耦合的起源112
7.2原则概要113
7.3服务合约耦合的类型114
7.3.1“逻辑-合约”耦合(服务逻辑到服务合约的耦合)116
7.3.2“合约-逻辑”耦合(服务合约到服务逻辑的耦合)118
7.3.3“合约-技术”耦合(服务合约到其底层技术的耦合)119
7.3.4“合约-实现”耦合(服务合约到其实现环境的耦合)119
7.3.5“合约-功能”耦合(服务合约到其外部逻辑的耦合)121
7.4服务消费者耦合的类型122
7.4.1“消费者-实现”耦合123
7.4.2标准化服务耦合与合约集中化123
7.4.3“消费者-合约”耦合124
7.4.4消费者耦合的度量128
7.5服务松散耦合与服务设计129
7.5.1耦合与面向服务129
7.5.2服务松散耦合与粒度130
7.5.3耦合与服务模型131
7.5.4服务松散耦合如何影响其他原则132
7.6服务松散耦合的相关风险133
7.6.1“逻辑-合约”耦合的限制133
7.6.2当模式耦合太“松散”时的问题134
7.7案例研究135
7.7.1现有服务的耦合级别135
7.7.2引入InvLegacyAPI服务135
7.7.3服务设计选择136

第8章服务抽象(信息隐藏与元抽象类型)140
8.1抽象释义141
8.2原则概要142
8.3元抽象类型144
8.3.1技术信息抽象145
8.3.2功能抽象146
8.3.3程序逻辑抽象147
8.3.4服务质量抽象148
8.3.5元抽象类型和Web服务影响区域149
8.3.6真实世界中的元抽象类型150
8.4服务抽象度量153
8.4.1合约内容的抽象级别153
8.4.2访问控制级别154
8.4.3抽象级别与服务质量元信息155
8.5服务抽象与服务设计155
8.5.1服务抽象vs.服务封装155
8.5.2封装如何影响抽象156
8.5.3服务抽象与非技术合约文档157
8.5.4服务抽象与粒度157
8.5.5服务抽象与服务模型158
8.5.6服务抽象如何影响其他的原则158
8.6服务抽象的相关风险160
8.6.1多消费者耦合的需求160
8.6.2人为误判160
8.6.3安全和隐私的考虑161
8.7案例研究161
8.7.1服务抽象级别161
8.7.2操作级的抽象例子163

第9章服务可复用性(商业与无关设计)166
9.1复用释义167
9.1.1复用简述167
9.1.2复用的起源169
9.2原则概要170
9.3服务可复用性度量及商业设计的应用171
9.3.1商业设计考虑173
9.3.2计划中复用的度量174
9.3.3实际复用的度量175
9.3.4商业设计和镀金175
9.4SOA中的服务复用176
9.4.1复用和无关服务176
9.4.2服务库存蓝图176
9.5标准化服务复用与逻辑集中化177
9.5.1理解逻辑集中化177
9.5.2作为企业标准的逻辑集中化178
9.5.3逻辑集中化与合约集中化179
9.5.4集中化与Web服务180
9.5.5实现逻辑集中化的挑战180
9.6服务可复用性与服务设计181
9.6.1服务可复用性与服务建模181
9.6.2服务可复用性与粒度182
9.6.3服务可复用性与服务模型182
9.6.4服务可复用性如何影响其他原则183
9.7服务可复用性的相关风险184
9.7.1文化上的考虑184
9.7.2治理上的考虑185
9.7.3可靠性上的考虑187
9.7.4安全上的考虑188
9.7.5商业设计需求上的考虑188
9.7.6敏捷交付上的考虑188
9.8案例研究189
9.8.1Inventory服务概要189
9.8.2评估当前的能力189
9.8.3为针对性的可复用性进行建模190
9.8.4添加EditItemRecord操作190
9.8.5添加ReportStockLevels操作190
9.8.6添加AdjustItemsQuantity操作190
9.8.7修改后的Inventory服务概要191

第10章服务自治(处理边界与控制)192
10.1自治释义193
10.1.1自治简述193
10.1.2自治的起源193
10.2原则概要194
10.3服务自治的类型195
10.3.1运行时自治195
10.3.2设计时自治(治理)196
10.4服务自治度量197
10.4.1服务合约自治(带有规范化合约的服务)197
10.4.2服务逻辑自治(部分孤立服务)201
10.4.3完全自治(孤立的服务)202
10.4.4具有混合自治级别的服务203
10.5自治与服务设计204
10.5.1服务自治与服务建模204
10.5.2服务自治与粒度204
10.5.3服务自治与服务模型204
10.5.4服务自治怎样影响其他原则206
10.6服务自治的相关风险208
10.6.1错误地判断服务的范围208
10.6.2包装服务和遗留逻辑封装208
10.6.3对服务需求的过高估计209
10.7案例研究209
10.7.1GetItem操作现在所实现的自治209
10.7.2新的拥有更高自治的操作级别架构210
10.7.3对于RunLabProject组合的影响211
第11章服务无状态性(状态管理延迟与无状态性设计)213
11.1状态管理释义214
11.1.1状态管理简述214
11.1.2状态管理的起源215
11.1.3延迟与委托的比较218
11.2原则概要218
11.3状态的类型220
11.3.1活跃和被动221
11.3.2无状态和有状态221
11.3.3会话和上下文数据221
11.4服务无状态性度量223
11.4.1非延迟的状态管理(无状态性从低到没有)224
11.4.2部分延迟存储(较低的有状态性)225
11.4.3部分架构状态管理延迟(中等无状态性)225
11.4.4完全架构状态管理延迟(高度无状态性)225
11.4.5内部延迟状态管理(高度无状态性)226
11.5无状态性与服务设计227
11.5.1消息作为一个状态延迟选项227
11.5.2服务无状态性与服务实例228
11.5.3服务无状态性与粒度228
11.5.4服务无状态性与服务模型229
11.5.5服务无状态性如何影响其他原则229
11.6服务无状态性的相关风险231
11.6.1对于架构的依赖231
11.6.2增加的运行时性能需求231
11.6.3低估交付代价231
11.7案例研究232
第12章服务可发现性(可解释性与交流)237
12.1可发现性释义238
12.1.1发现和解释、可发现性和可解释性简述239
12.1.2发现的起源241
12.2原则概要242
12.3发现和可发现性元信息的类型243
12.3.1设计时发现和运行时发现244
12.3.2可发现性元信息245
12.3.3功能性元数据246
12.3.4服务元数据的质量246
12.4服务可发现性度量247
12.4.1基本级别247
12.4.2定制分级系统247
12.5可发现性与服务设计248
12.5.1服务可发现性与服务建模248
12.5.2服务可发现性与粒度249
12.5.3服务可发现性与策略断言249
12.5.4服务可发现性与服务模型249
12.5.5服务可发现性如何影响其他原则249
12.6服务可发现性的相关风险251
12.6.1可发现性在实施后的应用251
12.6.2由不擅交流的人员来应用本原则251
12.7案例研究252
12.7.1服务概要(功能元信息)252
12.7.2相关的服务质量元信息253
第13章服务可组合性(组合成员设计与复杂组合)255
13.1组合释义256
13.1.1组合简述256
13.1.2组合的起源256
13.2原则概要260
13.3组合的概念和术语262
13.3.1组合和组合实例262
13.3.2组合成员和控制器262
13.3.3服务组合和Web服务265
13.3.4服务活动266
13.3.5组合启动器267
13.3.6点到点的数据交换和组合268
13.3.7组合的类型268
13.4复杂服务组合269
13.4.1一个服务库存演化的阶段269
13.4.2定义复杂服务组合271
13.4.3为复杂服务组合做准备271
13.5服务可组合性度量272
13.5.1组合的演化周期状态272
13.5.2组合设计评估273
13.5.3组合运行时评估273
13.5.4组合治理的评估274
13.5.5可组合性的度量275
13.6组合与服务设计278
13.6.1服务可组合性与粒度278
13.6.2服务可组合性与服务模型279
13.6.3服务可组合性与组合自治279
13.6.4服务可组合性与编排280
13.6.5服务可组合性如何影响其他原则281
13.7服务组合的相关风险284
13.7.1组合成员成为单点失效的源头285
13.7.2组合成员成为性能瓶颈285
13.7.3对于组合中“过度复用”的治理强度285
13.8案例研究286

第3部分补充内容
第14章面向服务与面向对象：原则和概念上的比较290
14.1两种设计范式的传说291
14.2目标的比较293
14.2.1提高业务需求的满足度294
14.2.2提高鲁棒性294
14.2.3提高可扩展性295
14.2.4提高灵活性295
14.2.5提高可复用性和生产率295
14.3基本概念的比较296
14.3.1类和对象296
14.3.2方法和属性296
14.3.3消息297
14.3.4接口298
14.4设计原则的比较299
14.4.1封装300
14.4.2继承300
14.4.3泛化和特化301
14.4.4抽象303
14.4.5多态性303
14.4.6开放-封闭原则(OCP)304
14.4.7别重复你自己(DRY)304
14.4.8单一职责原则(SRP)304
14.4.9委托307
14.4.10关联307
14.4.11组合308
14.4.12聚合308
14.5面向服务类的设计指南310
14.5.1类接口的实现310
14.5.2限制类对接口的访问310
14.5.3不要在接口中定义公共属性310
14.5.4谨慎使用继承310
14.5.5避免跨服务的has-a关系311
14.5.6使用抽象类进行建模，而不是进行设计311
14.5.7使用门面(Facade)类311
第15章实践支持312
15.1服务概要313
15.1.1服务层的概要结构313
15.1.2能力概要结构314
15.1.3其他考虑因素315
15.2词汇表316
15.2.1面向服务计算的术语317
15.2.2服务分类的术语317
15.2.3类型和相关术语318
15.2.4设计原则的应用级别318
15.3组织角色319
15.3.1服务分析员321
15.3.2服务架构师321
15.3.3服务管理者321
15.3.4schema管理者322
15.3.5策略管理者322
15.3.6服务注册表管理者322
15.3.7技术交流专家323
15.3.8企业架构师323
15.3.9企业设计标准管理者(及审计员)323
第16章面向服务原则到战略目标的映射325
16.1提高内在互操作性的原则326
16.2增强联合的原则327
16.3增加厂商多样化选择的原则327
16.4提高业务和技术领域一致性的原则328
16.5提高投资回报率的原则328
16.6提高组织敏捷度的原则329
16.7降低IT整体负担的原则330

第4部分附录
附录A案例研究总结332
附录B过程描述334
B.1交付过程335
B.1.1自顶向下与自底向上335
B.1.2库存分析周期335
B.1.3库存分析与面向服务设计337
B.1.4选择交付策略337
B.2面向服务分析过程338
B.2.1定义分析范围339
B.2.2识别受影响的系统340
B.2.3执行服务建模340
B.3服务建模过程340
B.4面向服务设计过程342
B.4.2服务设计过程与面向服务342
附录C原则和模式的对照345
其他资源347