南京大学《面向服务的软件工程》复习笔记

1. 服务、服务系统与面向服务的泛型

服务

• 什么是服务
  • 为客户提供的非持久性的无形的体验
  • 单一或一系列的活动，具有无形的天然属性，发生在客户和服务提供方的交互中，为客户提供解决方案
• 服务模型 vs. 制造模式
  • 产出：服务 vs. 产品
  • 交互：双向 vs. 单向
• 制造和服务的融合
  • 以制造模式为主，更加定制化和长尾化
  • 发展趋势越来越偏向于服务
• 服务发展趋势
  • 单纯的制造持续减少，服务产业持续增长
  • 服务变得越来越复杂（场景、规模、逻辑）
  • 引入 IT 系统对服务的执行提供支撑（有无服务雇员均可）

服务系统

• 服务系统
  • 用以实现业务服务的 IT 系统
  • 只关注 IT 使能服务（包含 IT 服务和非 IT 服务）
    • KPI（关键绩效指标）不同
    • 需求管理不同
    • 变化的步调不同
  • 大量的软件系统都是服务系统
• 服务系统的问题
  • 服务系统的复杂性
  • 服务系统的灵活性
  • 专业化和外包模式
  • 计算环境的演化
  • IT 专家和业务专家间的隔阂
  • 新增价值和创新功能
  • 系列有略微差异的服务系统（产品线）

面向服务的泛型

• 命令式（过程式）泛型

  • 用程序状态和改变程序状态的语句来描述计算
  • 对冯·诺依曼式计算机的顺序执行机制的直接抽象
  • 由过程完成复用

• 面向对象的泛型

  • 用封装了数据和操作的对象以及对象之间的消息传递描述计算
  • 封装、继承、多态
  • 为变化而设计
    • 使用设计模式（与泛型无关）
  • 最大的问题：对象所抽象的东西仍然是面向计算描述（实现）的
    • 底层实现逻辑的变化和上层实现接口变化都会使得对象发生变更和修改

• 基于构件的泛型

  • 构件：模块化的、可部署、可替换的软件系统组成部分（面向功能单位），封装了内部的具体实现并对外提供统一接口
  • 将软件开发转变为：以构件的创建、构件的管理以及复用已有构件组装形成应用为基本活动
  • 优点
    • 构件对外提供统一接口，针对特定业务功能进行抽象，业务接口极少发生变更
    • 构件实现的功能单位比整个业务逻辑小很多
  

• 面向服务的泛型

  • 服务：是自治、开放、自描述、与实现无关的网络构件
  • 服务是中立的，独立于当前软件系统，独立于调用它的服务系统或应用
  • 将软件开发转变为：：以服务的创建、服务的管理以及复用已有服务组装形成应用为基本活动
  • 通过网络，使用标准方式互联（不再是共享代码和设计，而是共享计算）
  • 服务：功能相关，简单且相对稳定，由 IT 专家开发；过程：应用相关，复杂多变，由业务专家开发，可以被封装为服务
  

2. 服务生态系统与面向服务的计算

服务生态系统

• 服务组合
  • 面向服务的应用逻辑，遵循面向服务的设计原则，采用服务和服务组合加以实现
  • 服务组合由多个装配在一起的服务所构成，用以提供业务任务或过程进行实现的功能
  • 面向服务倾向于将服务打造成无关的企业资源，一个服务可以被多个消费者程序调用，能在不同的服务组合中组合同一个服务
• 服务库存
  • 在组织或组织的合理部分边界内，一组独立标准化并治理的完备服务
  • 服务库存可以按照服务模型进行分层
    • 应用服务层（必要）
    • 业务服务层（必要）：以任务为中心 / 以实体为中心
    • 编排服务层（可选）
  • 在构建前，服务库存的蓝图应当已经设计完毕
  • 演化（按需开发，龙卷风模型：可重用的东西越来越多）
    • 初始服务交付项目
    • 混合应用和成长中的服务库存
    • 服务库存基本构建完毕
• 服务生态系统
  • 分析、设计、实现、治理、演化 $$\rightarrow$$ 构建起服务生态系统
  • 从消费者角度出发
    • 垂直服务：可被同时、独立调用，用以满足消费者需求的服务
    • 垂直服务可由多个可重用的跨领域的公共服务，即水平服务，构成
    • 垂直服务和水平服务不是互斥的，只要在某一场景下被消费者直接调用即是垂直服务

面向服务的计算

• 面向服务的计算
  • 从泛型角度出发
    • 面向服务的计算（SOC）是一种新型计算泛型，该泛型以服务作为基本概念以支持快速和低成本开发，和异构环境中分布式应用的灵活组合
  • 从软件架构角度出发
    • 面向服务的计算（SOC）是一组使用面向服务的架构（SOA）来表达计算的概念、原理和方法
    • 在面向服务的架构（SOA）中，使用带有标准接口的独立构件服务来构造软件应用
  • 从服务的角度出发
    • 面向服务的计算（SOC）涵盖了运用计算机和信息技术建模、创建、操作和管理业务服务的科学与技术，从而在业务服务和 IT 服务之间建立连接，进一步改进业务服务
  • 从软件工程的角度出发
    • 面向服务的计算（SOC）涵盖了使用服务作为基本抽象元素，采用工程化方法，对服务系统进行分析、设计、开发、测试、部署、管理等活动所涉及的理论、技术和方法
    • 面向服务的分析 vs. OOA
    • 面向服务的设计 vs. OOD
    • 面向服务的实现 vs. OOP
    • 服务测试、部署和管理
• 面向服务的目标
  • 技术目标：灵活程度；鲁棒性；可扩展性；业务和技术的相关性；复用和可重用性
  • 商业指标：实现供应商中立；潜在的可互操作性；企业灵活的组织化；形成商业联盟；降低 IT 成本；提高业务和技术的一致性；增加投资回报率

3. 面向服务的架构和 Web Service

面向服务的架构

• SOA 架构

  • 从架构方面整体支持面向服务泛型的基本概念性架构模型

  • 一种业务-IT 结合的方法，应用依赖于现有的服务来实现业务过程

  • 实现 SOA 主要包括：

    • 面向服务的企业
    • 采用服务开发应用
    • 采用服务对应用进行封装，便于复用

  • SOA 三角操作模型（引入第三方消除服务提供方和调用者间的紧耦合，可支持运行时确认服务提供者）

    

