随着云计算技术的发展，特别是随着软件服务技术^{[1, 2]}的成熟，以服务构建应用系统^[3]已经成为一种重要的软件使用和开发模式，服务组合及其应用是目前研究的一个热点.

组合服务是由服务构成的^{[4, 5]}，组合服务执行效率受服务执行时间以及服务间消息通信时间的影响.为保证组合服务执行效率，国内外研究者开展了大量的研究工作.例如，文献^{[6, 7]}提出了QoS驱动的服务选取方法.这些研究工作大都强调服务间的通信需要通过执行引擎进行中转(即控制流、数据流全集中模式，简记为CCCD模式)，同时假设服务间消息通信量增大时对执行引擎的处理效率没有任何影响.然而，在实际应用中，服务间可能需要传递大量数据，由于数据流消息需要通过执行引擎转发给其他服务，执行引擎的消息转发效率将影响组合服务执行性能.另外，也有研究者提出通过服务间直接消息传递解决组合服务执行效率的方法.例如，文献^[8]中提出了一种控制流集中、数据流分散的组合服务执行模式(简记为CCDD模式).该模式中，控制流消息需要根据服务间的控制流依赖关系依次发送给其所有的控制流后继服务.当服务间数据流消息数据量较小且控制流依赖关系较多时，采用CCDD模式的组合服务执行效率可能要比采用CCCD模式的低.

考虑到组合服务执行模式对其执行效率的影响，本文研究一种组合服务混合执行机制，根据组合服务业务特性和网络环境特点，判断数据流是经过执行引擎转发还是直接在服务间进行传递，从而通过选择执行模式保证组合服务执行效率.

图1给出了组合服务混合执行机制的分层结构，包括实例调度执行层、执行模式选择层和集成交互层.这里：实例调度执行层的主要功能是执行并调度组合服务运行实例；执行模式选择层主要负责根据运行实例的业务特点和网络环境状况，选择能够保证实例执行效率的执行模式；集成交互层的主要功能是接收/发送消息，完成与服务代理以及服务间的交互过程.

图 1(Figure 1)

Fig. 1

图 1 组合服务混合执行机制分层结构 Fig. 1 Architecture of hybrid execution mechanism for composite service

在组合服务混合执行机制中，执行引擎^{[9, 10]}是组合服务系统的控制中心；服务代理起到引擎和服务间的协调作用，负责接收引擎的控制消息，对服务进行调用.交互协议用于在执行引擎和服务代理间传递控制流和数据流消息.表1给出了本文所设计的交互协议.

表 1

Table 1

表 1(Table 1)

表 1 交互协议中的消息 Table 1 Messages in the interaction protocol 协议消息名称 含义 发送者 接收者 类型 服务参数 输入消息 调用服务所需的输入变量 执行引擎或 服务代理 服务代理 数据流相 关协议消息 服务参数 完成消息 通知执行引擎服务的完成状况 服务代理 执行引擎 控制流相 关协议消息 服务参数 传递通知消息 通知所需交互的 下一个服务代理的地址 执行引擎 服务代理 控制流相 关协议消息 服务参数 提取消息 通知服务代理将执行结果中与执行控制 相关的参数传递给执行引擎 执行引擎 服务代理 控制流相 关协议消息 服务参数 回传消息 根据服务参数提取消息， 发送相关服务参数给执行引擎 服务代理 执行引擎 控制流相 关协议消息

表 1 交互协议中的消息 Table 1 Messages in the interaction protocol

本文建立了能够反映服务所处业务和网络环境特点的执行环境特征模型，并在该模型的基础上提出了执行模式选择规则.

定义1 组合流程. 组合流程包括一组活动以及这组活动间的时序控制关系，它可以被形式化地定义为 C= < ID,A,E_c,E_d>，其中：ID为组合流程的唯一标识；A表示组合流程中的活动集；E_c表示组合服务流程中的控制流；E_d表示组合服务流程中的数据流.

