工作流技術在衛星地面系統的應用分析與設計

朱小杰 徐 京 劉 華

(航天恒星科技有限公司,北京 100086)

1 引言

衛星地面系統運行控制軟件是衛星地面系統的重要組成部分,該軟件功能上主要分為設備監控部分和任務調度部分,是衛星地面系統的管理中心,它與其它分系統密切配合,根據任務需求實現對系統內各個設備的統一管理控制,使全系統形成松耦合的有機整體,高效地完成各項任務。

隨著衛星地面應用系統中的運行控制軟件項目日益增多,系統越來越復雜,對軟件項目的開發效率和軟件質量要求也越來越高[1]。面對目前軟件開發人力資源有限、眾多工程進度緊的現實,如何從技術上解決這些矛盾,成為迫在眉睫的任務。這就對軟件復用、可擴展性、可維護性提出了更高的要求。

軟件復用的本質就是對軟件的共性抽取和特性提煉,對于任務調度共性需求的提取,就是要固化流程中不變的部分,而工作流技術正是解決這一問題的一種途徑[2]。但是,工作流技術的相關規范和標準較多,不同工作流產品的應用領域也不盡相同[3]。因此,就需要探討在運行控制軟件中如何應用工作流技術進行設計和驗證,從而使得工作流技術能夠很好地用于我們的運行控制軟件。

2 可行性分析

工作流的概念起源于辦公自動化領域,是在現代信息系統的建設中逐步形成的。工作流目前還沒有完全統一的定義。工作流管理聯盟(Workflow M anagement Coalition,WFMC)給出的定義是[4]:“工作流是一類能夠完全或者部分自動執行的經營過程,它根據一系列過程規則、文檔、信息或任務能夠在不同的執行者之間進行傳遞與執行”。工作流就是工作流程的計算模型,其表示的是:對流程中的任務,以什么樣的邏輯或者規則串聯起來,并以什么樣的模型進行表示和計算。

將計算機應用在工作流程管理中的技術稱為工作流技術。工作流技術的體現方式是一個工作流平臺或工作流管理系統,而不是硬編碼的應用[2-4]。

工作流管理聯盟給出了工作流管理系統的一個參考模型[4],如圖1所示。通過這個模型確定了工作流管理系統的基本架構,為我們實現工作流技術提供了參考。當然,一個工作流管理系統也可以不遵循這個模型標準或只實現這個模型的一部分,但事實證明,這個模型結構是目前最為合理的。

圖1 工作流管理系統結構Fig.1 Structure of workflow management system

從圖1可以看出,該參考模型中的核心組成部分是工作流執行服務:它借助于一個或多個工作流機(工作流引擎),激活并解釋過程定義的全部或部分,并同外部的應用程序進行交互,完成工作流過程實例的創建、執行與管理,為工作流程的運行提供一個運行環境[4]。

工作流管理系統將業務流程中,工作如何組織協調在一起的規則抽象出來,從而分離了具體工作的邏輯和流程組織的邏輯。我們在工作流管理系統的協助下,開發人員遵從一定的編程接口及約定,就可以開發出更具靈活性的事務處理系統,最終用戶無需重新開發事務處理系統,就可以自己更改工作流程,以適應業務變化的需要。

運行控制軟件的任務調度部分是按照下發的計劃,在不同的參與者之間進行流轉,以完成計劃任務。這些參與者既可以是人,也可以是設備,還可以是算法模塊。例如某遙感衛星地面接收處理子系統運行控制軟件[5],根據不同類型的衛星遙感圖像處理的需要,采用指定的通信協議和接口,按照預先設定的流程,串行或并行地調用本地或遠程算法模塊,處理并生成最終圖像產品。所以說,運行控制軟件的任務調度也是屬于工作流程管理的范疇,完全可以使用工作流技術來實現流程邏輯與具體工作邏輯的分離。將運行控制軟件任務調度部分流程邏輯提取出來,得到一個工作流引擎。這樣,我們只需要關注于每個活動的具體業務邏輯,至于這些活動點的依賴關系等流程的邏輯交由工作流引擎[4]來完成。如圖2所示,左邊是采用硬編碼方式實現的業務流程,針對每個活動點,都需要開發界面程序,進行后臺的業務處理、數據的存儲,對下一步的執行者進行硬性的指定,這樣能解決一個流程的實現問題,但是流程不是唯一的,業務需求也不是一成不變的[1,5];如果我們對其中的流程邏輯進行共性抽取,形成工作流引擎,這樣當有新的業務需求的時候,我們只需要針對和業務相關的部分進行少量的二次開發,這樣就提高了軟件的可復用性、可擴展性。所以,從本質上講,工作流技術就是對于流程的復用。