• SOA 的特点

  • SOA 的好处

    • 从 IT 的角度
      • 松耦合，消除假依赖（复用）
        • 语言、平台、厂商中立
        • 消除时间依赖
        • 消除访问地址依赖
        • 消除访问协议依赖
      • 服务间接寻址（灵活）
    • 从业务角度出发
      • 保护企业投资，提高 IT 资源作用，促进 IT 资源复用
      • 提升企业灵敏度
      • 支持企业外包管理模式

  • 从“双角度”出发的 SOA

    • 在不同粒度上提供了本质性的指导：业务层、过程层、中间件层、编程层

    • 在每个层次中按照“自顶向下”方式，将较大单元分解为较小的、以服务为中心的单元

    • 在每个层次中按照“自底向上”方式，将可使用的较小单元组织成较大单元，提供全新服务

      

• SOA 参考架构

  
  • 水平层：对功能性需求加以满足
    • 服务提供者（后台）
      • 操作型系统层：现存的打包应用 / 客户应用 / 遗留系统
      • 服务组件层
        • 实现服务的代码容器
        • 向下依赖于操作型系统层中的打包组件，向上依赖于服务层中的服务和业务过程层的业务过程
        • 实现方式包括 Java 类、EJB、.NET 组件等
        • 可能实现多个方法，但只有一部分会被封装成服务
        • 从调用角度出发，负责完成输入转换和输出配置的自动化逻辑
      • 服务层（公共部分）
        • 将 SOA 三角操作模型扩展为综合逻辑层次，以支持服务注册、服务分解、服务发现、服务绑定、接口聚合和生命周期管理
        • 以服务簇为核心概念
        • 负责定位合适的服务提供者，并绑定到具体的目标服务接口
        • 以服务组合的形式提供新的服务
    • 服务消费者（前台）
      • 服务层（公共部分）
      • 业务过程层
        • 以组合和分解的方式来处理业务逻辑
        • 采用业务流程构建 SOA 解决方案
        • 主要组合方式（两者在能力上是等价的）
          • 编排：引入中心协调者（主流方式）
          • 编导：没有中心协调者，根据脚本完成协作
      • 消费者层
  • 垂直层：提供系统支持机制、满足非功能性需求
    • 集成层
      • 在服务请求者和服务提供者之间，完成服务请求的中介、路由和转换
      • ESB
    • 服务质量层（QoS）
      • 从各方面提供解决方案层级的 QoS 管理
      • 不关注服务层级的 QoS 控制，着眼于为解决方案层级的 QoS 控制提供支持、跟踪、监视和管理
    • 数据架构层
      • 方便集成来自不同开发方的服务，为领域相关的数据架构提供统一的表达和支持机制
    • 治理层
      • 提供用以确保 SOA 解决方案的设计原则

Web Service

SOA 是概念层级的架构模型，其他技术都能用来实现 SOA 模型，如组件没服务、REST 服务等

• Web Service：面向服务事实上的行业协议（基于 Web Service 的 SOA）

  • XML 定义数据并完成信息交换
  • XML schema 定义数据结构
  • Namespace 使得 XML 元素全球可用
  • SOAP 定义平台 / 技术无关的消息传递方式
  • WSDL 定义平台 / 技术无关的服务能力/调用方式，使得构建服务簇和服务仓库成为可能
  • WS-BPEL / WS-CDL 使用 XML 脚本，以平台 / 技术无关的方式定义服务组合
  • UDDI，WSIL 完成服务的发布和查找
  • WS-* 满足各种应用的非功能性需求

• Web Service 协议架构

  

• Web Service 抽象模型

  

• Web Service 开发环境

4. XML 及相关协议

面向服务中的信息交换和数据类型

• 电子信息交换

  • 应用内部（intra=application）
  • 应用之间（inter-application）
  • 系统之间（inter-system）
  • 公司之间（inter-company）
  

• 电子信息交换方式

  • 基于二进制的方式（与实现紧密相关）
  • XML（平台中立，语言中立，基于文本结构，能表达复杂数据结构）
    • 描述服务（接口及流程），查询服务的服务需求，服务的调用请求，其他在面向服务的计算中需要执行的信息交换
    • 使用 XML Schema 脚本来对 XML 消息进行验证

XML

• XML 的概念和特点

  • 满足良好定义规则的格式化文本
  • XML 文档主要由标签和文本构成（树形）
  • XML 文档可以以 HTTP 消息 / 编程语言字符串 / 数据库 CLOB /其他文本数据的形式存储和展现

• XML 的良好格式化与合法性

  • 单根元素：单根树状结构而非森林结构

  • 元素标签规则：<label>xxx</label>，<label attr=“xxx”>xxx</label>，<label attr=“xxx” />，<label />

  • 元素嵌套规则：子元素未关闭时不能关闭父元素

  • 元素规则

    • 首字母，大小写敏感，不含有空格，不含有“xml”作为前缀
    • PCDATA（默认使用）：解析时需对预定义实体进行转义
    • CDATA（在 XML 中嵌套其他语言的文本）：<![CDATA[xxx]]> 不被解析，按字面意思处理

  • 元素属性

  • XML 声明：可选，出现的 XML 文档第一行，描述一致性

    

  • 合法的 XML 文档持有一个额外的词汇表，并遵循该表所定义的结构化规则（XML Schema / DTD）

名称空间

• 名称空间的作用和概念

  • 解决元素和属性名称冲突
  • 从概念上将元素和属性表达为“URI+名称”的形式，在全球范围内解决名称冲突问题
  • 作为前缀的 URI 被称为名称空间
  • 为了保证 XML 的格式良好，使用别名来代表 URI

• 名称空间的语法

  • QNames $$\rightarrow$$ prefix : localPart

  • 声明并使用名称空间

    <books:book
    	xmlns:books='http://www.libaray.com/books'
    	books:hadcover='true'/>

  • 名称空间前缀的作用域：定义该名称空间的元素（含嵌套子元素和所隶属的属性），除非子元素中重新定义了名称空间

  • 默认名称空间（只作用于子元素，不做用于属性，属性默认没有名称空间）

    <book xlmns='http://www.libaray.com/books'
          xmlns:books='http://www.libaray.com/books'
          books:hadcover='true'>
        <title>xxx</title>
    </book>

  • 重置默认名称空间

    <book xlmns='http://www.libaray.com/books'
          xmlns:amazon='http://www.amazon.com/products'>
        <title>xxx</title>
        <isbn xlmns=''>xxxxxxx</isbn>
        <amazon:skuNo>xxx</amazon:skuNo>
    </book>

XML Schema

• XML Schema 的作用和概念

  • 增加数据的表示能力，使用统一的数据结构表示方式，节省通信和集成的成本
  • 采用 XML 语法来定义数据结构和约束条件，支持名称空间，能够表达数据元素之间的关系，对 XML 文档进行验证
  

