面向服务的分析与设计 - SOAD

文献信息

作者：Olaf Zimmermann (IBM Germany), Pål Krogdahl (IBM Sweden)
会议：OOPSLA 2004, Vancouver, Canada
来源：IBM Enterprise Integration Solutions & IBM Business Consulting Services

摘要

服务导向架构(SOA)是一种新兴的企业应用架构风格。虽然SOA强化了软件工程的基本原则（信息隐藏、模块化、关注点分离），但将抽象层级提升到了业务流程和企业架构建模层面。现有方法如OOAD、EA框架和BPM只能部分支持SOA。本文提出了一种跨学科的分析和设计方法SOAD，并概述了其基本元素。

核心概念

SOA的三层架构

层次	企业视图
业务层	业务流程
服务层	软件服务
组件层	软件组件

SOAD的核心要素

服务质量的判定标准：

良好的服务促进灵活性和敏捷性
低耦合、封装和信息隐藏
服务命名对领域专家可理解
服务粒度要适当（尽可能是粗粒度）

SOA质量因素：

松散耦合（接口契约依赖）
位置透明性
协议独立性
多平台互操作性
粗粒度和无状态抽象
服务注册表存在

SOAD方法论

四大支柱

面向对象分析与设计(OOAD)
- 使用用例模型作为基础
- 从类级别提升到服务级别
- CRC卡片→SRCP卡片(Service, Responsibilities, Collaborations, Policies)
企业架构(EA)
- Zachman框架的应用
- 从部署聚焦转向服务聚焦
- 定义服务间的接口和SLA
业务流程建模(BPM)
- 端到端的业务流程视图
- BPEL可执行流程模型
- 业务流程与服务编排的关系
服务特有的创新元素
- 服务概念化（识别候选服务）
- 服务分类和聚合
- 语义中介
- 中间Meet-in-the-middle过程
- 策略和方面
- 服务 Harvesting 和知识中介
- 人的因素

服务识别方法

直接业务分析：

业务流程建模
利益相关者访谈
产品管理访谈（支付和计费模型）

间接技术：

组织结构图咨询
营销演示术语分析
现有用例模型参考

领域分解：

FODA方法
目标模型创建
子系统设计

SOAD设计原则

服务粒度原则：

尽可能粗粒度，但不损失相关性、一致性和完整性
不同协议绑定可访问不同抽象级别的服务
相关服务可捆绑成更粗粒度的服务定义

命名规范：

服务使用名词
操作使用动词
企业级命名方案（XML命名空间、Java包名）

反模式：

不可重用的功能不应作为服务
依赖同步通信的实现不是好的SOA候选
安全关键系统（如导弹预警）不适合纯SOA风格

服务层级映射

微观到宏观：

业务流程 → 业务流程服务 → 软件服务 → 软件组件

示例：人力资源管理域

业务层：招聘流程、员工服务
服务层：招聘软件服务、员工软件服务
组件层：职位组件、申请表组件、员工记录组件、职业组件

实施考虑

组织因素

文化冲突：OOAD与BPM阵营的术语和技术差异
最终用户参与方式需要改变
治理至关重要
知识管理程序必须建立

阻力管理

常见问题：“这不就是另一个CORBA吗？”
需要主动的抑制因素管理
重用策略涉及信任问题

与现有方法的关系

RUP的不足：

集成：当前观点聚焦于自上而下和绿色field开发
架构：需要将架构理解为软件服务的组织，而非组件的嵌套
组件：需要确保正确理解UML定义的组件概念

最佳实践

确保软件服务尽可能映射到跨企业重复的通用业务服务
服务定义在可识别为有意义业务功能的粒度级别
不为服务而创建服务
限制服务中的业务逻辑量
服务提供者和服务消费者应由不同的从业者设计开发
在服务概念化和实现过程中应用敏捷、迭代和增量过程

模型方程

SOAD = (OOAD + BPM + EA) ++

其中++表示额外的创新元素：

服务识别
服务分类和聚合
语义中介
中间Meet-in-the-middle过程
策略和方面
服务harvesting和知识中介
人的因素

个人笔记

这是一篇关于SOA方法论的重要论文，提出了SOAD（Service-Oriented Analysis and Design）作为连接OOAD、BPM和EA的桥梁。论文的核心观点是：

SOA不仅仅是技术架构，更是一种方法论
需要跨学科的方法来解决服务识别、分类和聚合的问题
强调业务与IT的紧密联系（business meets IT）
提出了具体的服务设计质量和粒度原则

对于企业架构师和SOA设计师具有重要参考价值。

知识库

探索

面向服务的分析与设计-SOAD-OOPSLA2004