定义2 组合服务和组合服务执行实例. 当组合流程C中的活动a_i要利用候选服务s_ij完成其功能时，称二元组<a_i,s_ij>为活动a_i的一个指派.如果对于C中的每个活动a_i，指派集合P中有且仅有一个元素为a_i的指派，则称P为该组合流程的一个组合服务.对于一个组合服务，其可以被多个使用者所调用，从而可以存在多个组合服务执行实例.对于组合服务P_i，其第j个组合服务执行实例可以记为p_ij.

定义3 组合服务执行实例的执行环境特征模型. 对于组合服务执行实例p_ij，在t时刻，其执行环境特征模型可以定义为F= < B,N>，其中，B为组合流程的业务特征向量，B=[b₁,b₂,…,b_m}，这里，如果组合服务执行实例p_ij中服务s_ijk的输出消息类型为布尔、字符以及整型等简单数据类型，则s_ijk面向的是控制处理逻辑，b_k为1；如果s_ijk的输出消息类型为复杂数据类型，则无法比较数据流相关协议消息与控制流相关协议消息数据量之和的大小，该情况下称s_ijk面向的业务处理逻辑不确定，b_k为0.N为组合服务执行实例在t时刻的网络环境特征矩阵.记组合服务执行实例p_ij中所有服务和执行引擎共同构成的集合为O.在时刻t，对于O中的任意两个元素o_l和o_k且 o_l和o_k不为组合服务执行引擎，如果o_l和o_k间存在数据流，则n_lk的取值为t时刻它们之间的网络带宽值；如果o_l和o_k间不存在数据流，则n_lk取值为-1；对于O中的任意两个元素o_l和o_k且o_l为组合服务执行引擎，则n_lk的取值为它们之间的网络带宽.

本文先给出在两种执行模式下组合服务执行时间的计算方法，并在此基础上给出组合服务的执行模式选择规则.以下，在组合服务执行实例 p_ij中，服务s_e采用CCCD执行模式的执行时间记为W(p_ij,s_e)，简记为W；采用CCDD执行模式的执行时间记为H(p_ij,s_e)，简记为H.

1) 单一数据流依赖. 对于组合流程CP中的活动a_e，如果a_e有且仅有一个数据依赖后继活动a_f，则称活动a_e为单一数据流依赖活动.

在CCCD执行模式下，活动a_e与a_f间的交互时间为发送结果消息(mr)给引擎的网络传输时间、引擎处理时间(tg)及引擎将输入消息(m_i)发送给服务s_f的网络传输时间之和.

在CCDD执行模式下，活动a_e与a_f间的交互时间为服务参数完成协议消息(m_p)的网络传输时间、对于服务参数完成协议消息的执行引擎处理时间(t_d)、服务参数传递通知协议消息(m_y)的网络传输时间、对于服务参数传递通知协议消息的服务代理处理时间(t_f)和服务参数输入协议消息(m_n)的网络传输时间之和.

本文假设相比较于网络传输时间，引擎和服务代理的协议消息处理时间很小，可以忽略不计.本文分别将活动平均输出数据量 和活动平均数据依赖数据量 作为m_r和m_p的历史经验值.从而，在CCCD和CCDD执行模式下，服务s_e与s_f的交互时间可以分别计算为

根据协议消息内容的定义， m_p和m_y的内容和格式是固定的，其数据量大小可以被事先确定. 为在过去一段时间t_u到t_v内，o_l和o_k间网络环境特征的平均值.E表示执行引擎.

在单一数据流依赖的情况下，本文将根据规则1和规则2进行执行模式的选择.

规则1. 对于组合服务执行实例p_ij中的服务s_e，s_e绑定的活动a_e为单一数据流依赖活动且s_e与s_f的交互时间远小于a_e与a_f的执行间隔时间.如果服务s_e在执行模式CCDD的执行时间T_H远小于在CCCD的执行时间T_W，则采用CCDD执行模式；否则，采用CCCD执行模式，以降低切换代价.

规则2. 对于组合服务执行实例p_ij中的服务s_e，s_e被绑定的活动a_e为单一数据流依赖活动且s_e与s_f的交互时间和a_e与a_f的执行间隔时间差别不大.如果T_W较小，则采用CCCD执行模式；如果T_H较小，则采用CCDD执行模式；如果T_W和T_H相同，则采用CCCD执行模式.