• XML Schema 的语法和机制

  • XML Schema 类型系统

    • 简单类型：不含有属性或子元素，原子类型，可用于定义其他类型，有40余种预定义的简单类型

    • 复杂类型：可以含有属性、子元素，可用于定义其他复杂类型，不能用于定义其他简单类型

    • 定义新的简单类型

      <xsd:simpleType name='quantityType'>
          <xsd:restriction base='xsd:Integer'>
              <xsd:minInclusive value='2'/>
              <xsd:maxInclusive value='5'/>
          </xsd:restriction>
      </xsd:simpleType>
      <xsd:element name='quantity' type='quantityType'/>
      
      <xsd:element name='color'>
          <xsd:simpleType name='quantityType'>
          	<xsd:restriction base='xsd:string'>
              	<xsd:enumeration value='red'/>
                  <xsd:enumeration value='green'/>
              	<xsd:enumeration value='blue'/>
          	</xsd:restriction>
      	</xsd:simpleType>
      </xsd:element>

    • 排序符

      <xsd:sequence></xsd:sequence>
      <xsd:choice></xsd:choice>
      <xsd:all></xsd:all>

    • 含有属性的元素

      

  • 将 XML Schema 定义的元素与名空间进行关联

    

  • 寻找 XML Schema

    

5. Web Service 核心

SOAP

• SOAP 的作用和概念

  • 通过网络来传递 XML 消息
  • 提供了一种标准的方法，使运行在不同平台、使用不同的技术和编程语言的应用程序可以互相进行通信
  

  • 从概念上提供了单向的、不带状态的消息交互范式

  • 提供了以可扩展的方式传送应用相关信息的架构

  • 提供了 SOAP 节点在接收到 SOAP 消息后所需执行的必要操作

  • 不关心所携带相关数据的语义（envelope）

  • 不关心 SOAP 消息路由、可靠消息传输、防火墙穿透等底层相关事项

  • SOAP 的使用方式（处理模式）

    

  • SOAP 的交互模式

    • RPC 模式：同步的请求 / 应答交互模式；发送请求并等待响应
    • 面向文档模式：异步交互模式；发送复杂的 XML 文档并等待通知，结果会在处理后发回

• SOAP 的语法和机制

  • SOAP 的结构

    

  • SOAP 绑定

    • 在抽象的消息交互框架中，SOAP 消息需要使用底层协议完成传输
    • SOAP 绑定完成 SOAP 消息的封装、处理和传输（如 HTTP、SMTP、MIME、HTTPS 绑定等）

  • SOAP 的处理模型

    • 用 XML 打包请求
      • 将接口名作为根节点
      • 方法和参数作为结点
    • 将请求发给服务器
      • 不创建自己的 TCP/IP 信息，利用 HTTP
      • 将请求封装成 HTTP POST 请求格式发出
    • 服务器接收到请求，解码 XML，处理请求，以 XML 格式返回响应
      • 与请求比较，方法的结点名字变为请求的方法名后缀 Response
      • 客户程序知道自己调用了哪个方法，根据方法名后缀 Response 寻找调用方法的返回值

• 思考：SOAP 为什么被设计成两块？实际 SOAP 如何利用这两个信道？

  • 被设计成 header 和 body 两块，一方面分离了控制信息和主要数据，让信息结构更加清晰；另一方面，在复杂模式中，header 中的头块信息可以和中间节点进行角色上的转变
  • body是必须的部分，内嵌的 XML 是完成当前任务的主要数据；而如果是⼀些附加的、用来协助完成的控制信息，则放在 header 中

WSDL

• WSDL 的作用和概念

  • 提供了一种基于 XML 的标准接口定义语言/服务能力定义语言，用以在服务的提供者/调用者/服务注册之间，交换必要的有关 Web Service 的信息

  • 可能携带了关于 Web Service的足够信息，也可能不够（商业上 / 技术上）

  • 用以描述网络服务的 XML 格式，将服务描述为基于消息（面向文档 / 面向过程）运作的端点集合

  • 回答了：服务是用来干什么 / 服务在哪 / 如何调用，这三个问题

  • 提供了：功能 / 消息结构 / 协议绑定（抽象消息映射为具体网络传输）

  • 通常与 SOAP 和 XML Schema 同时使用

  • WSDL 2.0 信息集

    
    • 以 description 元素为根结点
    • import、include：拼装不同部门/组织定义的文档，形成完整的 WSDL 语义
    • 抽象部分
      • Types：定义消息结构，即使用到的数据结构 / 数据格式规范，独立于语言和平台
      • Interface：operation 的集合，即服务能力的集合，描述服务能力
        • operation：input、output、infault、outfault
    • 具体部分
      • Binding：把抽象的消息格式转换为具体的消息格式，即特定端口类型的具体协议和数据格式规范的绑定
      • Service：对服务整体的抽象，包含若干个endpoint
        • endpoint：将绑定与当前地址关联

• WSDL 的语法和机制

  • 定义 WSDL2.0 目标名空间

    

  • 定义消息类型

    • 内嵌式
    
    • 使用 XML Schema 的 import（不同名空间之间）或 include（相同名空间）机制
    

  • 定义接口

    

    • 四种基本 MEP

      

  • 定义绑定

    

  • 定义服务

    

  • WSDL 中的 RPC 风格

    

• 服务簇和 WSDL 版本差异

  • 服务簇中的服务，共享相同的抽象部分，具体部分采用不同的绑定、地址和实现方式

  • WSDL 1.1 vs. WSDL 2.0

    

6. Web Service 扩展

服务发布和查询

• UDDI 的作用和概念

  • 用来发布和查找 Web Service 的元服务

  • 采用 XML 格式存放注册 Web Service 的描述信息

    • 业务的基本信息
    • 分类信息
    • 注册信息
    • 服务接口的注册引用及其他属性

  • 使用注册实体记录 Web Service 的发布信息

    • 白页：名称、地址、具体联系方式等基本信息
    • 黄页：针对业务或服务进行分类的信息
    • 绿页：服务中的技术性信息

  • UDDI 的主要元素

    • businessEntitiy：商业实体的信息及其所提供的服务（对商业实体的抽象）
    • businessService：商业实体所提供的服务（对服务进行抽象）
    • bindingTemplate：如何调用一个服务（对调用服务方式的抽象）
    • Technical Models (tModel)：特定的概念和结构（对绿页的抽象）
    • publisherAssertion：表达商业关系

  • UDDI 的工作流

    

• UDDI 的语法和机制

  • 略

  • 从 WSDL 到 UDDI 的映射

    

