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

1. 服务

1.1 定义

服务是为客户（担任协同提供者）所执行的非持久的，无形的体验。
服务是单个或一系列活动。这些活动或多或少带有无形的天然属性，通常（不是必须）在客户和服务雇员/物理资源和产品/服务提供者的系统之间的交互中所发生。它们用来提供针对客户问题的解决方案。

1.2 服务模型 vs. 制造模型

graph LR
subgraph 服务模型
    A((服务客户))
    B[前台]
    C[后台]
    subgraph 服务提供者
        C === B
    end
    B ---|双向关系| A
end
subgraph 制造模型
    D((通用客户))
    E[产品]
    subgraph 产品提供者
        F["后台(工厂)"]
    end
    F --> E -->|未知关系| D
end

服务模型：服务的客户和服务的提供者之间的交互是双向的（相同的服务提供者面向不同的客户提供的服务是不同的）
制造模型：整个过程是单向的，产品并不是针对每个客户定制的，而是面向大众化的（客户的反馈需要通过其他另外的循环反馈到产品提供者，并在下一代产品中体现）。

现实情况中，服务和制造并不是完全割裂开来的，我们越来越倾向于在制造模式中间引入服务部分，因为服务能够更好的对于客户的需求进行定制化设计，即制造和服务的融合。

当前仍是以制造模式为主，因为大多数产品的制造仍然是单向的，即产品提供者制造出来客户买走，二者并没有进行双向的互动；但越来越偏向于服务，制造和服务进一步的融合。

1.3 服务发展趋势

单纯的制造持续减少，服务产业持续增长。
服务变得越来越复杂。
引入各种 IT 系统。

2. 服务系统

2.1 定义

服务系统是指用以实现业务服务的 IT 软件系统。

当业务服务由服务系统提供，该服务被称为 IT 使能服务（IT-enabled）。

【注】IT 使能服务系统中可能既含有 IT 服务的部分，也可能含有非 IT 服务的部分。

IT 服务和非 IT 服务是服务的不同分类，二者的区别在于：提供的手段不一样、KPIs（关键绩效指标）不同、需求管理不同、变化的步调不同（二者最大的差异）。
大多数可交互的软件系统都隶属与服务系统（操作系统不是）

2.2 服务系统的问题

服务系统的复杂性（交互式）
服务系统的灵活性（技术、平台改变）
专业化和外包模式（专业化知识）
计算环境的演化（平台的变化）
IT 专家和业务专家之间的隔阂
新增价值和创新功能
一系列有着略微差异的服务系统（产品家族、产品线）

【需解决的问题】

如何利用有限的资源去建立合适的服务系统群

如何利用有限的资源去维护合适的服务系统群

3. 面向服务的泛型

3.1 命令式（过程式）泛型

用程序状态和改变程序状态的语句来描述计算
对冯·诺依曼式计算机的顺序执行机制的直接抽象
由过程完成复用（大多数情况下复用的是计算的逻辑或流程，而不是状态）

3.2 面向对象的泛型

用封装了数据和操作的对象以及对象之间的消息传递描述计算
封装、继承、多态
Design Pattern 设计模式：为变化而设计，与泛型无关

【面向对象过程中最大的问题】

对象所抽象的东西仍然是面向计算描述（实现）的

实现会受到两方面的变化的影响：一方面为底层设计的逻辑，另一方面为实现的接口

3.3 基于构件的泛型

构件：模块化的、可部署、可替换的软件系统组成部分，它封装了内部的具体实现并对外提供统一接口
以构件的创建、构件的管理以及复用已有构件组装形成应用为基本活动

【优点】

由于构件对外提供统一接口，针对某个特定的业务功能进行抽象，当前业务接口极少发生变更

构件所实现的功能单位，相对来说，比整个业务逻辑小很多

基于构件 vs. 面向对象

方面	基于构件	面向对象
抽象视角	构件是对客观世界的实体或者实体联合能提供的功能和服务的建模；仅仅关注实体的功能和服务	对象是对客观世界基本实体的抽象，强调对实体的对应及实体的建模；涉及实体的静态属性特征
可复用程度和复用机制	以组合的方式实现复用（跨软件系统复用）	以继承的方式实现复用（单个软件系统内部）
粒度不同（涵盖功能单元）	大	小

【注】大粒度的构件内部是可以以面向对象的方式来加以实现的，一方面对外以合理的方式封装了必要的完整的功能实现；另一方面拥有着统一的接口，使得构件和构件之间可以无缝连接

3.4 面向服务的泛型

服务：是自治、开放、自描述、与实现无关的网络构件

自治：服务能够单独独立地完成一个任务（不依赖于其他构件，来完成它所需要完成的工作）

开放：对于构件而言，只要遵循了一般的协议或标准，当前服务的统一接口应该是跨公司、跨平台、全球范围之内可以相互调用的（进一步提升了它复用的可能性和范围）

自描述：服务应该自己能够描述自己完成的任务，而不应该有其他的附加手段去对于当前的服务来进行描述

与实现无关：只需提供统一接口，不用关心具体实现