27、跨组织特征动态组合与多应用协调自适应技术解析

跨组织特征动态组合与多应用协调自适应技术解析

跨组织特征动态组合

在跨组织服务组合中，当特定特征策略规定必须应用某一特征时，消费者和提供者端的特征实现会针对通过该服务绑定交换的每条消息进行动态组合。

以下是一个特征策略的示例：

servicebinding {
    URI : http : / /www. stocktradingexample . be ;
    port : StockTradingServiceSoapEndpoint ;
    features : SHA1withDSA , SignatureBasedNR ;
}

协调架构

为了在跨组织服务组合中以一致的方式处理用户请求，所有参与服务之间需要进行协调。具体操作如下：
1. 每个请求都会被标记额外的元信息，这些元信息指定了与用户特定偏好相对应的一组特征。
2. 该元数据会随着用户请求发起的消息流进行传播，使得关于所需特征组合的信息能够随消息流传递。
3. 协调中间件会确保在需要时动态激活适当的特征实现。

协调中间件架构基于AO框架构建，跨组织特征在服务组合中的运行时组合主要包括两个阶段：选择和激活。这两个阶段在架构中以模块化包的形式呈现：
- 选择阶段：由FeatureSelection切面和PolicyManager组件组成。
- FeatureSelection作用于应用层，拦截受特定特征策略约束的远程服务请求。
- PolicyManager处理特征策略，并存储每个服务绑定适用的特征。这些数据结构是具有常量访问时间的哈希映射。
- FeatureSelection切面查询PolicyManager以确定给定服务绑定适用的特征，并将所需特征的标识符标注在拦截的消息上。同时，它会跟踪哪些服务绑定已经被定制，仅对新的服务绑定查询PolicyManager以获取所需特征。
- 激活阶段：由ConsumerActivation和ProviderActivation切面以及ConsumerFeatureMapping和ProviderFeatureMapping组件组成。
- 特征映射组件存储特征实现及其关联的AO组合的哈希映射，允许根据给定的特征标识符查询适当的特征实现。
- ConsumerFeatureMapping和ProviderFeatureMapping分别处理特征的服务消费者和服务提供者角色。
- ConsumerActivation切面作用于消费者服务平台，拦截所有消息并检查其中是否包含选定特征的元数据。将选定特征与当前应用于特定服务绑定的特征进行比较，若有必要则查询ConsumerFeatureMapping组件获取选定特征的AO组合描述，并使用该信息组合必要的切面组件，然后向AO框架发送请求以部署这些切面组件。最后，将特征更新作为附加信息添加到消息中通知提供者端。
- ProviderActivation切面在提供者端拦截传入请求，检查是否有特征更新。若有必要，激活新特征，其激活过程与消费者端类似。同时，会验证传入请求是否符合特征策略，若消息包含不支持或缺失的特征，则不接受该消息并返回异常消息。

以下是跨组织特征动态组合流程的mermaid流程图：

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

    A(用户请求):::process --> B(标记元信息):::process
    B --> C(消息流传播元数据):::process
    C --> D{选择阶段}:::process
    D --> E(FeatureSelection拦截请求):::process
    E --> F(PolicyManager处理策略):::process
    F --> G(标注消息特征):::process
    G --> H{激活阶段}:::process
    H --> I(ConsumerActivation检查消息):::process
    I --> J(查询ConsumerFeatureMapping):::process
    J --> K(组合切面组件):::process
    K --> L(部署切面组件):::process
    L --> M(通知提供者端):::process
    M --> N(ProviderActivation检查请求):::process
    N --> O(激活新特征):::process
    O --> P(验证请求合规性):::process

性能开销评估