• 使用 UDDI 进行 Web Service 的发布和查询

  • Web Service实现后（部署在通过网络能够访问的应用服务器），为了方便消费者使用，需要通过网络将服务发布在服务注册
  • 服务注册需要为服务调用者提供用以发现服务提供者极其所提供的 Web Service 的相关信息（无需提供具体实现）：
    • 服务名称
    • 服务提供者名称
    • 用来描述该服务的 WSDL 文件的 URL（作为服务合约的入口）
  • 服务消费者使用 UDDI 客户端来查询 UDDI 注册中的 Web Service
  • UDDI API
    • 对于分类、编目和管理Web服务，UDDI 注册库提供了一个标准方式，以便于能够发现和使用这些Web服务
      • 业务和提供者可以按标准方式使用UDDI来表示Web服务信息
      • UDDI 使用 SOAP 作为它的传输层
    • UDDI API 是-一个接口，可以接受封装在 SOAP 信封中的 XML 消息
      • 所有的 UDDI 交互都使用请求 / 响应模式
      • 可以使用出查询API来搜索和读取 UDDI 注册库中的数据，并可使用发布 API 来添加、更新和删除 UDDI 注册库中的数据
  • UDDI 发布 API
    • 授权：客户端可以获得相应的访问权限、获取授权令牌、终止会话和授权令牌
      • get_authtoken：将客户端记录到注册
      • discard_authtoken：终止会话，并从注册库中删除客户端
    • 保存：客户端可以在 UDDI 中添加或更新信息
    • 获取：可以获取客户端所发布的数据结构的概要数据
    • 删除：客户端可以在 UDDI 中删除信息
  • UDDI 查询 API
    • 浏览
      • 开发者可以使用浏览模式（发现 API 调用）来获取满足比较宽泛的查询标准的接入点、服务或者技术特性
      • 浏览模式中，可以使用 find_business、find_relatedBusiness、find_service、find_binding 和 find_tModel 操作
    • 下钻
      • 使用下钻模式（获取API调用）来获取更具体的功能部件
      • 下钻模式中，可以使用 get_businessDetail、get_BusinessDetailExt、get_serviceDetail、get_bindingDetail 和 get_tModelDetail操作

WS-* 协议

• WS-* 的作用和概念

  • 略

• BPEL

  • 为什么需要复合服务（复用 & 灵活）
    • 有些服务是垂直的，有些是水平的。为保证复用性，某些垂直服务被设计为由水平服务构造而来
    • 如果活动由服务实现，那么由活动构成的（商业）流程由复合服务实现
  • 如何实现复合服务
    • 在传统编程环境中，调用子服务，再把编程单元封装成服务以供调用
    • 采用标准协议的 XML 脚本描述服务组合方式

• WS-Addressing

  • Web Service 中的消息分发

    • 为了正确处理,消息接收者必须具备识别所需要调用的 Web Service 的能力
    • 由于在 WSDL 中没有定义，服务提供者在开发服务时需要自己来区分消息的不同类型
      • 在单个地址上部署单个服务时，采用 XSD，为不同的服务能力的不同消息说明不同的 QNames
      • 在单个地址上部署多个服务时， 必须在全局考虑所有服务中的消息类型
    • 如服务提供者不能达成上述目标,尤其在使用通配类型（#any, #none）时，必须提供消息分发机制
    • 在带状态的 Web Service 中，也需要消息分发机制来识别同一服务的不同实例

  • WS-Addressing 请求

    • 随机生成全局 ID 唯一标记当前会话进程
    • 为 WSDL 定义的操作引入一个字段 Action，用以区分不同操作
    • 在 SOAP 消息中增加 Go 字段，包含请求消息的相关信息
    • 在 SOAP 消息中增加 Back 字段，包含响应请求消息的相关信息
    

  • WS-Addressing 响应

    

  • 有状态和无状态的 Web Service

    • 无状态的 Web Service
      • 不获取和维护状态
      • 无上下文
      • 扩展性好、容错性好
      • 轻量级
    • 有状态的 Web Service
      • 为不同消费者服务，提供个人化服务
      • 持有状态
      • 支持需要协作的复杂服务
      • 需要更多编码和额外处理资源

• Web Service 资源框架（WSRF）

  • 定义带有资源的有状态的 Web Service
  • 包含四组用来通过 Web Service 接口访问内部状态的接口
    • WS-ResourceProperties
    • WS-ResourceLifetime
    • WS-BaseFault
    • WS-ServiceGroup
  • 支持资源属性的动态创建
  • 支持资源的销毁
    • 立刻销毁
    • 基于时间的计划销毁

• WS-Security

  • WS-Security SOAP 消息结构

    

• WS-Coordination

  • 用来发起、支持、完成多方参与、多消息的 Web service 协作的通用机制
  • 定义了协作服务和协作上下文，是协作 Web service 交互的框架

7. 服务生态系统的构建

面向服务的分析

目标

• 讨论需要构建哪些服务，每个服务需要封装哪些逻辑

核心

• 业务服务（隔离业务领域和应用领域的变化，服务编排的对象，实现复用，促进面向服务）

流程

• 定义流程自动化需求（文档化的需求描述为服务候选建模的依据）
• 识别现有的自动化系统（确保服务边界不重叠）
• 对服务候选建模（识别服务操作候选，并将其分组）

业务分析方法

• 业务流程管理模型（BPM）
• 实体模型

业务服务派生类型

• 以任务为核心：灵活，较少分析工作，需对多个用例和业务流程模型进行分析以识别公共性，复用潜力有限
• 以实体为核心：稳定，较多分析工作，不包含业务流程逻辑，复用潜力高

业务服务与编排

• 组合以任务为核心的业务服务及以实体为核心的业务服务
• 在不影响业务服务和应用服务的前提下进行业务规则和业务逻辑的变更

面向服务的设计

从服务候选（逻辑）派生出具体的服务设计（物理），然后装配到实现业务流程的抽象组合中

设计过程

• 组合 SOA：

  • 选择服务层

  • 定义核心的 SOA 标准

    
    • WS-I

  • 选择SOA扩展

    • 选择 SOA 特征
    • 选择 WS-* 标准
    • 选择 BPEL