可以說,引入工作流技術,使我們從繁瑣的業務過程邏輯處理中找出一種統一的解決途徑。

3 方案設計

通過以上分析,將工作流技術引入運行控制軟件是可行的,并能夠提升軟件的可復用性、可擴展性、可維護性。應用工作流技術的方式也有多種。如果利用已有的第三方工作流產品,將衛星地面系統的流程部署在第三方的工作流引擎上[6-8],從而實現我們的需求,這樣做是可行的,但同時也比較被動,因為第三方的引擎對我們來講是“黑盒子”,我們只能在第三方引擎的規范和限制下工作,這對于我們診斷和定位問題造成困難,維護較難;另外,第三方引擎關注的業務重點不一樣,例如:微軟等公司制定的業務流程執行語言(Business Process Execution Language,BPEL)關注于企業服務總線(ESB),非常適合將一組現有服務組合成一個新服務[9],并不非常適合于我們運行控制系統;而且部署和實現的代價很高,這也是一般的引擎對于我們的運行控制軟件來說的共同問題,即往往顯得較為重量級。與此同時,運行控制系統有些需求又是一些引擎所不能滿足的,例如回退模式[10];當需要在引擎外圍加一些面向領域的或用戶定制的特殊化需求時,又顯得異常困難。這樣,研究工作流引擎技術并擁有一個自己的輕量級的工作流引擎[7,10]顯得非常重要。

圖2 使用工作流技術前后的對比Fig.2 Contrast between system using workflow technology and that not using workflow technology

本文根據任務調度軟件的需求,設計并實現了一個流程引擎內核[10-12]。設計方案中所包含的主要類以及類之間的靜態關系如圖3所示。

圖3 引擎內核類圖Fig.3 Class diagram of workflow engine' s core

此流程引擎內核僅是滿足流程基本運行的最微小結構,而諸如整個引擎所涉及包括“狀態存儲”、“組織適配”、“時間調度”、“消息服務”等外圍的服務性功能這里沒有實現和展示。引擎內核,僅包含最基本的對象和服務以及用于解決流程運行問題的調度機制和執行機制[6-7,12],其職責主要包括過程邏輯的定義以及流程的調度和執行,并非是一套完整的執行環境。

過程邏輯的定義,包括組成工作流的所有活動以及活動之間的依賴關系。本引擎內核中利用三個對象來表示一個流程的定義。Activity 代表節點,Transition 代表連結這些節點的弧線,利用Activity和Transition 的組合,就可以表達一個完整的流程定義,Process Definiton 代表一個完整的流程定義。

各節點的調度和執行,即確保流程按照預先的邏輯定義進行流轉和執行。Execution 獲取一個Process Definition 后,先創建一個流程實例并設置開始節點,然后維持此流程實例上下文環境。流轉到某個Activity ,Activity 的類型有多種,圖3 中列出了三種有代表性的Task Activity ,Gatew ay Activity ,Sub Process Activity。其中Task Activity 再分三種類型,U ser Task Activity是需要人工參與的節點,Receive Task Activity是能夠調用java 類的節點,Script Task Activity是執行腳本語言的節點(當然,對應不同的腳本語言,會在引擎中有不同的腳本引擎)。Execution 依據不同的Activity 類型執行完其動作后,由此Activity 的Transition 得到其下一步的一個或多個Activity,再將它們移交給上下文環境。具體的流轉和執行由ExeOp 調用不同的Activity 來完成,以此往復,直至流程運行結束。

圖4 引擎驗證過程圖Fig.4 Chart of validating workflow engine

4 驗證與分析

