SOA设计原则与设计方法学（服务科学与工程概论·第9讲）
IBM 风格企业架构课程讲义（2008-12），分两大块：SOA 设计原则、SOA 设计方法学（以 IBM SOMA 为例）。
一、为什么需要 SOA（IT 战略挑战）
- 核心命题：企业从垂直整合（Vertical Integration）转向水平整合（Horizontal Integration），IT 要支撑”实时企业”与价值网络协作。
- IT 存量困境：“书同文、车同轨”问题——已有系统独立建设、异构（平台/语言/架构范式互不联通）、无对外接口或只有紧密耦合的私有接口；对垂直整合有效的东西对水平整合无意义。
- 业务-IT 断层：IT 人员与业务人员需要共用概念体系（业务对齐）：业务流程、业务服务（Business Service）、业务数据对象（Business Object）、业务事件（Business Event）。抽象方向是底层（代码/脚本/消息）→ 高层（单独建模、显式描述、独立存在）。
- SOA 的回答：Alignment（以服务为中心的分析设计改善业务-IT 交流）、Service（ESB+标准交互连接异构系统，ESB/Adapter/Connector 实现非侵入式重用）、Integration（服务导向整合 SOI）。
二、开始 SOA 旅程的要点
- SOA 是长途旅程，不能一蹴而就：快步小跑、挑一两个端到端流程试点、迭代螺旋上升、“积小胜而大胜”；不能为 SOA 而做 SOA，必须有实在的业务价值动机。
- 治理三层：IT 治理（面向 IT）⊃ 企业治理（体系）；SOA 治理面向服务，管理”服务/流程”全生命周期（建模、开发、组装、部署、管理、优化）。
三、三大设计原则
1. 业务与 IT 对齐
- 传统生命周期各阶段概念分裂：分析用 use case、设计用组件对象、实现用对象过程、测试用测试案例、运营用系统应用——导致 IT 对业务变化反应迟钝。
- SOA 把”服务”作为贯穿全生命周期的一等核心概念：服务提供跨越多个用例的功能视角，内涵远超功能接口（业务功能映射、资产管理、资源配置等多视角）。
- 服务必须有明确的业务含义（合适的粒度与抽象度）：粒度越低，业务/技术依赖越强，业务变化时被迫改定义的压力越大；目标是多数业务变化通过”组装服务/变更实现”完成而不改服务定义。
- 契约设计（最好机器可读）规范参与方职责，三类契约：功能逻辑契约（业务描述、前件/后件）、运营契约（SLA/QoS）、商业契约（商务条款）。
2. 保持灵活性
- 设计抽象的粗粒度服务适配更广需求；定义层次不变、靠实现层次变更吸收变化。
- 适当粒度的使能服务支持组装：核心逻辑相似的场景（一般订单 vs VIP 订单）用细粒度服务组装成不同粗粒度服务。
3. 松散耦合
- 指服务消费者↔提供者之间：契约层抽象减少技术依赖；调用层用中介保持双方技术透明；Web Service 技术保证平台中立。
- 服务实现替换（换提供方、新版本）对消费者透明。
- 隔离关注划分业务架构与技术架构；服务架构分 5 层：服务消费者 / 业务组装 / 服务 / 服务组件 / 现有系统——层间契约不变则层内变化不上溢。
四、SOA 方法学与既有方法学的关系
| 方法学 | 覆盖域 | 与 SOA 的关系 |
|---|---|---|
| BPM 流程建模 | 业务领域分析 | 不能发现/定义服务，但其结果是 SOAD 的重要输入（业务组件/流程/目标→服务发现依据） |
| EA/SA 架构 | 结构领域 | 缺业务蓝图；SOAD+BPM 分解出的服务可作业务蓝图指导 EA，EA 参考架构又是服务实现依据 |
| OOAD | 单应用内部分析设计 | 只到类和对象，缺业务/架构蓝图；其抽象、隔离关注等原则被 SOA 继承；服务模型反过来给 OOAD 提供蓝图 |
五、IBM SOMA（Service-Oriented Modeling and Architecture）
三阶段逐步精化的迭代：服务发现 → 服务规约 → 服务实现。
- 服务分析输入：业务领域/业务功能域（全局理解业务、组织服务层次结构）、业务流程（流程分级，第一级是 SOAD 主入口）、业务目标（补漏）、现有系统（发现服务与实现设计前提）。
- 服务发现三种方式：
- 自上而下（领域分解）：业务流程逐级分解到”有业务含义的最小单元”；
- 自下而上（已有资产分析）：验证或发现新服务候选；
- 中间对齐（业务目标建模）：保证与业务对齐的关键服务不被前两种遗漏。
- 服务规约：形成业务与 IT 互动的服务契约（输入输出消息、安全约束、响应时间、业务规则、业务事件、消耗、依赖关系等）；服务暴露三规则——业务对齐（支持流程与目标）、可组装（技术中立、自包含、无状态）、可重用（跨应用复用降本）。
- 服务实现：现有系统分析（架构/接口/技术特征）→ 服务分配到组件（IT 组件差距与映射）→ 服务实现决策（包装现有 vs 重构；复用已包装应用/外包/自建）→ 服务基础设施设计（人工服务容器、支持 choreography/orchestration 的流程引擎）。
六、SOA 计算环境基础组件
服务运行时环境（Service Runtime）、企业服务总线 ESB（服务集成基础设施）、服务网关、服务注册库、服务编排引擎（Choreography Engine）；系统可高度分布、异构。