• 设计服务

  • 以实体为核心的业务服务设计
    • 业务服务候选
    • 审查现存服务（确保新服务没有已经被实现）
    • 定义消息 schema 类型，并在 WSDL 中导入
    • 提取抽象服务接口（确保服务候选操作适当；在 WSDL 文件中创建 portType/interface 并定义 operation；通过 message 元素和 part 子元素引用 XSD schema 类型讲提供给每个操作的逻辑处理所需输入输出值形式化）
    • 应用面向服务原则（可复用，自治，无状态，可发现）
    • 标准化并完善接口服务（审查并应用现存设计标准和原则；修订服务设计；验证 WS-I 基本概要的一致性要求）
    • 扩展服务设计（添加新操作，添加新参数）
    • 识别必要处理（进一步识别应用服务）
    • 最终的抽象服务定义
  • 应用服务设计
    • 应用服务候选
    • 审查现有服务（避免服务内冗余；考虑使用第三方服务）
    • 确认上下文（重新评估服务候选中的候选操作分组）
    • 提取初始服务接口
    • 应用面向服务原则
    • 标准化并提炼服务接口
    • 为服务候选引入推理性特性
    • 识别技术约束（物理接入点，安全性约束，响应时间，底层系统可用性，部署位置相关的环境因素，底层应用逻辑的技术限制，管理需求，潜在的 SLA 需求）
    • 最终的抽象服务定义
  • 以任务为核心的业务服务设计
    • 业务服务候选
    • 定义工作流逻辑
    • 提取服务接口
    • 应用面向服务原则
    • 标准化并完善服务接口
    • 识别需要的处理
    • 最终的抽象服务定义

• 设计面向服务业务过程，组合服务构建出业务流程

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

8. 面向服务设计的原则

目的

• 提高内在互操作性
• 增强联合
• 增加厂商多样化选择
• 提高业务和技术的一致性
• 提高投资回报率
• 提高组织敏捷度
• 降低 IT 负担

标准化服务合约

服务可组合性

• 遵循相同标准，使用相同风格

  • 服务功能描述的标准化
  • 服务数据表示的标准化
    • 避免非标准化数据间的频繁数据转换
    • schema 被单独设计和实现，与使用它的服务操作分离
    • 采用“schema 集中化”的设计模式，对每个信息集合定义“官方”schema
    • 可以将一个企业划分为多个分离的领域，每个领域都可以被独立地进行标准化和治理
    • 除集中式的Schema外，定义特定服务相关的额外 schema 时，可引用和封装现有 schema 脚本
  • 服务策略标准化
    • WS-Policy 定义为服务合约添加了一个单独的潜在抽象层次
    • 使得逻辑能以单独的策略断言的形式存在于物理上独立的策略定义文档中
    • 多层次的标准化

• 标准化服务合约在服务设计中的应用

  • 数据表示标准化和转换的避免
  • 标准化与粒度
    • 以任务为核心的业务服务：粗粒度
    • 以实体为核心的业务服务：细粒度
  • 标准化服务合约与服务模型
    • 通用类型模板
    • 为同一种服务模型应用同一组设计标准和命名惯例
  • 标准化服务合约设计与其他原则
  • 服务合约设计相关风险
    • 版本化（服务合约的演化）
    • 技术依赖
    • 开发工具缺陷

服务松散耦合

最小化依赖关系

• 服务合约耦合的类型
  • “逻辑-合约”耦合（积极耦合）
    • 合约优先，服务逻辑对服务合约的紧密耦合
    • 服务合约对服务逻辑无耦合，在相同的服务合约下，可以替换或修改服务逻辑
  • “合约-逻辑”耦合（消极耦合）
    • 从现有的方案逻辑当中生成 Web Services，自动生成合约和数据结构
    • 增加技术、功能和实现的耦合级别
    • 缩短服务合约生命周期并限制服务的长期演化
  • “合约-技术”耦合（消极耦合）
    • 后台的实现技术方案/调用的通讯协议被反映到服务合约中
    • 暴露后台实现方式，技术不能进行灵活变更
  • “合约-实现”耦合（消极耦合）
    • 底层实现依赖于特定编程环境中的特定实现机制（物理数据库和相关的物理数据模型、遗留系统API、用户和群组账户以及相关的物理目录结构、物理服务器环境和相关的域名、文件名和网络路径）
    • 实现相关的特性和细节可能会在服务合约的内容中体现出来
  • “合约-功能”耦合（消极耦合）
    • 由一个服务所封装的逻辑被专门设计为支持服边界之外的功能体（上层进程耦合、”服务-消费者”耦合、任务服务（特意的功能耦合））
    • 缺乏可复用性，但若本身就不需要被复用则可以允许产生”合约-功能”耦合
  • “消费者-实现”耦合（消极耦合）
    • 没有隐藏实现细节，消费者绕过服务合约，直接使用其他入口访问服务
  • “消费者-合约”耦合（积极耦合）
    • 本质上形成了松散耦合跨服务关系的基础
    • 会产生多种直接和间接耦合场景
    • 合约集中化和技术耦合
      • 采用合约集中化，将对服务的访问控制在合约内
      • 没有使用类似 Web Service 的开放技术平台的情况下，合约集中化可能会导致贯穿整个企业的技术耦合的产生
    • 验证耦合：消费者程序遵循技术服务合约中的数据模型（XML Schema 表示的输入输出消息的复杂类型，XML Schema 建立数据类型、约束、基于信息的大小和复杂度的验证规则）
• 服务松散耦合在服务设计中的应用
  • 耦合与面向服务
  • 服务松散耦合与粒度
    • 涉及“消费者-合约”耦合
    • 过粗操作粒度，不必要的额外处理；过细操作粒度，过多服务往返开销
    • 过粗数据粒度，接受无用的额外信息；过细数据粒度，没有足够信息，需要额外调用
    • 约束粒度决定消费者验证逻辑的数量
  • 耦合与服务模型
    • 以实体为核心的服务
      • 解耦的服务合约
      • 与业务实体本身高度耦合
    • 应用服务
      • 往往是高度耦合的（实现耦合）
      • 通过标准化服务合约，避免“消费者-实现” 的间接耦合
    • 以任务为核心的服务
      • 有时是在功能上耦合的
      • 有时构成“服务-消费者”耦合
    • 编排服务
      • 避免技术耦合
      • 无法避免“合约-实现”耦合
  • 服务松散耦合与其他原则
  • 服务松散耦合的相关风险
    • “逻辑-合约”耦合的限制
      • 同一底层逻辑对应多个合约，建立多个入口，每一入口向不同类型消费者暴露不同的服务能力
    • Schema 耦合太“松散”
      • 强调服务的兼容性演化能力，过分简化服务合约，追求减少消费者依赖，仅确定了一些非常通用的数据类型（弱类型），验证并处理弱类型，增加服务所需的性能要求
      • 服务合约发布的信息少，消费者程序需要知道更多关于服务实现逻辑的信息，产生消极耦合

服务抽象

最小化元信息的可用性

• 信息隐藏与元抽象类型

  • 服务发布的信息传达了它的目的和能力，给用户提供了关于如何调用和使用该服务的详细信息

  • 服务没有发布的服务信息用来保护它和未来用户之间形成的耦合关系的完整性，保障在服务在合约的前提下进行演化的能力

  • 服务抽象原则就是为了获得信息隐藏的正确平衡点