2) 多数据流依赖. 对于组合流程CP中的活动a_e，如果a_e的数据流依赖后继活动的个数大于1，则称活动a_e为多数据流依赖活动.此时，将根据规则3确定服务s_e的执行模式.

规则3. 对于组合服务执行实例p_ij中的服务s_e，s_e被绑定的活动a_e为多数据流依赖活动.在a_e的所有数据依赖后继活动中，如果存在活动a_l且a_l满足如下的条件①，②和③，则服务s_e的执行模式为活动a_l的执行模式；如果所有的数据依赖后继活动都不满足条件②，且存在活动a_l，a_l为a_e的数据依赖后继活动且a_l的执行模式为CCDD，则服务s_e的执行模式为CCDD；否则服务s_e的执行模式为CCCD：

①活动a_l为活动a_e的一个数据依赖后继活动；

②a_e与a_l的交互时间同a_e与a_l的执行间隔时间相近；

③活动a_e与a_l在不同执行模式下的交互时间差是a_e与其他所有数据依赖后继活动的最大值.

实验测试环境是在实验室局域网内搭建的，每个服务分别部署在不同的主机上，并且每个主机上为相应的服务部署一个服务代理，执行引擎部署在另一台主机.限于实验室网络环境，将服务之间、执行引擎与服务之间的网络带宽降低为100kB/s.实验中将测试四种情况的组合服务执行实例平均响应时间.同时，实验中依次将整个系统并发组合服务执行实例数量由1增到50.图2给出了实验结果.

图 2(Figure 2)

Fig. 2

图 2 不同执行模式下的实例平均响应时间 Fig. 2 Response time of the execution instance under different schemas (a)—每个服务的最大输出数据通信量都是100B；(b)—3个服务的最大输出数据通信量为50kB，其他服务的最大输出数据通信量为100B；(c)—7个服务的最大输出数据通信量为50kB，其他服务的最大输出数据通信量为100B；(d)—每个服务的最大输出数据通信量都是50kB.

图2a中，与CCDD模式相比，混合执行模式和CCCD执行模式具有较短的响应时间，能够保证组合服务执行效率.这是因为在该情况下，由于服务间最大输出数据通信量都只有100B，为小数据量服务，最大输出数据通信量小于控制流相关协议消息数据量，CCDD模式执行过程中增加了控制流相关协议消息在引擎与服务代理间的传递，从而使得其平均响应时间差于其他两种模式.而混合执行模式是通过执行模式动态选择采用了CCCD执行模式，其响应时间基本上与CCCD模式相同.图2b 中，混合执行模式具有较短的响应时间.这是因为在该情况下，有3个服务的最大输出数据通信量为50 kB，为较大数据通信量，混合执行模式通过为该3个服务选择CCCD模式而为其他服务选择CCDD模式，能够避免其中数据量较大的3个服务通过引擎流转消息，进而能够保证组合服务执行效率.图2c中，混合执行模式具有较短的响应时间.这是因为在该情况下，有7个服务的最大输出数据通信量为50 kB，为较大数据通信量，混合执行模式通过执行模式的选择，能够保证数据通信效率，进而能够保证组合服务执行效率.同时，还注意到，随着并发实例数的增加，引擎负载随之增加，平均响应时间增速加快.当并发实例数达到45时，由于引擎处理能力限制，其开始出现内存溢出现象，部分实例执行失败.而混合执行模式和CCDD执行模式通过协议消息，使得数据流分散在服务间传递，能够降低引擎负载，因此执行效率高于CCCD模式.图2d 中，CCCD模式具有较长的响应时间.这是因为，随着并发实例数的增加，引擎负载增大，在并发实例数超过40时，出现内存溢出现象，部分实例执行失败.而混合执行模式和CCDD模式由于将数据流分散在服务代理间，具有较短的响应时间.

本文提出了一种组合服务混合执行机制，给出了该机制的分层结构.针对于组合服务执行模式灵活切换和选择问题，建立了交互协议，给出了执行环境特征模型，并在该模型的基础上给出了执行模式选择规则.实验结果验证了该机制的有效性.