服务生态系统的构建

1. 服务生命周期

1.1 基本阶段

• 面向服务的分析
• 面向服务的设计
• 服务的开发
• 服务的测试
• 服务的部署
• 服务的管理

1.2 业务逻辑/应用逻辑

• 业务逻辑源自于企业业务领域，也无需求的文档化实现

1. 一般被构造为表达这些需求的流程
2. 包括任何相关的约束、依赖及外部影响

• 应用逻辑是组织成不同技术解决方案的业务逻辑的自动化实现

【注】业务逻辑和应用逻辑可以认为是针对同一个问题在不同层级上的解决方案。

1.3 服务层次

服务生态系统服务可分为三个不同类别：

• 应用服务层：针对底层应用逻辑进行封装的服务
• 业务服务层：用来满足服务调用者的业务需求的服务
• 编排层：对业务服务采用编排方式加以实现（可选层）

【注】若将应用服务和业务服务在同一个服务接口中间加以实现，则称为混合（应用）服务。

1.4 面向服务的交付策略

• 自顶向下策略——分析优先

1. 定义企业范围的相关本体（Ontology，领域知识的概念及其关联）
2. 将相关的业务模型（包括实体模型）与新的或修订后的本体匹配
3. 进行面向服务的分析
4. 进行面向服务的设计
5. 开发所需服务
6. 测试服务及所有的服务操作
7. 部署服务

【注】自顶向下策略完全发挥了面向服务的特征；但前两个步骤并不能直接产生可用软件，前期投入较高。

• 自底向上策略——按需交付、封装并集成遗留系统优先

1. 对所需的应用服务进行建模，多为混合（应用）服务
2. 设计所需的服务
3. 开发所需的服务
4. 测试服务
5. 部署服务

【注】自底向上策略完全为了应对我们迫在眉睫的某一个特定业务系统的开发的需求（多、快、好、省），并不是完整的想要用面向服务的方式最大化一系列的优势。

• 敏捷策略（折中方式）——平衡策略 服务生态系统的分析（业务人员为主、IT 人员为辅）和设计和具体服务的分析和设计（IT 人员为主、业务员人员为辅）并发进行。

2. 面向服务的分析

2.1 面向服务的分析的目标

• 在服务生态系统中（初步）讨论需要构建哪些服务、每个服务需要封装哪些逻辑

1. 定义一组预备的服务操作初选
2. 将服务操作候选分组到符合逻辑的语境（服务候选）中
3. 初步定义服务的边界，以使他们不会与任何现有的或已经规划好的服务相重叠
4. 识别封装好的逻辑（服务操作候选、服务候选）能够被复用的潜在可能
5. 确保被封装的逻辑（服务操作候选、服务候选）语境符合预期的用途
6. 定义任何已知的候选合成模型

2.2 面向服务分析的流程

• 定义流程自动化需求：文档化的需求描述，是服务候选建模的依据
• 识别现有的自动化系统
• 对服务候选建模：对服务操作候选，并将其分组到服务候选中的过程

2.3 以业务为核心的 SOA

【注】面向技术 vs. 面向业务：Web Service 仍然是面向技术的

• 面向服务的分析应以业务服务为核心

1. 业务服务分别隔离来自业务领域和应用领域的变化
2. 服务编排以业务服务为对象
3. 业务服务实现复用
4. 业务服务促进面向服务的企业

• 常见业务分析方法

1. 业务流程管理（BMP）模型：大多数组织业务分析归档的主要形式

2.实体模型：遵循 OO 规范

• 业务服务的派生类型

1. 以任务为核心的业务服务（灵活性）

• 可能来源：用例模型，BPM 流程定义
• 较少分析工作，有限复用潜力
• 需要对多个用例和业务流程模型进行分析以识别公共性

2. 以实体为核心的业务服务（稳定性）

• 来源：实体模型
• 较多分析工作，不包含业务流程逻辑，较高复用潜力

业务服务与编排（灵活）

1. 业务中心化
2. 编排能够组合以任务为核心的工作服务和以实体为核心的业务服务

• 基本的业务模型由以实体为核心的服务来表示
• 与业务逻辑相关的任务由以任务为核心的服务来表示

1. 在不影响业务服务和应用服务的前提下进行业务规则和业务逻辑的变更

2.4 服务建模的过程

• 分解业务流程
• 识别业务服务候选逻辑

识别业务流程中不应该被抽象为服务候选的步骤

• 不能或者不应该被自动化的手工流程步骤
• 流程步骤由现有遗留逻辑加以执行，且不允许被封装为服务候选

分析潜在的可复用性，具备潜在复用性的流程步骤，应充分考虑被抽象为单独的服务候选

• 抽象编排逻辑

定义由编排层完成的潜在逻辑

• 业务规则
• 条件逻辑
• 异常逻辑
• 序列逻辑

