基于工作流的协同会商模型研究与设计

贺荣+蔡丽丽

摘要：针对协同会商系统对于规程化电子会议支持不足的问题，研究并设计了一种基于工作流的协同会商模型。该模型采用工作流技术实现规程化电子会议过程中的控制，保障协同会商有序、有效开展。面向业务需求分析了流程化协同会商模式，研究了流程任务封装、流程编排与模板套用、流程动态管控等技术，完成了基于工作流的协同会商系统软件结构设计和交互接口设计。

关键词：协同会商；工作流；web电子会议；表征状态转移

引言

协同会商是指多人以会议室、电视电话网络或IP网络为媒介，针对某一项任务或专题，开展协同研讨、交互和工作的过程。网络化环境下的协同会商系统是通过计算机软件系统和IP网络，面向异地用户，针对共同的会商任务建立统一的协同会商环境，解决异地用户无法实施沟通和交换信息的问题。随着计算机软件技术的迅速发展和IP网络通信质量的提升，网络化环境下的协同会商系统能够支持的交互手段和信息共享方式逐步丰富，已经能够满足异地用户协同研讨和交互需求，但受限于用户分布异地的特性，对于协同会商过程中研讨过程的控制一直是该类系统的弱项，尤其对于具有严格会议议程要求的协同会商场景，难以通过单纯的权限控制模型保证会议的有序、有效开展。

结合上述问题，本文研究并设计了一种基于工作流的协同会商模型，采用工作流技术实现流程化的协同会商，首先针对需求研究流程化的协同会商模式，以及流程任务封装、编排、讨论和动态管控方式，随后进行了软件结构设计和交互接口设计。

1流程化协同会商模型

1.1协同会商模式

本文研究与设计的协同会商系统面向网络化环境下的多人异地研讨需求，基于协作空间实现多模式协同会议和研讨功能。协作空间是在分布异构系统中构建的支持动态信息共享、交互和应用协同的虚拟环境。它具备明确的空间边界，提供丰富的应用协作模式和严格的协同数据管控机制，支持地理分散的协同应用共享数据、交换信息和协调任务。

协作空间由协作任务、协作成员和协同数据组成。协作任务是在协作空间中进行应用协同的起因，通常协作任务都具备明确的任务目标、任务起始时间和完成期限；协作成员是应用协同的实现主体，处于不同地理位置的协作成员通过应用系统在协作空间中完成规定的协作任务；协同数据包含应用协同过程中产生的业务数据和应用协同完成后形成的结论数据。协作空间的设计目的在于有效管理协作任务、协作成员、协同数据，以及应用协同过程中三者之间的关系。

本系统需要支持的协同会商模式主要包括：

1）自由交互模式：由管理员配置空间参与成员列表，空间开放后用户可自由加入协作空间，并自由使用空间内的各类多媒体交互手段。

2）协商研讨模式：由管理员配置空间参与成员列表、角色和权限，角色包括主持人、成员、访客，开放后只有参与成员列表的用户可加入协作空间，空间内用户默认按照配置的权限使用多媒体交互手段，当需要使用不具备权限的交互手段时需主持人批准。

3）评审会议模式：由管理员配置空间参与成员列表和协作流程，开放后只有参与成员列表的用户可加入协作空间，空间内用户按照配置好的协作流程开展协同工作。

可以看出，自由交互模式和协商研讨模式适用于临机日常的协同会商场景，通过协作空间的故有属性和权限控制模型可以实现，但评审会议模式的协同会商场景要求按照严格的工作会议流程开展多人协同会商，同时需要根据不同的工作会议议程按需对协同会商流程进行配置和调整。

针对评审会议模式的协同会商需求，本文研究并设计了基于工作流的协同会商模型，在会议准备阶段由会议组织者编排、绘制会议议程；在会议进行阶段，与会人员按照会议议程开展协同会商，由工作流引擎按照会议议程控制协同会商过程。

1.2流程任务封装

应用系统在使用工作流引擎时通常需要经历流程编排、流程发布和流程执行三个过程，其中流程编排采用BPMN2.0等标准，通常由技术人员完成。本系统采用流程编排功能实现对会议议程的编排和绘制，这就要求会议组织者需要具备一定的专业基础，一般的普通用户未经培训很难正确绘制流程。因此，为了降低流程编排的难度，本文将对任务节点进行封装，将集成信息参数和分支规则参数等信息封装进任务节点，形成普通用户能够直观理解使用的业务环节模型。同时，将可合并的任务节点封装成一个业务任务模型，从而简化流程环节，减少编排者工作量。流程任务封装过程中关于流程和任务模型的定义如下：

