deepread13｜案例13 面向服务架构SOA（服务识别三法ESB集成治理案例）详解

ONEPSOFT | 软考学习知识库

---

deepread13｜案例13 面向服务架构SOA（服务识别三法ESB集成治理案例）详解

一、知识点定位

• 主要教材出处：第 15 章 面向服务架构设计（15.8 ESB/注册表模式、15.9 服务划分、15.10 实施过程、航空集成案例）。
• 在考试中的角色：案例高频（企业服务集成、SOA 实施、ESB 总线设计必考），选择题考服务识别三法、ESB 四层架构、服务治理 PEP、服务粒度/无状态。
• 与 #6 关联：#6 讲 " 是什么 "，本条讲 " 怎么做 "——ESB 功能、WebService 三剑客、设计原则都衔接。

一句话定位：SOA 落地三件事——识别服务（自顶向下业务分解 / 自底向上遗留资产 / 目标服务树）、设计服务（外粗内细 + 无状态 + 松耦合）、集成治理（ESB 总线 + 注册表 PEP）。案例常考 " 企业怎么用 SOA 整合老系统 "。

---

二、教材原文精摘（第 15 章，原封不动）

【服务识别三法】原文：

①自顶向下（领域分解）：从端到端业务流程逐层分解至业务活动，每个业务活动都是最小业务单元，业务活动树每节点都是服务候选者；变化分析区分易变/稳定部分。

②自底向上（遗留资产分析）：建立已有系统功能模块目录，发现重复/可复用模块，包装成服务发布；结果是可重用服务列表。

③目标服务（目标服务建模）：从业务目标分解子目标，子目标分派给服务实现，形成 " 目标服务树 "。

【服务粒度与无状态】原文：

暴露在整个系统外部的服务推荐粗粒度接口，细粒度用于内部；可用 BPEL 由细粒度操作组成粗粒度服务接口。

SOA 服务应独立、自包含、无状态：实现时不依赖前一个请求状态，不依赖其他服务上下文；无状态接口供多使用者重用最好。

【设计原则】原文：

无状态；单一实例；明确定义接口 (WSDL)；自包含模块化；粗粒度；松耦合（使用者只见接口，位置/实现/状态不可见）；重用；互操作。

【ESB 集成架构（4 层）原文：

SynchroESB 基于 SOA、以 ESB 为底层：①服务总线层（底层支持）；②数据转换与适配器层（接入）；③流程整合层；④用户交互层（统一信息入口）。

【服务治理（注册表 PEP）原文：

服务注册表是 SOA 治理主控制点（策略执行点 PEP），驱动服务合同/策略/元数据开发发布管理；治理功能：①服务注册（提供者公布功能/位置/方法/绑定）；②服务位置（消费者查询符合要求的服务）；③服务绑定（消费者用合同开发代码调用）。

【航空集成案例】原文：

服务建模：Ramp Coordination 流程分解为两个业务组件，输出 Retrieve Flight BO / Ramp Coordination / Check Spot / Check Unloading / Check Loading / Check Push Back 等 6 服务。Check Push Back 现人工、将来可自动化重实现，无需改流程（服务可替换性）。Event Service 经 ESB 的 JMS Pub/Sub 分发 " 航班到达 " 事件，应用间不再点对点，耦合极大缓解（松耦合）。Retrieve Flight BO 是 Federation Service，聚合乘务/机务/订票系统信息（服务聚合重用）。

---

三、系统解读（逐段讲透）

• 针对服务识别三法（案例核心）：这是 " 怎么找出服务 " 的方法——
• 自顶向下：从业务流程往下拆到最小业务活动（=服务候选）。像做 WBS。
• 自底向上：从已有系统找重复功能模块，包装成服务复用。像盘点已有资产。
• 目标服务：从业务目标倒推 " 哪些服务实现这个目标 "。像目标分解。

三种可组合用。

