服务计算
服务
服务时为客户所执行的非持久的，无形的体验
服务模型与制造模型
单纯的制造持续减少，服务产业持续增长
服务系统
用以实现业务服务的IT软件系统IT使能服务：业务服务由服务系统提供
问题
- 复杂
- 灵活
- 专业化与外包
- 计算环境演化
- IT专家与领域专家的沟通
- 价值与创新
- 服务系统家族
面向泛型
使用软件工程相关方法工具进行开发
- 复用
命令式（过程式）泛型面向对象泛型
使用设计模式应对可以预料到的变化
基于构件的泛型
| \ | 基于构件 | 面向对象 |
|---|---|---|
| 抽象视角 | 构件是对客观世界的实体或者实体联合能提供的功能和服务的建模;仅仅关注实体的功能和服务 | 对象是对客观世界基本实体的抽象,强调对实体的对应及对实体的建模;涉及实体的静态属性特征 |
| 可复用程度和复用机制 | 以组合的方式实现复用 | 以继承的方式实现复用 |
| 粒度不同 | 大 | 小 |
构件:模块化的、可部署、可替换的软件系统组成部分，它封装了内部的具体实现并对外提供统一接口。
好处：
- 接口稳定，内部实现发生变化不会导致变化扩散
面向服务的泛型
服务：自治、开放、自描述、与实现无关的网络构件
服务组合
面向服务的应用逻辑,遵循面向服务的设计原则,采用服务和服务组合加以实现。
由于面向服务倾向于将服务打造为无关的企业资源, -一个服务可能被多个消费者程序所调用,它们能在不同的服务组合中组合同一个服务。
服务库存
服务库存，是在组织或组织的合理部分边界内一组独立标准化并治理的完备服务。
分层
- 应用服务层
- 业务服务层
- *编排服务层（非必须）*
演化
龙卷风模型
- 各个服务按需独立开发
- 依赖先前的服务进行开发
- 使用开发完成的服务进行组合，达到快速开发
服务生态系统
当服务库存按照面向服务的方式进行良好规划和设计、经过长时间演化、已经基本完备;该组织的服务系统均已合理地转向面向服务的实现,那么该组织内的服务生态系统就被构建起来。
垂直服务：可以被消费者直接调用，满足消费者需求水平服务：需要组合多个服务才能提供服务
生命周期
- 分析
- 设计
- 开发
- 测试
- 部署
- 管理
服务层次
交付策略（开发方式）
- 自顶向下：分析优先
- 自底向上：按需交付，封装并集成遗留系统
- 敏捷策略
面向服务的计算
快速、低成本。在异构环境中分布式应用的灵活组合
面向对象 vs 面向服务
| 特点 | 面向对象的计算 | 面向服务的计算 |
|---|---|---|
| 方法论 | 通过定义紧耦合的类来进行应用开发应用架构为基于继承关系的层次式架构从构造函数一通过类或模型到系统设计 | 通过定义松耦合的服务来进行应用开发,并将服务组装成可执行的应用从系统模型到服务模块,从服务抽象定义到服务实现绑定通过搜索获得可用的服务实现 |
| 抽象和协作层次 | 往往由一个团队来负责应用的开发,并负责整个生命周期开发者必须了解应用领域知识和编程 | 开发任务由三个独立方承担:应用程序开发者,服务提供方和服务代理。其中,应用程序开发者需要了解应用逻辑,但不需要了解具体的服务是如何实现的。服务提供者需要编程能力,但不必了解使用服务的应用 |
| 代合共享和复用 | 代码复用通过类成员的继承和库函数加以实现。其中库函数在编译时引入,且往往是平台相关的 | 代码在服务层次复用。 服务使用标准的结构,并发布在Internet库中。服务是平台无关的，且能够被查找并远程调用。服务代理支持系统的服务共享 |
| 动态绑定和重新组合 | 在运行时将名称和方法进行关联。方法必须在应用部署前链接到可执行的代码 | 在运行时将服务调用和服务进行绑定。可以在应用部署后,再进行服务选定。这一特色使得应用可以在运行时重组 |
| 重组 | 躲在设计时决定导入的组件 | 可以动态改变应用系统中服务的组合关系,以及服务定义与服务实现之间的绑定关系,即实现动态地添加、修改、删除各个服务节点 |
| 组件通讯和接口 | 与平台和语言有关,例如C++程序难以直接和Java程序通信 | 与平台和语言无关。组件间通过标准协议通信，如XML，WSDL和SOAP |
| 系统维护 | 用户需要时常升级软件,且在执行升级时,应用必须停止 | 通过互联网升级系统,因为服务多运行在远程服务器上,用户通过互联网进行访问。维护对用户透明 |
| 可靠性 | 在设计时决定可靠性的方法 | 对于服务提供者,每个服务相对简单，更加可靠。对于应用程序存在多个满足同一-需求的服务可用过将故障服务的节，点断开并重新绑定到备选服务节点上，获得不间断的应用系统 |
| 软件拥有 | 软件作为产品销售,为用户所拥有 | 软件存在并执行于独立的服务提供商的设备上,用户按照每次对服务使用付费,而不是按照软件产品付费 |
| 耦合 | 提倡重用和松耦合,但是预先定义的类依赖导致更多的对象紧密绑定 | 服务的松耦合由功能和服务合约给定 |
| 粒度 | 为支持不同规模的任务,支持细粒度接口( API) | 鼓励粗粒度的接口( 服务描述) ,通讯消息中包含尽可能多的任务相关信息 |
| 作用域 | 对象作用域更小，更有针对性(往往基于一个软件系统) | 服务作用域显著不同(往往基于一个服务生态系统) |
| 前瞻性 | 鼓励处理逻辑与数据的绑定从而产生对象 | 鼓励创建活动无关的、由消息驱动的服务 |
| 状态性 | 数据和逻辑的绑定,导致带状态的对象 | 服务尽可能保持无状态性 |
| 组合 | 在支持对象组合的同时也支持对象的继承,从而导致紧耦合 | 支持松散耦合服务的组合 |
面向服务的架构SOA
- 面向服务的企业
- 使用服务对应用封装
SOA三角操作模型
分层
- 操作型系统层：只为一个目的服务一类特定用户
- 服务组件层：提供用以实现服务层中所定义服务的代码容器
- 服务层：服务层将SOA三角操作模型，扩展为综合的逻辑层次,以支持服务注册、服务分解、服务发现、服务绑定、接口聚合和生命周期管理。
- 业务过程层：以组合和分解的方式处理业务逻辑
编排
编导
- 消费者层：通过业务服务快速构建用户接口来满足消费者需求
web service
- xml：定义数据，信息交换
- xml schema：定义数据结构
- soap：平台无关消息传送
- wsdl：平台技术无关服务描述
- ws-bpel/ws-cdl:脚本
- uddi，wsil：服务发布与查找
抽象模型
SOAP
提供了单向、不带状态的消息交互范式一个定义了消息传输的数据抽象接口
WSDL
提供了一种基于XML的标准接口定义语言/服务能力定义语言,用以在服务的提供者/调用者/服务注册之间,交换必要的有关Web Service的信息
面向服务的分析
需要构建哪些服务，每个服务需要封装哪些逻辑
- 定义流程自动化需求
- 识别现有自动化系统
业务服务
- 以任务为核心
- 以实体为核心
服务建模
面向服务设计
从服务候选中派生出具体的服务设计，装配到实际业务流程
- 以实体为核心
- 应用服务
- 以任务为核心
服务开发
特定平台及语言：
- 开发定制服务
- 包装遗留系统
- 构建应用系统
服务设计
标准化服务合约
- 技术性
- 非技术性
版本问题：服务合约的演化技术依赖
标准化服务策略
服务耦合
- 逻辑-合约耦合
- 先设计合约，再设计底层方案逻辑
- 合约-逻辑耦合
- 根据实际设计生产合约，是一种反模式
- 合约-技术耦合
- 合约-实现耦合
- 合约-功能耦合
- 服务没有可复用性
- 消费者-合约耦合
- 接口粒度
服务抽象
为了获得信息隐藏的正确平衡点
- 抽象度量：合约内容
- 详细合约
- 简明合约
- 优化合约
服务可复用性
- 计划的可复用
- 针对的可复用
- 完全可复用
无关服务与周围环境之间保持中立或者无关服务越是无关，复用潜能越大
服务可复用性原则倾向于降低服务粒度
服务自治
当前服务不依赖于其他因素
- 运行时自治
- 设计时自治
- 服务拥有者对服务修改的自由度
风险：
- 错误判断了服务的范围，导致修改困难
- 对遗留系统的封装，修改困难
- 过度设计
服务无状态性
- 使用状态库保存状态
- 使用消息保存状态
代价：性能代价设计代价