15、基于承诺的业务建模与MAMS服务框架解析

基于承诺的业务建模与MAMS服务框架解析

基于承诺的业务建模

在业务建模中，承诺是一个核心概念。以车辆维修保险场景为例，当保单持有人请求维修时，会产生一系列承诺。维修人员通过创建新的承诺 C14 来满足承诺 C13，并解除承诺 C12，之后保险公司通过向维修人员付款来履行承诺 C12。不过，保险公司并非必须此时付款，还可能有其他情况，比如维修人员可能在保险公司付款前就完成车辆维修，即满足承诺 C14。

验证代理交互

为了验证每个合作伙伴是否遵守业务模型，我们有相应的算法。如果一个代理履行了它作为债务人的每个已解除的承诺，那么就认为它遵守了业务模型。我们将 UML 序列图作为代理交互的低级模型，代理在执行一个任务时可能会交换多条消息。例如，保单持有人可能通过向保险公司发送消息来报告事故，保险公司可能会请求额外信息，从而引发更多消息。在交互模型中，我们假设任务执行者完成任务后会发送消息声明任务完成。

以下是验证代理交互的算法：

def verifyInteractions(m, i):
    C = m.C  # 模型承诺
    CS = []  # 已满足的承诺
    CV = []  # 已违反的承诺
    T = i.T  # 交互模型中完成的任务
    for c in C:
        if eval(c.consequent, T) == True:
            CS.append(c)
    for c in C:
        if c not in CS:
            if eval(c.antecedent, T) == True:
                CV.append(c)
    return CV

该算法会遍历业务模型中的承诺，使用交互模型中声明的任务来评估每个承诺的前件和后件。承诺的前件和后件是包含任务析取的公式， eval 过程根据交互模型中声明的任务来评估这些公式。如果承诺的后件评估为真，则该承诺得到满足；如果前件评估为真而后件评估为假，则该承诺被违反。违反承诺的债务人就是不遵守给定业务模型的代理。

例如，在 AGFIL 业务模型中，考虑承诺 C10 = C(C, P, reportAccident, receiveClaim)。如果交互模型中既没有声明 reportAccident 也没有声明 receiveClaim ，那么保单持有人（P）和呼叫中心（C）都遵守业务模型。如果保单持有人报告事故，呼叫中心收到索赔，那么两者都遵守业务模型；但如果保单持有人报告事故，呼叫中心未收到索赔，那么呼叫中心违反了承诺 C10，不遵守业务模型。

业务模型的完整性

代理建立业务关系是为了实现各自的目标。一个所有代理都能实现其目标的业务模型是完整的。检查模型的完整性很重要，因为如果不完整，一些代理将无法实现其目标，可能会希望退出关系，导致业务模型不稳定。

以下是检查业务模型完整性的算法：

def verifyCompleteness(m):
    C = m.C  # 模型承诺
    A = m.A  # 代理
    for a in A:
        G = a.G  # 代理目标
        for g in G:
            GT = g.T  # 目标所需的任务
            AT = a.T  # 代理能执行的任务
            for t in GT:
                if t not in AT:
                    for c in C:
                        if c.creditor == a and t in tasks(c.consequent) and set(tasks(c.antecedent)).issubset(set(AT)):
                            break
                    else:
                        return False
    return True

该算法会检查每个代理是否能实现其所有目标。如果一个代理无法执行目标所需的所有任务，那么模型中必须有其他代理的承诺来执行剩余任务，并且该代理应该能够执行这些承诺前件中指定的任务。如果模型中有一个代理无法实现目标，算法将返回 False ，表示模型不完整；否则返回 True 。

例如，在 AGFIL 业务模型中，评估员的目标是进行索赔评估，需要执行 inspectVehicle 和 agreeToRepair 任务。评估员有能力执行 agreeToRepair ，但缺乏执行 inspectVehicle 的能力。为了使模型完整，模型中必须有其他代理承诺执行 inspectVehicle ，并且评估员应该能够执行该承诺的前件任务，比如 payAdjuster 。