创建的编排逻辑亦为服务操作候选

• 创建业务服务候选：在创建业务服务候选时，充分考虑业务中立，引入对额外的服务操作候选的分析
• 提炼和应用面向服务原则（复用、自治）
• 识别服务候选组合

假想一系列业务流程中的通用场景

• 有助于识别当前的业务流程步骤划分是否合理
• 显示编排服务层和业务服务层之间的潜在关系
• 定义潜在的服务组合
• 突出显现当前缺失的工作流逻辑或过程步骤
• 修订业务服务候选
• 分析应用处理需求

1. 为了完成服务操作候选描述的动作，需要执行那些底层应用逻辑
2. 所需的应用逻辑是否存在，是否需要全新开发
3. 所需的应用逻辑是否跨越应用边界，即是否需要多个系统完成该应用逻辑

• 识别应用服务操作候选：不应与业务流程步骤的上下文相关
• 创建应用服务候选
• 修订服务候选组合
• 修订应用服务候选
• 保存服务候选库存（文档化或形式化方式，可选步骤）

3. 面向服务的设计

• 在面对服务设计的过程中，通过从服务候选（逻辑）派生出具体的服务设计（物理），然后装配到实现业务流程的抽象组合中
• 面向服务设计的目标

1. 确定架构扩展的核心集合（协议及版本）
2. 设定架构的边界
3. 识别所需的设计标准
4. 定义抽象服务接口设计
5. 识别潜在的服务组合
6. 评估面向服务原则的支持
7. 探究 SOA 特征的支持

3.1 面向服务的设计过程

• 组合 SOA

1. 选择服务层

• 必选：以业务核心的服务
• 对内：用应用服务封装实现
• 对外：用编排服务来封装灵活变化的流程

1. 定位核心的 SOA 标准（协议、版本）
2. 选择 SOA 扩展

• 设计服务

1. 设计以实体为核心的业务服务
2. 设计应用服务
3. 设计以任务为核心的业务服务

• 设计面向服务的业务过程
• WSDL 优先的服务设计（主要是服务合约的设计）

1. 服务被设计为精确表达对应服务候选的上下文和功能
2. 约定服务操作命名标准，从而产生标准化的接入点定义
3. 抽象地对操作的粒度进行建模，提供一致性和可预知的接口设计，从而得到消息大小以及适应于目标通讯架构的负载比例
4. 要求底层应用遵循服务设计的表示（现有服务合约，再有服务实现），否则，常会使得业务层需要组合依赖于 RPC 风格的通信的旧由组件
5. 业务服务的设计由业务领域专家辅助完成，以确保业务逻辑的精确表示

3.2 以实体为核心的业务服务设计

• 审查现存服务：服务建模时已经考虑现有服务，设计时再次审查以确保服务操作候选所表示的部分或所有功能并不存在与现有的其他服务中
• 定义消息 Schema 类型（不推荐从无到有定义类型，数据类型应该谁拥有谁定义）
• 提取抽象服务接口
• 应用面向服务原则

1. 服务可复用性
2. 服务自治
3. 服务无状态
4. 服务可发现性

• 标准化并完善服务接口

1. 审查并应用现存设计标准和原则
2. 修订服务设计
3. 验证 WS-I 基本概要的一致性要求（完成到目前为止产物的校验）

• 扩展服务设计

1. 添加新操作
2. 在现存操作中添加新参数
3. 实体为核心的服务的一组经典操作：

• Get Something
• Update Something
• Add Something
• Delete Something
• 识别必要处理：在服务建模的基础上进一步识别应用服务

3.3 应用服务设计

• 审查现有服务

1. 避免应用服务内的冗余
2. 考虑使用第三方服务（业务、实体服务几乎不可能，所以不用考虑）

• 确认上下文：在与现有服务设计所构成的上下文进行对比的基础上，重新评估由服务候选所提议的操作候选分组（在以实体为核心的服务中，由于实体模型已经预定义了上下文，故不需要此步骤）
• 提取初始服务的服务接口
• 应用面向服务原则

1. 服务可复用性：审查现存的操作候选，以确保设计的通用和可复用
2. 服务自治；确保用以执行服务操作的底层应用逻辑不强制依赖于该服务，且自身也没有依赖性
3. 服务无状态：不同的应用平台和实现环境带来的挑战（功能/性能）
4. 服务可发现性：以统一方式描述，使用元数据标注服务

• 标准化并提炼服务接口

1. 审查并应用现存设计标准和原则
2. 审查设计目标，修订服务设计
3. 验证 WS-I 基本概要的一致性要求（完成到目前为止产物的校验）

• 为服务候选引入推理性特性

1. 可能修改现有操作或引入全新操作，需回溯到第 1 步
2. 如需要调整或新加入特性时，需回溯到第 2～5 步以确保良好和一致的设计

