2.1 服务与服务系统

2.1.2 服务系统的组成要素：

  • 顾客和目标
  • 输入输出
  • 使能者（人力，信息，物理）
  • 环境

（顾客和输入的区别？）

图片.png

1. 更加抽象化：

  • 服务参与者
    • 顾客(consumers)：接受最终服务的组织/人；
    • 提供者(service providers)：提供最初服务的组织/人；
    • 使能者(enablers)：一系列用以帮助建立、设计、启动、部署服务的其他角色，协助在顾客和提供者之间建立交互关系。视服务系统的复杂程度，使能者可分为1-层使能者、2-层使能者和辅助使能者等多个层次。
  • 服务资源
    • 软件(Software)
    • 硬件(Hardware)或设备(Equipment)
    • 资源的能力(Resource Capability)
    • 服务环境(Service Environment)
      • 产品型资源、独占型资源、共享型资源；
      • 可复用型资源、消耗型资源
  • 服务信息
    • 资源类信息
    • 指令类信息
  • 服务交互行为
    • 交互过程(Interactive Process)、活动(Activity)与动作(Action)

2. 参与者之间的关系：

图片.png

！服务价值网(Service Value Network, SVN)（参与者之间的关系）：**
LINK：https://wiki.mbalib.com/wiki/%E4%BB%B7%E5%80%BC%E7%BD%91%E6%A8%A1%E5%9E%8B
描述服务参与者之间价值交换关系的有向网络结构

  • 节点：表示服务参与者(组织、企业、角色、人、等)；
  • 有向边：表示参与者之间的价值交换关系及其方向；
  • 边的内容：被交换的价值(产品、知识、金钱、经验、市场影响等)

图片.png
**

3. 要素之间的关系：

图片.png
**

2.1.3 服务生命周期

软件系统的生命周期：
用户提出需求 -> 需求分析 -> 系统设计 -> 系统开发/测试 -> 软件实施 -> 软件运行 -> 软件维护 -> 软件报废
服务系统的生命周期：
服务模式创新 -> 服务设计与建模 -> 服务系统实现 -> 服务系统运行 -> 服务系统维护、演化与重构

服务狭义生命周期 SVLC

从服务系统运行的角度：服务价值的生命周期
① 双方找寻(Bilateral Searching)：服务系统协助在众多顾客和提供者之间建立一个沟通的渠道，并遵循特定标准，帮助有需求的顾客找到可满足其需求的提供者，或者反之。
② 双方协商(Bilateral Negotiation): 双方进行协商，形成服务协议(SLA)。
③ 单方准备(Uni-lateral Preparation)：价值准备阶段(实现该价值之前所做的必要准备)；服务系统协助将顾客和提供者的众多服务要素(人员、资源、行为等)按照特定模式组合到一起，确定彼此间的交互机制和协议。
④ 协同生产(Co-Production)：实现价值；价值的加工、产生、价值转换、传递、合并、分解等。顾客和提供者开始交互，直到服务结束。
⑤ 传递(Transferring)：服务价值的传递。
⑥ 使用(Usage)：使用价值，包括价值的转换、传递、合并、分解等。
⑦ 支付(Payment)：支付价值，实现价值传递。

图片.png

2.2 服务工程与方法论

2.2.1 服务工程与其内涵

图片.png

  • “服务”：顾客与服务提供者之间为协同创造价值和共担风险而进行的交互过程。

  • 服务系统：对各类服务要素及其之间关系的一种配置，用以支持顾客与服务提供者之间的交互，从而帮助双方实现既定的价值

  • ！ 服务工程 与 软件服务工程是两个东西

服务工程：用来描述和定义、设计、建立、实施、运行维护和动态重构服务系统的理论、方法和工具
图片.png
从宏观角度看，服务工程可以看作是 ——

  • 一种设计和开发新服务的途径；
  • 一种设计和开发支持服务运作的服务系统的途径。**