与现有方法的比较

我们的方法与一些现有方法进行比较：
| 方法 | 特点 | 与我们方法的差异 |
| ---- | ---- | ---- |
| 现有高级方法 | 捕获业务组织及其价值交换，多为非正式或半正式，用于估值和盈利能力分析 | 缺乏对业务关系的严格处理和业务层面的合规性概念 |
| e3 - value 方法 | 将业务组织视为参与者，参与者执行价值活动，有价值接口概念 | 缺乏形式语义和灵活性，承诺可委托而价值接口不能 |
| Tropos | 基于参与者、目标、计划和参与者依赖的概念 | 依赖概念未对依赖者提出要求，承诺有前件可建模互惠关系 |
| Opera | 从单一设计者或经济实体的角度建模多代理社会 | 使用传统义务，缺乏承诺的灵活性 |
| Amoeba | 基于承诺协议的过程建模方法 | 创建的模型基于细粒度消息和承诺，我们的方法抽象层次更高 |

MAMS 服务框架

在当今服务全球化的时代，中小企业作为服务提供商面临诸多困难。一方面，创建服务需要技术知识；另一方面，提供服务需要购买、配置和维护必要的硬件和软件，这使得服务提供成本高昂甚至无利可图。

MAMS（Multi Access - Modular Services）项目旨在解决这些问题，它允许非技术人员根据用户需求快速轻松地创建、部署和管理服务。平台提供商作为技术专家，专注于提供服务创建工具和基本服务，以及可靠的服务托管基础设施。

相关工作

现有的服务交付平台，如 BEA WebLogic Communications Platform、IBM Service Provider Delivery Environment、Microsoft Connected Services Framework 和 HP Service Delivery Platform 等，不能满足 MAMS 的所有要求。它们大多未充分解决 IT 和电信的融合问题，对用户上下文和偏好的感知不足，不支持非技术人员创建服务，并且平台功能封闭。

一些欧洲研究项目虽然在简化服务创建方面有所尝试，但大多未使用代理技术来实现服务的自主和灵活提供。在代理社区，一些研究关注了 Web 服务与代理的集成，但对于 MAMS 项目来说，这些研究的作用有限。

MAMS 项目概述

MAMS 项目采用图形化服务组合和基于代理的方法来解决中小企业服务开发和部署的问题。

首先，为非 IT 专家用户开发了可视化服务创建环境，用户只需了解单个服务的输入和输出类型，这些类型以用户友好的方式定义，包括高级抽象类型如电子邮件或 SIP 地址、用户组名称以及基本类型如数字和布尔值。用户可以从服务列表中选择服务，通过拖放操作将它们放置在工作台上，然后通过图形表示连接这些服务以创建新的服务组合，最后将组合部署到 ODSDP。

其次，开发工具和服务执行环境集成到统一的 MAMS 服务框架中，该框架提供了从服务创建、执行、网络层到硬件的完整垂直集成。例如，IP 多媒体子系统（IMS）允许集成多媒体连接，如视频电话或会议呼叫。

在 MAMS 中，区分了三种不同的角色：
- 平台提供商 ：服务交付平台（SDP）的主机和所有者，提供和维护基本服务，管理其他第三方服务的集成。
- 服务提供商 ：非 IT 专家，如企业家或中小企业，借助 MAMS 通过组合和配置基本服务来创建自己的服务。

通过这种方式，MAMS 服务框架为中小企业提供了一种可行的服务开发和部署解决方案，同时利用代理技术提高了服务交付平台的灵活性、可扩展性和稳定性。

基于承诺的业务建模与MAMS服务框架解析

MAMS服务框架的技术架构与优势

MAMS服务框架采用了基于代理的技术架构，这种架构继承了面向服务架构的特性，具有灵活性、健壮性和可扩展性。该框架利用代理技术构建了一个分布式服务执行环境，下面我们详细分析其技术架构和优势。

