工作流技術(shù)在衛(wèi)星地面系統(tǒng)的應(yīng)用分析與設(shè)計

朱小杰 徐 京 劉 華

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

1 引言

衛(wèi)星地面系統(tǒng)運行控制軟件是衛(wèi)星地面系統(tǒng)的重要組成部分,該軟件功能上主要分為設(shè)備監(jiān)控部分和任務(wù)調(diào)度部分,是衛(wèi)星地面系統(tǒng)的管理中心,它與其它分系統(tǒng)密切配合,根據(jù)任務(wù)需求實現(xiàn)對系統(tǒng)內(nèi)各個設(shè)備的統(tǒng)一管理控制,使全系統(tǒng)形成松耦合的有機整體,高效地完成各項任務(wù)。

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

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

2 可行性分析

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

將計算機應(yīng)用在工作流程管理中的技術(shù)稱為工作流技術(shù)。工作流技術(shù)的體現(xiàn)方式是一個工作流平臺或工作流管理系統(tǒng),而不是硬編碼的應(yīng)用[2-4]。

工作流管理聯(lián)盟給出了工作流管理系統(tǒng)的一個參考模型[4],如圖1所示。通過這個模型確定了工作流管理系統(tǒng)的基本架構(gòu),為我們實現(xiàn)工作流技術(shù)提供了參考。當(dāng)然,一個工作流管理系統(tǒng)也可以不遵循這個模型標(biāo)準(zhǔn)或只實現(xiàn)這個模型的一部分,但事實證明,這個模型結(jié)構(gòu)是目前最為合理的。

圖1 工作流管理系統(tǒng)結(jié)構(gòu)Fig.1 Structure of workflow management system

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

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

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

可以說,引入工作流技術(shù),使我們從繁瑣的業(yè)務(wù)過程邏輯處理中找出一種統(tǒng)一的解決途徑。

3 方案設(shè)計

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

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

本文根據(jù)任務(wù)調(diào)度軟件的需求,設(shè)計并實現(xiàn)了一個流程引擎內(nèi)核[10-12]。設(shè)計方案中所包含的主要類以及類之間的靜態(tài)關(guān)系如圖3所示。

圖3 引擎內(nèi)核類圖Fig.3 Class diagram of workflow engine' s core

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

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

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

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

4 驗證與分析

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

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

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

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

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

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

5 結(jié)束語

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

圖6 不同執(zhí)行結(jié)果Fig.6 Different results af ter executing

References)

[1]王瑞,李曉輝,朱家佳,等.遙感衛(wèi)星地面站業(yè)務(wù)運行管理系統(tǒng)模型和流程設(shè)計方法[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]賀然,徐京,王揚.設(shè)計模式在任務(wù)調(diào)度軟件中的應(yīng)用[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 的區(qū)別[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].計算機應(yīng)用研究.2009,26(11)

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

[13]齊同曄.基于狀態(tài)轉(zhuǎn)換的工作流驗證的研究與實現(xiàn)[D].大連理工大學(xué),2009,7