从微观角度看，服务工程可以看作是 ——

  • 连接服务业务与可执行服务系统的一种途径；
  • 一个过程，被划分为若干个阶段，逐步逼近目标系统；
  • 服务模型驱动的过程，使用模型描述服务，通过模型转换在业务领域与计算领域之间建立映射关系，从而实现可执行的服务系统；
  • 由一组工程化的模型、方法、原则、工具支持。

2.2.2 服务工程方法论

  • 方法论： 方法的集合
  • 实践得到
  • 实际上可理解为可复用模板

(1) 服务模型
(2) 服务建模方法 （画图）
服务建模是一个按照模型驱动(model-driven)方式将现实业务和需求转变成服务模型并最终指导系统实施生成的过程；
(3) 服务系统构建 （实现）（服务构件体系结构SCA，ESB，SOMA）
(4) 服务质量与性能评价
(5) 相关支持工具和平台
(6) 服务系统实施指南
系统选型 项目准备 系统建设 系统交付 持续改善

2.2.3 典型服务工程方法论

服务工程方法论之一：SOA服务方法论

**

  1. SOMA方法论（SOA的方法论之一）（面向服务的建模与体系结构，Service Oriented Modeling

and Architecture，IBM）：

  • 识别
  • 设计
  • 实现服务(services)
  • 用来支持服务的构件(components)
  • 服务组合
  • 服务间的协同(choreography)
  1. Sybase：面向服务的应用系统开发方法 (Service Oriented Development of Application, SODA)
  2. 面向服务的统一过程(Service-Oriented Unified Process, SOUP)

    服务方法论之二：模型驱动的服务方法论 (自顶向下)

    模型标准：UML、EDOC Profile、BPMN
    底层实现：Web Service、SCA、BPEL

    例子1：模型驱动的服务工程方法论：
    服务工程过程分为：分析、战略设计、开发、实施四个阶段；每个阶段对应的服务模型分别为    需求模型、企业模型、执行模型和IT处理模型

    例子2：模型驱动的服务方法论SMDA：
    图片.png
    SMDA建模过程：三层模型：
    服务需求模型——Service Requirement Model (SRM) 服务协议
    服务行为与能力模型——Service Behavior and Capability Model (SBCM) 服务行为和所需资源(how)
    服务执行模型——Service Execution Model (SEM) 具体的服务执行动作和具体的资源(step to step)
    服务执行系统——Service Execution System (SES)
    SRM->SBCM->SEM：从需求到系统的转换，逐渐细化、逐渐具体化。

服务方法论之三：基于领域工程的服务方法论 （自底向上）

该类方法的基本过程与传统软件复用过程类似，分为三个阶段：
服务领域工程、服务构件工程、服务应用工程。

  • 服务领域工程针对某一领域的群体顾客需求来建立领域模型和领域服务系统，识别可复用服务构件，并在其中嵌入一组可配置参数使其具备较高的适应性；
  • 服务构件工程用来设计、开发、管理服务构件；
  • 服务应用工程针对特定顾客的个性化需求，在领域服务系统的基础上加以配置和调整，即可得到相应的服务系统。

    服务方法论之四：语义驱动的服务方法论

    该类方法追求服务开发过程的严格性、一致性和正确性，通过形式化方法来定义服务业务需求的语义(知识、规则等)
    ，进而通过语义转换将需求映射为具体的服务设计和服务编排，进而构造相应的服务系统、

服务开发过程：服务业务需求->服务语义（模型）-> 服务模型 -> 服务系统实现

2.3 服务模型

模型(model)是对系统中的某些理论或现象的图解性描述
**

服务模型应具备的描述能力(1)

提供者与顾客之间的交互(co-production) (参与者)

  • 基于交互的协同生产是服务的主要特征，体现为服务业务流程的交互/互操作，同时也体现为软件服务系统之间的集成与互操作。
  • 服务模型需重点刻画各参与者之间如何相互协作的过程。

私有与开放 (参与者)

  • 服务各参与者所完成的功能包含了两部分：私有部分与开放部分。
  • 前者是参与者其内部完成的业务，对外不开放；后者则是该参与者与其他参与者之间进行服务交互的业务，需要对外公开。
  • 服务模型应能针对这两部分业务分别进行刻画，并关注二者之间的分离与连接