技术架构

MAMS服务框架的技术架构可以用以下mermaid流程图表示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(可视化服务创建环境):::process --> B(服务组合):::process
    B --> C(ODSDP):::process
    C --> D(服务执行):::process
    D --> E(网络层):::process
    E --> F(硬件):::process
    G(平台提供商):::process --> C
    H(服务提供商):::process --> A

这个流程图展示了MAMS服务框架从服务创建到执行的整个过程。非IT专家用户在可视化服务创建环境中创建服务组合，然后将其部署到ODSDP（基于代理的服务交付平台），在ODSDP上执行服务，最终通过网络层与硬件进行交互。平台提供商为ODSDP提供支持，而服务提供商则使用可视化服务创建环境来创建服务。

优势分析

• 灵活性 ：代理技术使得服务可以根据不同的需求和环境进行灵活配置和调整。例如，当服务负载发生变化时，代理可以自动调整资源分配，以确保服务的稳定运行。
• 可扩展性 ：分布式服务执行环境可以轻松地添加新的服务和资源，以满足不断增长的业务需求。新的服务可以通过简单的配置加入到现有的服务组合中。
• 稳定性 ：代理技术可以自动检测和处理故障，提高服务的稳定性。当某个服务出现故障时，代理可以自动切换到备用服务，确保服务的连续性。

MAMS服务框架的应用场景与案例分析

MAMS服务框架适用于多种应用场景，下面我们通过具体案例来分析其应用效果。

应用场景

• 电信服务 ：MAMS服务框架可以集成IP多媒体子系统（IMS），实现多媒体通信服务，如视频电话、会议呼叫等。非IT专家可以根据用户需求快速创建和部署这些服务。
• 中小企业服务 ：中小企业可以利用MAMS服务框架创建自己的定制化服务，而无需具备专业的技术知识和大量的资源投入。例如，一家小型电商企业可以创建一个基于MAMS的客户服务系统。

案例分析

假设一家小型酒店希望提供个性化的客户服务。酒店管理人员作为非IT专家，可以使用MAMS的可视化服务创建环境来创建服务组合。具体操作步骤如下：
1. 选择服务 ：从服务列表中选择所需的服务，如客房预订服务、客户信息管理服务、餐饮预订服务等。
2. 组合服务 ：通过拖放操作将这些服务放置在工作台上，并通过图形表示连接它们，创建一个完整的服务组合。例如，将客房预订服务与客户信息管理服务连接，确保客户信息可以自动同步。
3. 部署服务 ：将创建好的服务组合部署到ODSDP上，ODSDP会自动分配资源并执行服务。
4. 监控和调整 ：酒店管理人员可以实时监控服务的运行情况，并根据客户反馈和业务需求进行调整。例如，如果发现客房预订服务的响应时间过长，可以调整资源分配或优化服务流程。

通过使用MAMS服务框架，这家小型酒店可以快速创建和部署个性化的客户服务系统，提高客户满意度和业务效率。

总结与展望

基于承诺的业务建模为业务关系的建模和验证提供了一种有效的方法，通过验证代理交互和检查模型完整性，可以确保业务模型的合规性和稳定性。MAMS服务框架则为中小企业提供了一个可行的服务开发和部署解决方案，利用代理技术提高了服务交付平台的灵活性、可扩展性和稳定性。

未来，我们可以进一步探索以下方向：
- 业务建模方法的扩展 ：开发更多的业务模型模式和方法，以满足不同业务场景的需求。
- MAMS服务框架的优化 ：进一步提高MAMS服务框架的性能和功能，如增加更多的服务类型和集成更多的技术。
- 可视化工具的改进 ：开发更强大的可视化工具，使非IT专家能够更轻松地创建和管理服务。

通过不断的研究和实践，我们相信基于承诺的业务建模和MAMS服务框架将在更多的领域得到应用和推广，为企业的发展提供有力支持。