• 针对服务粒度/无状态：对外粗粒度（少接口、消息大、交互频度低），内部细粒度；无状态（不依赖上下文）才能被多方重用——这是 SOA 设计铁律。
• 针对 ESB 集成 4 层：总线层（消息骨干）→适配器层（接老系统）→流程层（编排）→交互层（统一入口）。这是企业整合老系统的标准架构。
• 针对服务治理（PEP）：注册表是治理 " 主控制点 "——注册/位置/绑定三功能（呼应 #6 UDDI）。治理=管合同/策略/元数据，保证服务可控。
• 针对航空案例：经典展示——业务分解出服务、服务可替换（人工→自动不改流程）、ESB 事件解耦（Pub/Sub 取代点对点）、Federation 聚合重用。案例题直接套这个模板。

核心一句话总结：SOA 落地=识别（自顶/自底/目标三法）+ 设计（粗粒度 + 无状态 + 松耦合）+ 集成治理（ESB 四层 + 注册表 PEP）；航空案例是全套样板——分解出服务、可替换、ESB 事件解耦、聚合重用。

---

四、工程实践举例（土木工程视角）

你做土木工程，"WBS 分解/总包集成/构件复用 " 与 SOA 工程实践同构：

• 服务识别·自顶向下 ↔ WBS 工作分解：从总流程（如 " 建一栋楼 "）逐层拆到最小工作包（基础/主体/砌筑/装修），每工作包=服务候选——正对应 " 业务活动树每节点是服务候选者 "。
• 服务识别·自底向上 ↔ 已有构件/标准图集复用：盘点已有系统重复功能模块包装成服务↔把企业已有标准构件/定型图集包装成 " 可复用构件库 " 发布——正对应遗留资产分析。
• 服务识别·目标服务 ↔ 项目目标分解：总目标 (如期竣工)→分目标 (进度/质量/成本)→任务 (各工序)↔目标服务树（目标→子目标→服务）。
• 服务粒度（外粗内细）↔ 对外总包界面粗、内部工序细：给业主/监理的界面是粗粒度 " 分部分项 "，内部再细分工序——正对应外粗内细。
• 无状态 ↔ 工序独立：某工序不依赖上道工序现场状态（像无状态服务），好并行、好替换——正对应无状态可重用。
• ESB 集成 4 层 ↔ 现场集成平台：总线层↔现场物流总线；适配器层↔对接各分包系统接口；流程层↔施工组织流程编排；交互层↔统一项目管理入口——正对应四层。
• 服务治理（注册表 PEP）↔ 总包统一管理：注册表管合同/策略/元数据的主控制点↔总包对分包合同/规范/资质的统一管理点（PEP）；注册/位置/绑定↔分包登记/查询/签约调用。
• 航空案例·服务可替换 ↔ 工序可替换：Check Push Back 人工→自动不改流程↔某工序人工→机械化工法替换不影响总流程——服务可替换性。
• 航空案例·ESB 事件解耦 ↔ 事件总线解耦：Pub/Sub 取代点对点↔现场事件广播（如 " 混凝土到场 " 广播给各相关方）取代逐一通知，耦合大降。

知识点 ↔ 工程实践 对照表

教材知识点要素	你的实践场景对应	映射说明
服务识别·自顶向下	WBS 工作分解	业务活动树=服务候选
服务识别·自底向上	标准构件库复用	遗留资产包装
服务识别·目标服务	项目目标分解	目标→子目标→任务
服务粒度（外粗内细）	对外总包界面粗/内细	分部分项 vs 工序
无状态	工序独立	不依赖上下文
ESB 集成 4 层	现场集成平台	总线/适配/流程/入口
服务治理 PEP	总包统一管理	合同/策略主控制点
航空案例·可替换	工序工法替换	不改总流程
航空案例·ESB 事件	现场事件广播	Pub/Sub 解耦

当知识点涉及服务识别三种方法时，补充结构：

流程图（结构化呈现）

1. 自底向上:已有系统功能目录→复用模块包装成服务
2. 目标服务:业务目标→子目标→目标服务树
3. 怎么识别服务?
4. 自顶向下:业务流程逐层分解→业务活动树=服务候选

运维视角提示：ESB 集成 4 层里 " 流程整合层 + 用户交互层统一入口 " 本质是运维统一管控面——所有老系统经适配器接入、经总线互联，运维一处可观测全局（呼应 #6 运维视角）。服务治理（注册表 PEP）让服务 " 可控、可查、可替换 "，运维变更有章法。SOA 整合老系统 = 用 ESB+ 治理把 " 蛛网式点对点 " 变 " 总线式可控 "，运维从救火变治理。