基于工作流的協同會商模型研究與設計

賀榮+蔡麗麗

摘要：針對協同會商系統對于規程化電子會議支持不足的問題，研究并設計了一種基于工作流的協同會商模型。該模型采用工作流技術實現規程化電子會議過程中的控制，保障協同會商有序、有效開展。面向業務需求分析了流程化協同會商模式，研究了流程任務封裝、流程編排與模板套用、流程動態管控等技術，完成了基于工作流的協同會商系統軟件結構設計和交互接口設計。

關鍵詞：協同會商；工作流；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模式的協同會商系統中，填補了系統對于具有嚴格會議議程要求協同會商場景的空白，能夠支撐網絡環境下規程化電子會議的有序開展。下一階段，考慮在本文的工作基礎上進一步拓展流程化協同會商的應用領域，進一步優化現有系統。