下面對以上的設計方案和實現進行驗證[13]。按照圖4所示,將流程配置文件交由流程引擎處理,流程引擎會對配置文件進行解析,獲取其中的節點和連線信息并進行有效記錄,將這些信息轉化為一個個對象,創建流程實例,設置初始節點,引擎根據配置信息進行自動化的流轉直至得到不同的結果。

圖5 載荷處理流程實例Fig.5 Examples of payload processing flow

圖5(a)是某遙感衛星載荷的處理過程,假設需求發生變化,將算法c 替換算法b,并且加一個處理步驟,如圖5(b)所示。其分別對應的配置文件如表1所示。

表1 流程定義配置文件Table1 Configuration files of process definitions

從表1的兩個不同的配置文件交給引擎分別執行,在單元測試框架Junit 軟件下調試通過,可以得到兩種不同的結果。如圖6所示。

從以上可以看出,引擎內核具有快速響應流程需求變化的能力。在流程級別更改一個算法或增加一個步驟,只需要更改配置文件,替換掉原有的算法或新加一個處理過節點,而這些對于流程引擎都是透明的,流程引擎封裝了執行流程的所需要的諸如串行、并行、分支、聚合、判斷、回退等邏輯功能。針對不同節點的需求,可以設計具有相似功能特性的節點,即對節點類型進行擴展,形成多個特殊化的有特定功能的節點。例如,可以抽象并定義不同的有效載荷處理和不同的算法處理模塊,當某個節點需要的時候直接調用,就可以將有效載荷和算法加入到系統中。可以對領域內共有的特性進行模型抽取,在工作流引擎的基礎上形成一個領域框架,將其作為流程平臺二次開發的流程應用支撐層,在更細粒度上進一步增強可復用性。

5 結束語

本文簡單介紹了工作流技術相關概念,在此基礎上分析了工作流技術在衛星地面系統運行控制軟件中應用的可行性;結合運行控制軟件的特點,設計了一種滿足流程基本調度運行的引擎內核;并通過實例驗證了其響應系統需求變更的能力。本文初步驗證了將工作流引擎技術引入到衛星地面系統的可行性及優勢,對后續任務調度軟件的開發提供了一種的新的、具有快速響應需求變化能力的思路和解決方案。

圖6 不同執行結果Fig.6 Different results af ter executing

References)

[1]王瑞,李曉輝,朱家佳,等.遙感衛星地面站業務運行管理系統模型和流程設計方法[J].遙感信息,2010(2)

[2]胡長城.工作流之星光[EB/OL].[2010-10-09].http://www.docin.com/p-37941230.html

[3]Tom Baeyens.State of workflow[EB/OL].[2010-08-10].http://www.jboss.com/products/jbpm/stateofworkflow/

[4]Workflow Management Coalition.The workflow reference model [EB/OL].[2010-06-20].http://www.wfmc.org/Published-Research/View-category.html

[5]賀然,徐京,王揚.設計模式在任務調度軟件中的應用[J].航天器工程,2009,18(3):110-116

[6]jBPM Team.jBPM User guide[EB/OL].[2010-08-11].http://www.jboss.org/jbpm

[7]Activiti Team.Activti user guide[EB/OL].[2010-09-11].http://www.activiti.org/userguide/index.html

[8]楊洪波.BPEL 與XPDL 的區別[EB/OL].[2008-10-

10].http://wenku.baidu.com/view/843be3649b6648d 7c1c746ee.h tml

[9]Van der AALST W M P.Pat terns and XPDL:Acritical evaluation of the XML process definition language[EB/OL].[2009-10-13].http://wwwis.win.tue.nl/～wvdaalst/publications/p201.pdf

[10]Tom Baeyens.Process component models:The next generation[EB/OL].[2009-11-15].http://www/infoq.com/articles/process-component-models

[11]葉娜,李健.工作流引擎推進過程中m 選n 問題的研究[J].計算機應用研究.2009,26(11)

[12]余陽,湯庸,潘茂林,等.時態工作流過程模型及其合理性驗證[J].軟件學報,2010 ,21(6)

[13]齊同曄.基于狀態轉換的工作流驗證的研究與實現[D].大連理工大學,2009,7