在不影响协同会商业务执行的前提下，为了尽量降低流程的复杂度，任务封装时须遵循以下几点规则：

1）一个封装后的任务模型只有一个输入和一个输出；

2）多个任务节点封装成一个任务模型时，各任务节点的执行角色必须一致；

3）流程进行任务模型封装后，简化成一个顺序型流程；

4）流程中存在分支时，只能存在一个分支形成主流程；

5）封装后的任务模型只对使用者暴露必要的人机交互信息设置。

以启动会议模型为例，通过原始流程环节分析，将启动会议和自由/协商模式分支封装成启动会议模型，形成一个分支任务模型，它的ME={启动会议，分支，研讨，结束}，mi=（启动会议，分支，in），mo=（分支，null，out，<审评批复>）。

以评审会会议议程为例，原始的协同会议流程涉及了分支节点、并发环节等复杂流程节点类型，尤其是分支节点需要分支规则判断，如图1所示所示。

首先，分析协同会商的业务流程，从业务层级上将会商流程分割成业务颗粒度最小的任务环节，如图2所示。通过对任务环节的信息分析，抽取各环节的执行信息以及环节之间的执行逻辑信息，结合基于流程的协同会商实现方式将信息划分为静态类执行信息和动态类执行信息。静态类执行信息是指业务环节的固定信息，一旦确定下来就较少会发生变动，多为协同会商与流程之间的集成协作信息，不需要公布与流程参与者知晓，例如分支节点的分支判断规则信息；动态类执行信息是指业务环节中会根据实际场景发生变化的信息，需要协同会商流程策划者（发起者）在会商启动之前具体指定，例如业务环节的参与者。

1.3流程编排与模板套用

当任务模型封装完毕后，用户直接基于这些任务模型进行协同会商流程编排，并生成流程与任务模型的关联关系和模型与模型之间的执行次序信息。当发布流程时，流程将通过关联关系获取任务模型的具体信息，根据任务模型的封装信息解析生成相应的流程定义片段，最终根据模型与模型之间的执行次序信息将已解析生成的流程定义片段衔接形成完整的流程定义文件。由于本文研究的流程服务采用BPMN2.0标准协议，故而流程编排解析任务模型时将遵循BPMN2.0协议，生成符合该标准格式的流程定义描述文件。下面是流程解析算法，parseProeess（）是算法名称。

parseProeess（）{

for（each model in MODEL）{

//循环解析任务模型

generateModelBPMN（model）；

}

for（each flow in MPL）{

//连接各模型的片段信息

assemblingModel（now.source，floW.target）；

}}下面是任务模型的解析算法，generateModelBPMN（model）是算法名称，model是任务模型对象。generateModelBPMN（model）{

for（each me in model.ME）{

//根据BPMN20协议生成元素节点的描述信息

generateElementBPMN（me）；

//处理元素节点的属性信息

for（each mp in model.MP）{

//根据BPMN20协议生成元素节点属性信息

generateProperties（mp）；

}

for（each mf in model.MF）{

//根据元素节点的执行次序生成流程执行规则

generateFlow（mf.source，mf.target，mfc）；

if（mf.t=IN）{

//建立输入节点关系，以便流程后续组装各任务模型的执行次序

addIngoings（me）；

}else if（mf.t=OUT）{

//建立输出节点关系，以便流程后续组装各任务模型的执行次序

addOutgoings（me）；

}

}

}}

为了实现流程的复用，进一步简化流程编排工作量，流程化协同会商模型引入了模板概念，根据常见的协同会商场景预先准备协同会商模板库，用户可直接根据模板的输入输出要求设定相关参数，如指定与会人员，从而启动协同会商。同时，当场景发生变化时或新增场景时，用户可以基于原有模板直接修改，或者直接在模板库中添加新模板。

1.4流程动态管控

真实应用环境中，由于业务的变化或是其他情况的出现，协同会商流程不是一成不变，流程化的协同会商必须能够及时适应这些变化。针对这种适应需求，流程化协同会商模型设计时添加了流程动态管控机制。

使用场景的变更映射至流程所呈现出的变更情况有两种，一是任务模型内部执行流程发生变化，二是流程环节发生变化。针对这两种情况，流程动态管控机制引入了版本控制，通过版本控制管理流程定义和任务模型的变化。当任务模型内部发生变化时，通过修改模型的封装信息，形成新版本的任务模型。当流程重新发布时，流程将默认读取最新版本的模型封装信息解析生成流程定义文件。同时，流程依然可以根据实际情况需要选择之前版本的任务模型进行编排解析。