评估旨在衡量协调架构对服务应用整体响应能力引入的绝对和相对性能开销，特别是选择和激活组件引入的开销。
- 原型实现：使用Java SE 6实现了协调架构的原型框架，基于支持动态AO组合的方面组件框架构建，使用Java动态代理技术拦截调用并调用建议，所有声明性规范使用XML文件。
- 基准测试：
- 使用往返延迟基准测试，该测试应用由客户端和服务器两个JVM应用组成。客户端调用实现空ping方法的远程服务，该方法无参数且返回值为空。
- 基准场景配置为：远程服务和客户端在同一局域网的不同主机上的两个JVM中运行。依次执行100个基准系列，每个系列先进行20000次预热操作，然后测量20步，每步5000次调用，记录每步的平均执行时间。
- 将基准应用扩展为包含基于签名的身份验证特征，并在默认版本和扩展了协调架构的版本的分发层上执行。
- 测试结果：
- 往返延迟基准测试结果表明，协调中间件引入的开销可以忽略不计。这是因为协调架构中的选择切面会跟踪哪些服务绑定已经被定制，并且特征激活机制仅在有更新时通知提供者端。
- 与标准中间件平台（Java RMI和JBoss Remoting）相比，协调架构引入的相对开销比JBoss Remoting小6倍，表明其引入的开销是可以接受的。

资源受限移动设备上多应用的协调实用自适应

随着普适计算的出现，未来人们将广泛使用通用移动设备来协助休闲和商务任务，用户期望设备能同时运行多个强大的应用程序。然而，移动应用开发者面临着诸多挑战，如应用需应对突然的上下文变化、稀缺资源和有限的设备能力等。

多应用实用自适应相关概念

• 组件和变体：应用由组件（即代码片段）组装而成，多个不同的组件集合（每个称为一个变体）可以实现相同的应用。运行时，适应所需的知识由计划表示，每个计划包含组件的代码以及如何将该组件与其他组件组装的信息。计划可以在运行时安装和移除，因此应用的可用变体集可以动态变化。
• 上下文：是一组描述从中间件视角看世界的数值（不包括中间件本身的属性）。应用声明其依赖的上下文，中间件根据请求提供相应的值。上下文值会随世界的变化而变化，原则上这些变化不受中间件、应用和用户的控制。
• 资源：如内存和CPU，是特定的上下文值，其可用性决定了某个变体是否能在特定情况下执行。每个变体声明其所需的每种资源的特定固定量，资源由中间件分配给变体，且只有中间件可以收回资源，因此运行中的变体可以继续运行，不受资源变化的影响。

以下是多应用实用自适应相关概念的表格总结：
| 概念 | 描述 |
| ---- | ---- |
| 组件和变体 | 应用由组件组装，多个变体可实现同一应用，计划表示适应知识，可用变体集可动态变化 |
| 上下文 | 描述世界的数值集合，应用声明依赖，中间件按需提供，值随世界变化，不受控制 |
| 资源 | 特定上下文值，决定变体执行，变体声明所需量，由中间件分配和收回 |

处理多个同时运行的应用程序会带来一些问题，如过度适应导致的性能下降以及低收益重新配置引起的卡顿和用户分心等非功能性问题。后续将介绍Serene Greedy这种实用的方法来解决这些问题。

跨组织特征动态组合与多应用协调自适应技术解析

多应用自适应的非功能方面

在对多个应用进行自适应时，除了要考虑结果的最优性，还需要关注一些非功能方面的因素，这些因素对于提升用户体验和应用的整体性能至关重要。
- 用户分心 ：频繁的自适应操作可能会打断用户的正常使用流程，导致用户分心。例如，应用在自适应过程中可能会弹出提示框、改变界面布局等，这些都会干扰用户的注意力。
- 操作流畅性 ：自适应过程应该尽可能地保证应用操作的流畅性。如果自适应操作过于复杂或耗时过长，可能会导致应用出现卡顿现象，影响用户的使用体验。
- 性能稳定性 ：过多的自适应操作可能会导致系统资源的频繁分配和释放，从而影响系统的性能稳定性。例如，频繁的内存分配和回收可能会导致内存碎片的产生，降低系统的运行效率。

以下是多应用自适应非功能方面的表格总结：
| 非功能方面 | 影响 |
| ---- | ---- |
| 用户分心 | 打断用户正常使用流程，干扰注意力 |
| 操作流畅性 | 自适应复杂或耗时过长会导致卡顿 |
| 性能稳定性 | 频繁操作影响系统资源分配，降低运行效率 |

