1. 服务生态系统
1.1 服务组合
- 面向服务的应用逻辑，遵循面向服务的设计原则，采用服务和服务组合加以实现。
- 服务组合由多个装配在一起的服务所构成，用以提供对业务任务或过程进行实现的功能。
- 由于面向服务倾向于将服务打造为无关的企业资源，即服务和它的调用者之间是无关的，一个服务可能被多个消费者程序所调用，它们能在不同服务组合中组合同一个服务。
1.2 服务库存
- 服务库存是在组织或组织的合理部分边界内，一组独立标准化并治理的完备服务。
- 服务库存可以按照服务模型进行分层：
- 应用服务层：紧密和实现相关的较小功能单元抽象出来的服务。
- 业务服务层：直接满足调用者、消费者需求的服务
【根据实现、设计上的特征分类】
- 任务-中心：以任务为中心的业务服务（任务服务）
- 实体-中心：以实体为中心的业务服务（实体服务）
- 编排服务层：（可选的服务层）服务组合的一种实现，一般由领域专家实现，使用平台中立语言（文本化的标记语言，一般为 XML）来描述服务组合的业务逻辑。
- 在构建前，服务库存的蓝图就已设计完毕了。
- 服务库存的演化阶段：
- 初始服务交付项目（按需开发）
- 服务是中立的，独立于当前软件系统，独立于调用它的服务系统或应用。
- 混合应用和成长中的服务库存
- 服务的数量持续增长，服务组合的可能性也持续增长，但是服务库存仍然尚未完成。
- 服务库存基本构建完毕
- 服务库存的演化基本完成。随着服务库存的增长，潜在的服务组合的复杂度也随之提升。
1.3 服务生态系统
- 当服务库存按照面向服务的方式进行良好的规划和设计、经过长时间演化、已经基本完备；该组织的服务系统均已合理地转向面向服务的实现，那么该组织内的服务生态系统就被构建起来了。
- 包含分析、设计、实现、治理、演化等···
- 治理：由于共享计算，通过网络以统一的接口调用服务，故需要提供相应的计算资源，来尽量满足所有人的需求
- 演化：
- 兼容性演化：接口不变，后台实现发生变化
- 非兼容性演化：接口也需要改变
- 从消费者角度出发：
- 可以被同时、独立调用的，用于满足消费者需求的服务被称为垂直服务（消费者直接调用的服务）
- 垂直服务可以由多个可重用的跨领域的公共服务所构成，这些服务被称为水平服务（不直接被消费者调用的服务）
- 垂直服务和水平服务不是互斥的；二者的区别的唯一标准就在于在某一特定场景下，是否被消费者直接调用
【注】当水平服务被消费者直接调用，此时就是作为垂直服务。
2. 面向服务的计算
2.1 定义
- 从泛型角度出发 面向服务的计算（SOC）是一种新型计算泛型。该泛型以服务作为基本概念，以支持快速和低成本开发，和异构环境中分布式应用的灵活组合。
- 从软件架构角度出发 面向服务的计算（SOC）是一组使用面向服务的架构（SOA）来表达计算的概念、原理和方法。在面向服务的架构（SOA）中，使用带有标准接口的独立构件服务来构造软件应用。
- 从服务角度出发 为了在业务服务和 IT 服务之间建立连接，并进一步改进业务服务，面向服务的计算（SOC）涵盖了运用计算和信息技术建模、创建、操作和管理业务服务的科学和技术。
- 从软件工程的角度出发 面向服务的计算（SOC）涵盖了使用服务作为基本抽象元素，采用工程化方法，对服务系统进行分析、设计、开发、测试、部署、管理等活动所涉及的理论、技术和方法。
2.2 软件应用构造阶段
- 面向服务 vs. 面向对象
- Services-Oriented Analysis vs. OOA
- Services-Oriented Design vs. OOD
- Services-Oriented Implementation vs. OOP
- Services testing, Sevices Deployment and Services management
内部：IT 特性支撑（技术上的目标）
- Flexibility：软件系统能够以灵活多变、快速构造的方式加以实现
- Robustness：出现 bug 能快速定位、快速替换，甚至无缝切换
- Extensibility：全新特性被引入到服务系统时可以灵活、快速、代价越小越好地应对
- Business Requirements Fulfillment：业务和技术上的相关性，良好地处理业务领域专家和 IT 专家的交流问题
- Reusability and Productivity：服务的可重用性、复用（以上目标的基础）
外部：业务上的支持（商务上的目标）
- Vendor Diversification Options：服务供应商的服务拥有统一中立的标准接口
- Intrinsic Interoperability：基于服务构造的服务生态系统中的服务系统之间应该潜在的可互操作性
- Organizational Agility：企业组织内部甚至可以不用以人事为基本单位进行企业的划分，而是以服务作为基本单位来组织企业
- Federation：所有为企业提供了服务的服务提供商都可以以联盟的方式加以组合
- Reduced IT Burden：由于复用减少了重复开发 IT 资源的成本负担
- Business and Technology Alignment：由于面向服务的交流方式更有利于 IT 专家和业务领域专家的交流
- ROI（投资回报率）：面向服务的计算会带来商业上 ROI 的增加
3. 面向服务 vs. 面向对象
特点 | 面向服务的计算 | 面向对象的计算 |
|---|---|---|
方法论 | 通过紧耦合的类进行应用开发，应用架构为基于继承关系的层次式架构，从构造函数——通过类或模型——到系统设计（自底向上） | 通过定义松耦合的服务来进行应用开发，并将服务组装成可执行的应用，从系统模型到服务模块，从服务抽象定义到服务实现绑定，通过搜索获得可用的服务实现（自顶向下） |
抽象和协作层次 | 往往由一个团队来负责应用的开发，并负责整个生命周期。开发者必须了解应用领域知识和编程 | 开发任务由三个独立方承担：应用程序开发者、服务提供方和服务代理。其中，应用开发者需要了解应用逻辑，但不需要了解具体的服务实现；服务提供者需要编程能力，但不必了解使用服务的应用；服务代理进一步对服务提供方和应用开发者进行解耦 |
代码共享和复用 | 代码复用通过类成员的继承和库函数加以实现。其中库函数在编译时引入，且往往是平台相关的 | 代码在服务层次复用。服务使用标准结构，并发布在 Internet 库中。服务是平台无关的，且能够被查找并远程调用。服务代理支持系统的服务共享（共享计算） |
动态绑定和重新组合 | 在运行时将名称和方法进行关联。方法必须在应用部署前链接到可执行的代码 | 在运行时将服务调用和服务进行绑定。可以在应用部署后，在进行服务选定（选定由服务代理实现）。这一特色使得应用可以在运行时重组 |
重组 | 多在设计时决定导入的组件 | 可以动态改变应用系统中服务的组合关系，以及服务定义与服务实现之间的绑定关系，即实现动态地添加、修改、删除各个服务节点 |
组件通讯接口 | 与平台和语言有关 | 与平台和语言无关。组件间通过平台标准协议通信，如 XML、WSDL 和 SOAP |
系统维护 | 用户需要时常升级软件，并且在执行升级时，应用必须停止 | 通过互联网升级系统，因为服务多运行在远程服务器上，用户通过互联网进行访问。维护对用户透明 |
可靠性 | 在设计时决定可靠性的方法 | 对于服务提供者，每个服务相对简单，更加可靠。对于应用程序存在多个满足同一需求的服务，可用将故障服务的节点断开并重新绑定到备份服务节点上，获得不间断的应用系统 |
软件拥有 | 软件作为产品销售，为用户所拥有 | 软件存在并执行于独立的服务提供商的设备上，用户按照每次对服务使用付费，而不是按照软件产品付费 |
- 从设计角度和实现角度来看：
特点 | 面向对象的计算 | 面向服务的计算 |
|---|---|---|
耦合 | 提倡重用和松耦合，但是预先定义的类依赖导致更多的对象紧密绑定 | 服务的松耦合由功能和服务合约给定 |
粒度 | 为支持不同规模的任务，支持细粒度接口（API），粒度之间差距悬殊 | 鼓励粗粒度的接口（服务描述），通讯消息中包含尽可能多的任务相关信息，粒度之间差异较小 |
作用域 | 对象作用于更小，更有针对性（往往基于一个软件系统） | 服务作用域显著不同（往往基于一个服务生态系统） |
前瞻性 | 鼓励处理逻辑与数据的绑定从而产生对象，前瞻性较弱 | 鼓励创建活动-无关的、由消息驱动的服务，前瞻性较强 |
状态性 | 数据和逻辑的绑定，导致带状态的对象 | 服务尽可能保持无状态性 |
组合 | 在支持对象组合的同时也支持对象的继承，从而导致紧耦合 | 支持松耦合服务的组合 |
【注】具体实现中，由于服务是一个与实现无关的网络构件，故服务内部可以使用面向对象的方式来实现。
