SOA服务设计原则
点此进入淘宝搜索页搜索分类: 图书,计算机与互联网,网络与通讯,WebServer,综合,
品牌: Thomas Erl
基本信息·出版社：人民邮电出版社
·页码：346 页
·出版日期：2009年
·ISBN：7115204926/9787115204929
·条形码：9787115204929
·包装版本：1版
·装帧：平装
·开本：16
·正文语种：中文
产品信息有问题吗？请帮我们更新产品信息。
内容简介《SOA服务设计原则》首先简要介绍了SOA与面向服务的基本概念和关键目标，然后着重阐述了为实现SOA的目标需要遵守的8个核心设计原则：标准化服务合约、服务松散耦合、服务抽象、服务可复用性、服务自治、服务无状态性、服务可发现性和服务可组合性。《SOA服务设计原则》结构清晰、行文简洁，并且在书中贯穿了具体的案例来形象地介绍这些相对比较抽象的设计原则。《SOA服务设计原则》作者Thomas Erl是业界公认的SOA领袖，《SOA服务设计原则》以及他的其他著作被许多著名跨国公司的资深专家誉为“必备的SOA参考书”。
作者简介Thomas Erl，是全球最畅销的SOA类书籍的作者，“Thomas Erl面向服务计算系列”丛书的编辑，以及《SOA杂志》的编辑。Thomas Erl同时也是SOA系统公司的创始人，这是一个专门提供SOA培训和策略咨询服务的公司。Thomas是一位经常参与私人和公众活动的演说家和讲师，发表过无数文章和论文，为许多新闻机构提供在线演讲，并接受他们的采访，其中包括《华尔街期刊》。
媒体推荐“本书可以说是一本服务设计的百科全书——Erl没有遗漏任何东西，实在是必不可少的一本书。”
——Steve Biekel，Inter公司首席IT技术架构师
编辑推荐《SOA服务设计原则》的读者对象是对面向服务架构感兴趣的IT开发人员、分析师与架构师。通过阅读《SOA服务设计原则》，读者不仅可以更加深入地理解SOA的基本原理以及SOA能够带来的好处，更重要的是，可以更加深入地学习在实践SOA的过程中需要遵守的基本原则，并通过书中的实际案例来掌握如何在实践中运用这些原则。
成功采用面向服务架构（SOA）的关键在于理解其最根本的构造模块（即服务）的意义和重要性。只有理解服务设计，才有可能创建真正的“面向服务”解决方案来支持sOA与面向服务计算目标的实现。《SOA服务设计原则》对面向服务设计范型进行了全面、深入和形象的探讨，恰如其分地展现了在现实世界的SOA中应该如何设计服务。
目录
第1章 概述 1
1.1 本书的目标 2
1.2 读者对象 3
1.3 本书不涉及的内容 3
1.3.1 本丛书中包括的其他书 3
1.3.2 SOA的标准化努力 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.5 SOA 杂志 11
1.6.6 通知服务 12
1.6.7 联系作者 12
第2章 案例研究 13
2.1 案例研究背景：Cutit Saws公司 14
2.1.1 历史 14
2.1.2 技术基础设施和自动化环境 14
2.1.3 业务目标与障碍 14
第1部分 基本原理
第3章 面向服务计算与SOA 18
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.7 SOA和Web服务 34
3.2.8 服务库存蓝图 37
3.2.9 面向服务分析和服务建模 37
3.2.10 面向服务设计 37
3.2.11 Service-Qriented Architecture: Concepts, Technology, and Design 39
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.7 IT负担的降低 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.2 Web服务 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 标准化的XML Schema定义 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.4 SOA中的服务复用 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.1 Inventory服务概要 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.1 GetItem操作现在所实现的自治 209
10.7.2 新的拥有更高自治的操作级别架构 210
10.7.3 对于Run Lab Project组合的影响 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.4 schema管理者 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
……[看更多目录]
序言在过去几年中，我在参与私营和公共机构的客户进行的各种范围内的SOA项目的过程中，遇到了许多不同的IT环境。在参与一个国防工业客户的项目时，我不仅有机会了解到他们在技术方面的要求，同时也了解到了专门同国防产业相关的各种策略与规程。正是在那个时候，我参与了DOD（美国国防部）标准化项目，这个项目包括了各种文档和规范，用来建立关于军事领域的各种指导原则和标准，这其中包括了武器和其他军事装备的设计，以及军方人员所使用的方法和过程的定义。
在学习这个项目的同时，我得知在过去也曾经存在过一些其他的标准化项目，帮助一些公共机构（例如海岸防卫队和美国航空航天局）以及许多私营公司进行标准化。这些项目的目标都是围绕着建立一套产业标准，通过提高互操作性，以达到降低运作额外开销、降低风险和提高组织的整体有效性的最终目标。
在前面提到的公开领域中的相关标准中，互操作性可以是指装备或武器的交换，或者是在不同地点的人员之间的交流和协作。
例如，一个在爱奥瓦州生产的子弹夹，可能会存储在弗吉尼亚州的仓库，会被运送到一个位于得克萨斯州的训练基地，可以用在一把在堪萨斯州制造的手枪上来完美地供士兵使用。之所以可以这样做，是因为这些产品都是根据同样的规范来制造的。类似地，在对一个自然灾害事件作出反应时，要组建一个营救团队，可能需要迅速召集来自不同城市、可能从来也没有在一起共事过的人员。这个团队仍然能够有效地运作，这是因为所有的团队成员都是根据相同的规程和流程来训练的，他们都采用相同的术语和约定。
这些标准化的项目同SOA与面向服务背后的原理和目标是大同小异的。最根本的目标都是产生一些具有可重复的价值、长期的利益以及内在灵活性的东西，它们对于企业的战略性目标是有益的。为了在SOA世界中达成这一目标，最大的障碍是大家对于面向服务作为一个工业范型到底意味着什么缺乏共识。我期望通过本书可以帮助缓解这种情形，对于“面向服务”意味着什么提供一些更为清晰的解释。
文摘插图：
一个组织要成功应用一种设计范型，仅仅拥有对相关设计原则以及对支撑性设计模式的理解是不够的。每个组织都有特定的战略目标和特定的企业环境。这些形成了特定的一组需求和约束条件，需要在解决方案设计中加以调和。
设计标准（design standards）是（通常是强制性的）设计惯例；为了支持组织的目标，它们会被加以定制，并一致地预先决定了解决方案的设计特性，而且针对特定的企业环境进行了优化。正是透过内部设计标准的使用，一个组织才能够持续地实施那些针对其特定环境、资源、目标和优先考虑事项而进行剪裁的解决方案（如图3．6所示）。
正如应用设计原则一样，设计标准的应用将导致创建特定的设计特性。正如设计模式一样，设计标准推动并精炼了这些特性以避免潜在的问题和加强整体的解决方案设计。事实上，通常建议设计标准应当基于或者来源于业界的设计原则和模式。
能够拥有不带有设计原则的设计标准吗？当然可以，实际上拥有多个设计标准是普遍的现象。其中可能只有一些标准需要与原则关联，以便于透彻理解整体设计范型的应用。不同的设计标准也可以被创建出来，可能仅仅是为了支持其他的目标或者补偿特定环境、文化或技术相关的因素所强加的约束条件。尽管某些标准可能与被接受的设计原则之间并没有直接的关联关系，但是必须尽力保持所有标准之间的相对一致与和谐。