• 服务抽象原则

  • 服务合约中发布的信息越多，“消费者-合约”耦合就会越深
  • 向设计服务消费程序的人呈现的信息越多，他们所知的底层逻辑、平台和服务相关的细节就会越多，导致事实上的“消费者-实现”耦合

• 对服务元信息进行抽象

  • 技术信息抽象
    • 发布：调用程序需要的技术、程序交互需要的技术
    • 隐藏：写程序使用的编程语言、程序使用的系统资源
  • 功能信息抽象
    • 决定了程序的哪些能力通过技术合约是可见的
  • 程序逻辑抽象
    • 对外界隐藏程序的内部细节
  • 服务质量信息抽象——描述服务的行为、限制和交互需求
    • 服务质量数据被用来描述一个服务的行为性的、基于规则的、和可靠性等相关的元信息
      • 确保服务及时响应的并发访问阈值
      • 可用性限制，例如定期安排的断电
      • 决定服务对不同类型输入数据的处理和响应的业务规则
    • 使用策略或 SLA 等文档加以描述

• 元抽象类型的实现

  • 
  • 

• 服务抽象度量

  • 合约内容的抽象级别
    • 详细的合约
    • 简明的合约
    • 优化的合约
    • 混合的详细合约（服务能力位于不同的抽象级别）
  • 访问控制级别（源代码和设计规格）
    • 开放访问
    • 受控访问
    • 不可访问
  • 抽象级别与服务质量元信息
    • 服务质量元信息也能够适用于抽象级别和访问控制级别

• 服务抽象在服务设计中的应用

  • 服务抽象 VS. 服务封装
    • 在良好抽象的服务中，可以改变所封装的内容，而不会影响已经在使用该服务的消费者程序
  • 封装如何影晌抽象
    • 封装遗留环境的服务
      • 抽象的程度可能需要依靠底层服务适配器和相应的遗留 API 来决定
      • 访问控制可能会很难实现
    • 封装定制组件的服务
      • 拥有定制的能力使得内容和访问抽象级别能够较好的定义
    • 封装了服务的服务
      • 除服务本身外，所封装的子服务也对内容和访问抽象级别有所影响
  • 服务抽象与非技术合约文档
    • 非技术的服务描述（如 SLA）为技术合约增加了额外的规则、约束、策略、保证和担保等，这些文档由服务拥有者建立，并应当被服务消费者程序设计人员所知晓
    • 如非技术的服务描述过于详细（依赖于当前实现），也会影响到服务的演化
  • 服务抽象与粒度
    • 服务抽象鼓励发布尽可能少的细节，以便在服务随时间而演化的过程中给服务的拥有者最大的自由度，这将导致粗粒度的约束级别
    • 在使用策略时，可能导致暴露服务底层的逻辑、行为和参数选择的细节
    • 其他的面向服务原则（如服务松散耦合和服务自治），也提倡在服务合约中减少约束
  • 服务抽象与服务模型
    • 以实体为中心的服务与应用服务
      • 抽象程度往往和所封装的定制逻辑、遗留API等紧密相关
      • 需要严格的访问控制，以确保服务合约的寿命和底层逻辑的可复用性
    • 任务服务与编排任务服务
      • 无法达成过高的抽象级别
  • 服务抽象与其他原则
  • 服务抽象的相关风险
    • 多消费者耦合的需求
      • 不同消费者可能需要不同的技术接口细节，所需的抽象程度也不尽相同
      • 使用合约反规范化，提供不同级别的抽象粒度
    • 人为误判
      • 过于抽象的服务合约导致曲解或不能充分理解一个服务，从而丧失潜在的复用机会
      • 过于具体的服务合约导致对服务的行为作出与服务实现相关的假设，从而导致实现耦合
    • 安全和隐私的考虑
      • 服务合约可能暴露私有或者敏感信息（不同的使用环境、并发和冗余的服务合约内容以解决这一问题）

服务可复用性

实现通用的和可复用的逻辑与合约

• 计划中复用的度量

  • 战术上的可复用性

  • 针对性的可复用性

  • 完全的可复用性

• 逻辑集中化

  • 库存蓝图的制定能最大化发现和定义无关服务的机会，实现服务的可复用性

  • 在规范化的服务库存中，每个服务代表了一个独特的功能域，本质上意味着服务边界之间没有重叠

  • 逻辑集中化的风险

    • 项目组没有意识到服务的存在（服务没有做到充分地可发现或者可解释）：使用服务可发现性原则和集中的服务注册
    • 项目组拒绝使用这样一个服务，因为他们认为这样做会加重负担：纳入企业的设计标准等

  • 要求设计者建立消费者程序并需要特定功能时，这些消费者程序只调用指定的服务（不会描述怎样访问这一逻辑），对比合约集中化要求设计者建立消费者程序时，这些消费者程序仅通过已发布的合约访问一个服务（不需要指定为了何种目的应该访问什么服务），两者相结合构成支持最大化可复用和与消费者松耦合的高度标准化服务仓库

  • 集中化与 Web 服务

    • Web 服务的 WSDL、XML schema 和 WS-Policy 定义必须正确地表达访问一个正式逻辑体（根据逻辑集中化）的一个正式访问点（根据合约集中化）

  • 实现逻辑集中化的挑战

    • 实际企业中很难实现逻辑集中化，采用领域库存模式描述企业的子集，并在领域库存中实现逻辑集中化

• 服务可复用性在服务设计中的应用

  • 服务可复用性与服务建模
    • 面向服务分析阶段需要考虑服务的可复用性、服务自治和服务可发现性
    • 在服务建模中，需要精化已有的服务能力候选，使其更加一般化和可复用；定义额外的服务能力候选，这些能力是在构成服务建模过程的基础的业务流程自动化所需之外的
  • 服务可复用性与粒度
    • 服务粒度
    • 能力粒度
    • 数据粒度
    • 约束粒度
  • 服务可复用性与服务模型
    • 以实体为中心的业务服务和应用服务强调无关性，提供适合封装可复用逻辑的功能上下文
    • 以任务为核心的业务服务通过将无关服务从处理业务流程的逻辑中解脱出来，也支持了可复用性
  • 服务可复用性与其他原则
  • 服务可复用性的相关风险
    • 文化上的考虑
    • 治理上的考虑
    • 可靠性上的考虑
    • 安全上的考虑
    • 商业设计需求上的考虑
    • 敏捷交付上的考虑

服务自治

实现独立的功能边界和运行时环境