服务模型应具备的描述能力(2)

实体化与虚拟化

  • 广义的服务系统中既包含了Web Service等软件，也包含了诸如人、资源等物理实体。服务模型需要覆盖这两个方面。
  • 针对后者，需要刻画清楚现实世界的实物，需对实物进行虚拟化，通过软件模型的手段(内部实现、外部接口等)对其进行描述。

耦合与解耦——“面向服务”思想的重要特征

  • 松散耦合：将服务参与者隔离开来，交互两边通过预先定义的标准接口与协议进行交互，而某一方的改动并不会影响到另一方。
  • 通过松散耦合，可支持服务系统的灵活配置和动态演化。
  • 为了设计松散耦合的服务，在进行服务建模时，需要对现实中错综复杂的服务业务进行精细解耦，使服务尽可能保持独立，从而确保服务业务的敏捷性。

服务模型应具备的描述能力(3)

组合与协同

  • 通过组合小粒度服务形成大粒度服务，以达到业务的灵活变化与软件务重用。
  • 服务模型需要至少覆盖三个层面：
    • 可独立存在的小粒度服务（基本服务）；
    • 服务组合：描述复杂服务内部的执行步骤以及这些步骤间的关系；
    • 服务协同：描述多个组织或服务之间通过交互完成复杂服务的过程。

。。。。。。。。。。。

2.3.2 服务视图及其模型

图片.png

2.3.3 服务开发各阶段典型模型

**

服务蓝图

图片.png
图片.png

BPML

LINK; https://www.jianshu.com/p/6f38a0275e98
要素：活动、事件、网关、连接对象

泳道(Swim-Lane)：用以区分不同功能和职责。有2类泳道：

  • 池(Pool)：代表流程中的一个参与者。它可以用作一个图形容器来与其他的池相分隔，通常在交互流程中出现。各个池中的活动通常是有自身流程的。
  • 道(Lane)：是池的子划分（垂直或水平的），用于活动的组织和分类。道用来按角色划分活动，流程可以在一个池中跨道流转；但在同一个池中，消息流通常不跨道流转。

同个参与者不同角色
图片.png

WSDL

图片.png

服务设计阶段的典型模型-OWL-S

LINK：https://www.w3.org/Submission/OWL-S/
OWL-S是Web服务和语义Web的结合，主要是为了解决Web服务描述和发现以及业务组合的语义表示。

OWL-S包括三个组件：**

  • ServiceProfile：描述服务的功能，即这个服务是做什么的。服务搜寻代理通过ServiceProfile实现服务匹配，寻找到满足服务请求者需求的Web Service；
  • ServiceModel：描述服务是怎么做的，即服务的具体实现细节；
  • ServiceGrounding：描述怎样访问服务。

可以说，WSDL与UDDI使Web服务实现了自动化，OWL-S使得Web服务实现了智能化。

服务组合/协作阶段的典型模型

服务协同(Choreography)：将多个零散的、分别由多方提供的服务/业务流程按照彼此之间的协同关系组织起来，支持多方的交互行为。

  • 侧重于不同服务之间的消息传递的次序与规则，以保证期望的协同行为。
  • 无需完全由一个组织所拥有；也无需中心控制；
  • Collaboration ≈ Choreography

BPEL（Business Process Execution Language）

BPEL（Business Process Execution Language）：业务流程执行语言，是一种使用XML编写的用于自动化业务流程的编程语言。
BPEL4WS（BPEL for Web Services）：面向Web服务的过程建模语言。
**
BPEL的作用是将一组现有的服务组合起来，从而定义一个新的Web服务；BPEL提供了一种XML注释和语义，用于指定对基于WSDL的Web Services进行流程编排并确定Web服务之间的业务流程，实现Web Services之间的组合。

BPEL的基本构成要素

  • 过程中的基本功能单元：活动
  • 活动之间的次序关系：
    • ①先后次序
    • ② 多分支
    • ③ 循环
    • ④ 并发与同步
    • ⑤ 非确定性选择
  • 过程的相关数据：容器
  • 错误处理机制：、
  • 补偿机制：


。。。**