自适应原因分析

多种事件会引发应用的自适应，这些事件对维持应用的最优实用性有着不同的影响和重要性。
- 上下文变化 ：如网络连接状态、设备位置等上下文信息的改变，可能会导致应用的某些功能无法正常使用或需要调整。例如，当设备从Wi-Fi网络切换到移动数据网络时，应用可能需要降低数据传输量以节省流量。
- 资源可用性变化 ：内存、CPU等资源的可用性发生变化时，应用需要进行自适应以确保能够在当前资源条件下正常运行。例如，当系统内存不足时，应用可能需要释放一些不必要的资源或降低自身的运行性能。
- 用户偏好改变 ：用户对应用的使用偏好发生变化时，应用需要根据新的偏好进行调整。例如，用户可能会更改应用的显示模式、通知设置等。

以下是不同自适应原因及其影响和重要性的表格：
| 自适应原因 | 影响 | 重要性 |
| ---- | ---- | ---- |
| 上下文变化 | 影响应用功能使用，需调整功能 | 高 |
| 资源可用性变化 | 决定应用能否正常运行，需调整性能 | 高 |
| 用户偏好改变 | 影响用户使用体验，需调整设置 | 中 |

Serene Greedy方法

Serene Greedy是一种用于在资源受限的移动环境中，对同时运行的应用程序进行自适应决策的实用方法。该方法综合考虑了多种因素，以平衡应用的性能和非功能方面的需求。
- 决策机制 ：Serene Greedy方法会评估每个应用的当前状态和可用资源，根据预设的规则决定是否进行自适应操作。在决策过程中，会考虑到自适应带来的收益以及可能产生的非功能影响，如用户分心和操作不流畅等。
- 操作流程 ：
1. 收集应用的当前状态信息，包括上下文、资源使用情况等。
2. 评估每个应用的自适应需求和可能的收益。
3. 根据预设的规则，决定是否对应用进行自适应操作。
4. 如果决定进行自适应，选择合适的自适应策略并执行。

以下是Serene Greedy方法操作流程的mermaid流程图：

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

    A(收集应用状态信息):::process --> B(评估自适应需求和收益):::process
    B --> C{是否进行自适应?}:::process
    C -- 是 --> D(选择自适应策略):::process
    D --> E(执行自适应操作):::process
    C -- 否 --> F(维持当前状态):::process

Serene Greedy方法的验证与讨论

通过将Serene Greedy方法与其他自适应推理技术进行比较，可以评估其在性能和非功能属性方面的表现。
- 性能比较 ：在处理多个应用的自适应问题时，Serene Greedy方法能够在保证一定性能的前提下，减少不必要的自适应操作，从而降低系统的资源消耗。与一些传统的自适应方法相比，Serene Greedy方法在性能上具有一定的优势。
- 非功能属性比较 ：在非功能属性方面，Serene Greedy方法更加注重用户体验，能够有效减少用户分心和操作不流畅的问题。与其他方法相比，它能够更好地平衡自适应的收益和非功能影响。

以下是Serene Greedy方法与其他自适应推理技术比较的表格：
| 比较方面 | Serene Greedy方法 | 其他自适应推理技术 |
| ---- | ---- | ---- |
| 性能 | 减少不必要操作，降低资源消耗 | 可能存在过度自适应，资源消耗大 |
| 非功能属性 | 注重用户体验，减少分心和卡顿 | 可能影响用户体验，存在分心和卡顿问题 |

综上所述，跨组织特征动态组合和多应用协调自适应是在现代分布式和移动计算环境中非常重要的技术。跨组织特征动态组合通过协调架构实现了特征的动态选择和激活，并且在性能开销方面表现良好。而Serene Greedy方法为资源受限移动设备上多应用的自适应提供了一种实用的解决方案，能够在保证性能的同时，兼顾非功能方面的需求，提升用户体验。