• 服务自治

  • 将库存中的每一个服务配置为独立的构成单元
    • 拥有越高的控制权，就拥有越高的自治
    • 拥有越高的自治，就拥有越强的可靠性和可预测性
  • 表现了可以独立执行自身核心服务逻辑的能力

• 服务自治类型

  • 运行时自治：服务对其运行时执行环境的控制权的大小

  • 设计时自治：服务拥有者对于服务设计的管理权的大小

• 服务合约自治

  • 一个服务合约所表达的能力范围不应与另外一个服务的能力范围发生重叠
  • 服务合约自治与实现无关，从而与运行时自治无关
  • 当服务合约是标准化的，并与它的底层实现解耦时，倾向于服务合约自治
  • 服务规范化
  • 合约反规范化
  • 共享自治：封装遗留系统和技术的服务具备较低的自治性

• 服务逻辑自治

  • 部分隔离
    • 底层服务构件是专用的并可以被隔离
    • 数据库、目录和其他资源仍然是可被服务与企业的其他部门共享的

• 完全自治

  • 服务对自身的运行时环境拥有绝对的所有权
  • 对服务的设计和架构可以自顶向下进行控制
  • 功能隔离：服务构件和物理数据模型是专用的，但是服务位于一个与其他服务共享的服务器上
  • 绝对隔离：服务构件和相关的数据模型都位于专用服务器上
  • 设计时隔离：从设计开始，就对服务设计、数据模型和宿主环境等，拥有完全的管理权

• 服务自治在服务设计中的应用

  • 服务自治与服务建模
    • 服务分析和服务建模中需要考虑服务自治
    • 面向服务分析中，包含对已有自动化系统进行收集的步骤
    • 已有自动化系统的信息影响到服务系统所能达到的自治级别
  • 服务自治与粒度
    • 相同的合约，不同的实现可能带来不同的自治级别
    • 服务中的不同能力重要程度不同，可能要求不同程度的自治性
    • 对可靠性、性能和安全需求，倾向于将能力分散到单独的服务中去，可能导致服务粒度降低
  • 服务自治与其他原则
  • 服务自治的相关风险
    • 错误地判断服务的范围：反模式
    • 包装服务和遗留逻辑封装：无法改变的自动化系统无法回避自治问题
    • 对服务需求的过高估计：过于追求高自治

服务无状态性

实现可适应的、和状态管理无关的逻辑

• 状态管理延迟与无状态性设计

  • 服务的可复用性和可组合性，强调服务处理逻辑的优化，通过尽量减少资源消耗，满足尽可能多的消费者程序的需要

  • 服务组合的复杂性上升的同时，整个组合生命周期内需要被保留和管理的活动相关数据的数量也在增加

  • 为了使服务的可扩展性最大化，也为了服务库存的最大化利用，服务和其周围的架构可被设计为支持状态管理职责的委托和延迟，从而采用无状态性改进服务设计

• 服务无状态性度量

  • 非延迟的状态管理（无状态性从低到没有）
  • 部分延迟存储（较低的有状态性）
  • 部分架构状态管理延迟（中等无状态性）
  • 完全架构状态管理延迟（高度无状态性）
  • 内部延迟状态管理（高度无状态性）

• 状态管理

  • 

• 无状态性在服务设计中的应用

  • 消息作为一个状态延迟选项
  • 服务无状态性与服务实例
    • 在有状态的情况下，同一服务的多个不同实例处于活动且有状态时，它们构成一个服务实例池
    • 服务消费者应能够在实例池中找到特定的实例并与之通信
    • WS-Addressing 协议提供了相应机制
  • 服务无状态性与粒度
    • 当一些服务在运行时需要接收和处理大范围的状态数据时，它们相应的合约粒度一定会受到影响
    • 尤其可能会需要降低数据和约束粒度，以使它们能接收更大量的数据和范围更广的数值
    • 与其他设计原则不同，服务无状态性可以同时影响消息体和消息头的粒度（WS-*）
  • 服务无状态性与服务模型
    • 实体服务
      • 对实体服务中的所有能力，以及对于一个服务库存中的所有实体服务，进行标准化状态管理规范
      • 对消息传递的业务和上下文信息（和规则）的数据表示进行标准化管理，以确保一致的互联性
    • 应用服务
      • 有时会被故意设计成违反本条原则，设计一系列服务，作为有状态的系统资源来替代服务管理状态数据
      • 这种类型的应用服务所提供的“横切”功能就是状态管理自身
      • 使得其他服务的无状态性更容易实现
    • 任务服务
      • 以任务为中心的服务有一个以业务流程为中心的功能范围，它们被特意设计成用于封装上下文规则
      • 如何管理状态数据有多样化方法（较大规模的组合倾向于延迟上下文数据，较小规模的任务在活动期间保有状态数据）
    • 编排任务服务
      • 编排任务服务总是被期望保持有状态
      • 如果一个过程持续保持不活动状态超过了一定的时间，状态数据将会被保存在一个数据库中，直至需要被重新激活
  • 服务无状态性与其他原则
  • 服务无状态性的相关风险
    • 对于架构的依赖
    • 增加的运行时性能需求
    • 低估交付代价

服务可发现性

实现可交流的元数据

• 设计时发现 vs. 运行时发现

  • 由人来完成发现的手动过程称为设计时发现
  • 建立具有动态发现查询能力的程序和服务，被称为运行时发现

• 可发现性元信息

  • 功能性元数据
  • 服务质量元数据

• 服务可发现性在服务设计中的应用

  • 服务可发现性与服务建模
    • 服务可发现原则要求以统一的方式，从服务生命周期的开始，记录所有元数据
    • 在服务建模过程中，业务和技术专家一起协作，来建立服务候选
  • 服务可发现性与粒度
    • 粒度中立
  • 服务可发现性与策略断言
    • 在 WS-Policy 框架中，可以使用策略断言来展示者服务消费者设计人员的优先和所应遵从的选项
    • 既能表达功能性元数据，又能表达服务质量元数据
    • 仅面向技术专家
  • 服务可发现性与其他原则
  • 服务可发现性的相关风险
    • 可发现性在实施后的应用
    • 由不擅交流的人员来应用本原则

服务可组合性

最大化可组合性

9. 补充与例题

一些概念补充

• Web 服务是实现SOA的核心技术，但 SOA 并不等同于 Web 服务。Web服务是⼀套技术体系，可以用来构建应用解决方案，解决特定的消息通信和应⽤集成问题。而 SOA 是⼀种软件架构，不局限于某种技术组合（如 Web 服务），它超越技术范畴，甚⾄可以用来组织公司。
• 企业服务总线（ESB）是SOA基础架构（basic frastruct）的关键组件，是⼀种消息代理架构，管理消息通信、服务交互等等。
• WSDL：Web 服务描述语言，基于 XML，但它才是 Web 服务的核心。因为它描述 Web 服务提供的操作（服务能力）以及这些操作接收和返回的参数。WSDL 包含的信息：服务做什么，应该如何使用它们，它们在哪里。也就是说提供者和调用者都需要参考 WSDL，从这个意义上来说 WSDL 是核心。