• 识别技术约束

1. 特定功能的物理接入点（需要引用什么组件、需要调用什么 API 函数、需要激活什么适配器）
2. 与处理过程中任意部分相关的安全性约束
3. 每个处理功能的响应时间
4. 执行处理功能的底层系统的可用性
5. 与服务部署位置相关的环境因素
6. 底层应用逻辑的技术限制（尤其是当面临遗留系统时）
7. 服务所带来的管理需求
8. 潜在的 SLA（服务合约）需求

3.4 以任务为核心的业务服务设计

• 定义工作流逻辑

1. 为每个可能的交互场景定义逻辑（执行路径）
2. 便于提供定义类型、操作和消息格式的消息

• 提取服务接口

1. 根据活动图派生服务所需执行的动作集合
2. 服务其他服务的接口（WSDL）和类型（XSD Schema）

• 应用面向服务原则

1. 服务可复用性：相对较弱，仍可对子流程进行抽象，达成跨流程和流程内的复用
2. 服务自治：取决于底层子服务的自治性
3. 服务无状态：使用文档风格的 SOAP 消息来转义状态信息
4. 服务可发现性：要求相对较高，使用元数据标注服务

• 标准化并完善服务接口

1. 审查并应用现存设计标准和原则
2. 审查设计目标，修订服务设计
3. 验证 WS-I 基本概要的一致性要求（完成目前位置产物的校验）

• 识别所需要的处理

1. 鉴于复用性，以任务为核心的业务服务可能调用了以实体为核心的业务服务，应用服务以及其他的以任务为核心的业务服务。
2. 确定所需子服务已经存在或者已经完成设计，否则需要重新进行考虑

3.5 面向服务的业务流程设计

• 传统上

1. 业务流程由分析师采用建模工具设计，产生图标交给架构师和开发者实现
2. 在一个自动化解决方案中，工作流程图及其相应的文档是传达该逻辑应如何实现的唯一方式

• 面向服务的业务流程设计

1. 技术分析师和系统架构师来图形化地创建代表他们工作的工作流逻辑和业务流程图，并自动转化并对应到 BPEL 脚本
2. 更加自动化的工具使得业务分析师可以在不了解 BPEL 的前提下，完成流程的设计

4. 服务的开发、测试及其它

4.1 服务的开发

• 在具体开发平台上，使用特定语言

1. 开发定制服务
2. 包装遗留系统（查漏补缺）
3. 构建应用系统

4.2 服务的测试

• 服务的潜在访问者有哪些类型
• 能够满足所有服务策略断言吗
• 服务可能会面临怎样的异常情况
• 服务描述在多大程度上良好表达了服务语义
• 修订后的服务描述是否改变或扩展了前一版本
• 服务被组合的简易程度有多高
• 服务描述被发现的简易程度有多高
• 是否遵循了 WS-I 该要的要求
• 会出现什么与数据类型相关的问题
• 是否已经提出了所有可能的服务活动和服务组合
• 补偿过程是否已经被充分测试
• 在补偿过程汇总出现异常时，会发生什么
• 新的服务是否遵循了已有的设计规范
• 新服务是否引入了定制的 SOAP 头，如果有，是否所有的潜在调用者（包括中间节点）也需要引入，并对他们进行理解和处理
• 新服务是否引入了当前架构不支持的功能或 QoS 需求

4.3 面向服务的测试的特点

• 基于规约的测试

1. 服务用户可能没有看到或看不到源码
2. 服务提供者虽然没有看见源码，可能不知道源码会被谁使用以及如何使用
3. 服务代理了解服务规约，但是依然不知道具体的使用方法和源码

• 动态性测试
• 协同测试

1. 协同验证与确认（CV & V）
2. 独立验证预确认（IV & V）

4.4 面向服务的测试方法

4.5 WebStar

• 用以发布与服务相关的测试资产，如测试用例、测试用例的排名方法、测试生成方法、测试生成方法排名、软件可靠性模型、软件可靠性模型的排名方法
• 用以提供服务排名、测试用例排名、测试方法排名、可靠性模型排名

4.6 服务的部署

• 服务如何部署
• 基础设施是否能够适应满足所有服务的处理需求
• 引入新服务将如何影响现有的服务和应用
• 如何定位和部署在多个解决方案中复用的服务
• 引入所需要的中间件将如何影响现有环境
• 在服务引入新版本的服务描述时，是否需要和现有版本一起部署
• 需要怎样的安全设置和账号
• 为适应计划中或不可预见的扩展性需求，如何维护服务池
• 如何维护和监管具有性能和可靠性限制的包装遗留系统

4.7 服务的管理

• 如何监管服务的使用
• 为了管理服务描述文档，需要何种形式的版本控制
• 如何跟踪和管理信小溪
• 如何检测性能瓶颈