当流程环节发生变化时，则需要根据需求增加或减少任务环节，修改流程的执行路径，重新发布流程。当流程重新发布时，流程服务将升级流程的版本，原有的流程将继续保留存在，已有正在执行中的会商流程依旧按照原有的流程逻辑执行。但新启动的协同会商流程将自动按照最新版本的流程逻辑执行。

2系统设计

2.1软件结构设计

基于工作流的协同会商系统为三个层次，存储层提供用户信息、流程描述、协作空间、离线消息和服务配置信息存储功能；支撑层面向上层应用提供协同服务和工作流引擎，包括协同服务管理、协同用户管理、协同会话监控、协作空间管理、流程任务流转等功能；应用层面向用户提供基于浏览器的协同会商环境、流程编排工具和流程管理工具。

2.2交互接口设计

基于工作流的协同会商系统中协同服务和工作流引擎作为底端支撑服务，面向基于浏览器的协同会商环境、流程编排工具和流程管理工具提供流程管理、任务管理和应用协同接口；基于浏览器的协同会商环境和流程编排工具之间采用页面集成的方式面向用户提供统一的访问页面如表1所示。

底层协同服务和工作流引擎采用RESTlet框架为上层应用提供基于RESTful的信息查询和控制接口，通过URI方式对外发布访问资源；针对会商过程中服务器主动推送消息的场景，采用HTML5中WebSocket特性提供全双工的消息收发功能。

1）流程管理

流程定义是指一个已经发布的流程描述模型，流程定义管理提供对流程模型的发布、删除和查询功能，流程实例是指一个正在执行的具体流程，是流程定义实例化后的流程，与流程定义是一对多的关系。资源类见表2。

流程发布是通过POST请求方式将流程编排生成的流程模型描述文件部署至流程服务中，由流程服务解析描述文件生成流程模型，支持协同会商为流程定义设定类别标识{identifier}，以便流程定义的后续查询和管理。

流程实例管理支持协同会商服务通过流程类别标识获取该分类下的流程实例列表，同时支持根据流程定义ID查询流程实例。

工作流引擎提供流程实例启动接口，启动流程则实例化该流程，创建一个实例对象并开始流程流转。它支持协同会商通过POST请求方式传递流程启动所需的参数信息。当流程启动后，协同会商可以通过流程实例查询或是流程实例获取的接口查询实例信息，也可以通过调用流程实例删除或者流程实例中止的方式提前结束流程。与流程定义管理中的流程删除不同，流程实例删除只删除该实例，不影响该流程其他的实例流转。流程定义中的流程删除则是删除流程定义，同时将该流程下所有的流程实例一并删除。

2）任务管理

任务管理提供协同会商对任务的统一管理接口，支持对流程运转中的任务进行提交、分派等处理操作，推动流程的流转。任务管理类资源包括了任务完成、任务分派、任务获取、任务查询、任务执行参数获取，见表3。

当流程实例化，协同会商可以通过流程环节的参与者或参与者角色查询对应的任务列表，并通过请求任务完成资源提交任务，推动流程的进程。当任务仅指定了参与者角色，尚未指定具体执行者时，协同会商通过调用任务分派资源将任务分派至具体的执行者。当任务已指定执行者但执行中需要更改执行者，则可通过任务重分派资源修改任务的执行者。任务分派、完成和重分派资源均支持通过POST请求方式传递任务处理所需的参数信息。

协同会商与流程服务提供的资源接口之间的交互数据格式采用JSON格式，资源接口接收JSON格式的输入参数，并返回JSON格式的响应信息。

3）应用协同

应用协同提供用户管理、空间管理和消息收发接口，见表4。

应用协同提供静态信息查询控制和动态信息操作两类资源，其中静态信息查询控制均采用REST模式对外发布资源，主要包括用户查询、用户创建、用户删除、协作空间查询、协作空间创建和协作空间删除；动态信息操作均采用HTML5中WebSocket技术，完成全双工的浏览器与服务器交互，主要包括系统接人、加入空间、退出空间、消息发送、消息接收和状态感知。

3结束语

本文介绍了采用工作流技术实现的多用户协同会商模式，研究了流程化协同会商模型，并对其中流程任务封装、流程编排与模板套用、流程动态管控技术进行深入分析，最后完成了基于工作流的协同会商系统结构设计和交互接口设计。目前基于工作流的协同会商模型已应用于B/S模式的协同会商系统中，填补了系统对于具有严格会议议程要求协同会商场景的空白，能够支撑网络环境下规程化电子会议的有序开展。下一阶段，考虑在本文的工作基础上进一步拓展流程化协同会商的应用领域，进一步优化现有系统。