试结合相关协议和框架，描述⼀个 web service 从创建开始到被最终服务消费者调用的全过程中对服务的建模、查询和调用的全过程

• 服务的建模：

  • XML 定义了 Web 服务中的消息交换格式，使用 XML Schema 定义不同的数据结构，引入 Namespace 使得 XML、XML Schema 中的元素和属性全球唯⼀且全球共享
  • SOAP 提供了⼀种标准的通信方法，使得运行在不同平台、使用不同的技术和编程语言的应用程序可以互相进行通信，服务的发布、查找、调用，都通过 SOAP 传递 XML 消息
  • WSDL 对服务能力、服务中使用的数据结构以及传输绑定给出定义和描述；提供了⼀种基于 XML 的标准接口定义语言/服务能力定义语言，用以在服务的提供者/调用者/服务注册之间，交换必要的有关 Web Service 的信息
  • 对于大多数服务，用以上三个协议和框架可以完成建模；对于⼀些更为复杂的服务，如复合服务或者是带有非功能性需求的服务，还需要用到其他协议和框架完成建模
    • BPEL 定义多个服务间如何交互和合作，从而将⼀组现有的服务根据业务流程构建起来，实现业务服务
    • WS-Policy 可以实现非功能性需求，如信息加密，权限验证等。建模完成后，服务提供者通过 UDDI 或者 WSIL 将服务发布出去。其中，UDDI 利用分页机制，让服务得到最大可能的复用和共享范围；WSIL 使用树形连接结构，适用于企业既定的服务

• 服务的查询

  • 消费者程序发送 SOAP 消息给服务注册，描述自己需要的服务
  • 服务注册查询注册表，通过 WSDL 服务合约找到⼀系列符合条件的服务
  • 服务注册将查询到的 WSDL 通过 SOAP 发送给消费者程序，让消费者程序从中选择可用的服务；或者服务注册自动化筛选出当前最符合消费者程序要求的服务，通知消费者程序

• 服务的调用

  • 消费者程序根据 WSDL 中提供的服务位置进行调用
    • 消费者和提供者基于 WSDL 中约定的接口进行消息的发送和接收
    • 当前服务可能同时被多个消费者程序使用，创建了⼀系列服务实例， WS-Addressing 提供了相应的机制，确保服务消费者能在实例池中找到特定的实例并与之通信
    • 由于创建的实例是有状态的，利用 WSRF 对状态数据进行存取，进行状态管理，提高资源利用率

以电信企业为应用背景，举例描述服务分析和服务设计的过程。并结合⾯向服务的设计原则（标准化服务合约、服务松散耦合、服务抽象、服务可复用性、服务自治、服务无状态性、服务可发现性、服务可组合性），讨论 “schema集中化” “合约集中化” “逻辑集中化” 在设计过程中的应用。

• 举例：电信企业有订购、退订套餐，账单结算等基本业务流程

• 服务分析流程

  • 面向服务分析的目标是讨论需要构建哪些服务，每个服务应该封装哪些逻辑。分析的核心是业务服务
    • 进行文档化的需求描述，定义流程自动化需求，作为服务候选建模的依据；由于电信企业发展比较完善，可以直接使用之前的需求文档分析
    • 对现有的自动化系统进行分析、识别；分析企业正在使⽤的系统具有的功能
    • 对服务候选建模，识别服务操作候选，并将其分组
  • 在面向服务分析流程中，需要考虑服务可复用性、服务自治和服务可发现性
    • 可复用性：在服务建模中，需要：精化已有的服务能⼒候选，使其更加⼀般化和可复用；定义额外的服务能力候选，这些能⼒是在构成服务建模过程的基础的业务流程自动化所需之外的
    • 自治：对已有自动化系统收集得到的信息，会影响服务系统所能达到的自治级别；比如根据信息决定保留遗留系统，那么达到共享自治，独⽴开发的可能达到逻辑自治或完全自治
    • 可发现性：从服务⽣命周期开始，尤其是在产⽣服务操作候选时，需要以统⼀的方式，记录所有元数据；在服务建模过程中，业务和技术专家需要⼀起合作，建立服务候选

• 服务设计流程

  • 服务设计过程，是从服务候选（逻辑）派生出具体的服务设计（物理），然后装配到实现业务流程的抽象组合中
    • 组合SOA：选择编排、业务、应⽤服务层中的哪些进行实现，定义核心的SOA标准，选择SOA扩展（WS-*协议）
    • 根据业务层级，分别设计以实体为核心的业务服务，应⽤服务，以任务为核心的业务服务
    • 设计面向服务业务过程，组合服务构建出业务流程

• schema集中化

  • 传统的做法是在订购服务、退订服务中使用不同的套餐数据结构，而按照标准化服务合约，所有使用的数据结构都应该被单独定义、管理，与具体的操作流程无关。采用Schema集中化的设计模式，将电信企业划分为多个分离的领域（部门），每个领域都可以被独立地进行标准化和治理，每个领域定义和管理自己的schema，作为整个服务系统的基本数据结构；在不同的服务中，使⽤这些schema，避免了频繁且不必要的数据转换；在必要的情况下，可以利用这些schema定义新的数据结构

• 合约集中化

  • 为了保证服务松散耦合，避免消极耦合，采用合约集中化，将对服务的访问严格控制，在合约内：
    • 所有的合约应该被集中管理，拥有⼀致的设计原则和设计目标；
    • 在服务⽣态系统中，任何情况都不可以绕开合约去访问具体内容
  • 服务抽象 & 服务可发现性设计服务暴露的信息
  • 服务抽象：技术信息、功能、程序逻辑、服务质量抽象
  • 服务抽象出来并对外界可用的信息就是服务合约，服务合约的设计标准会影响到其他

• 逻辑集中化

  • 为了实现服务可复用性，让消费者程序只调用指定的服务，要建立服务库存，在规范的服务库存中，每个服务代表来⼀个独特的功能域，这就要求服务边界之间没有重叠
  • 设置专家管理服务库存，应用开发人员不能直接往服务库存中增改需要的服务，只能请求当前服务库存管理⼈员进行审查，作出恰当的决策
  • 同时，服务可发现性是实现服务可复用的前提，服务自治是可复用服务潜在高性能和并行使用的保证；无状态性能提⾼服务的可用性