支持快速構建領域應用系統的業務過程模型研究

摘要：針對基于業務基礎平臺快速構建領域應用系統，建立了業務過程模型BPM4DBL(business process model for dynamic business logic)。模型中包括活動和規則元素，可以描述領域應用中宏觀實體和微觀知識結構；給出了模型中元素的構建步驟和原則，并定義了模型向XPDL（XML process definition language）和BPEL4WS(bussiness process execution language for Web service)的映射規則，從而支持領域應用系統的快速構建。最后給出了一個具體的應用實例。

關鍵詞：業務過程模型；領域應用系統；業務基礎平臺

中圖分類號：TP311文獻標志碼：A

文章編號：1001－3695(2008)03－0744－05

0引言

在動態多變的市場環境中，如何在成本和質量指標約束下快速構建滿足用戶個性化需求的應用系統，是當前領域應用系統開發中面臨的挑戰。業務基礎平臺[1，2]一方面提供可直接適用于不同領域應用系統的基礎模塊，如組織結構管理、日志管理和安全管理模塊，以及與中間件和數據庫的連接模塊；另一方面提供了業務過程模型驅動的領域應用系統開發框架，從而可以提高系統的開發效率及適應用戶需求的動態變化。因此，業務基礎平臺的研究目前得到學術界和工業界的廣泛重視。本文研究如何構建適應領域應用基礎平臺中的業務過程模型。

目前研究者已經建立了各種業務過程模型，而每種模型一般具有特定的適用范圍。文獻[3，4]通過總結近20年的業務過程模型研究，根據構建目標將其分為三類：應用于業務過程的一般性描述，如甘特圖和IDEF3模型；應用于業務過程重組，如流程圖和IDEF0模型；應用于軟件系統開發和執行，如工作流、OMT和著色Petri網模型。本文所研究的業務過程模型屬于第三類。業務基礎平臺中業務過程模型需要適應兩類領域應用的動態性變化：a）業務功能的動態性，即業務應用中領域知識或領域邏輯的變化；b）業務結構的動態性，即業務應用中任務的數目或執行順序等發生變化。因此，如何在統一的模型框架下反映上述兩類動態性，成為支持業務基礎平臺中業務過程模型的關鍵[5，6]。

本文在給出業務基礎平臺概念的基礎上，定義了支持領域應用系統快速構造的業務過程模型BPM4DBL。

1領域應用系統的快速構造

本文中領域應用系統主要面向業務密集型領域，如金融、保險、通信和電子政務等業務系統。一般來說，該類系統的業務層具有復雜多變的業務邏輯，技術層架構于數據庫和中間件平臺之上；同時，業務層表現為領域相關的業務實體，技術層表現為數據結構和函數等程序對象。因此，業務層和技術層之間的語義“鴻溝”以及技術層實現的復雜性使技術人員很難快速構造領域應用系統。業務基礎平臺試圖縮小這種“鴻溝”以及降低技術層開發的復雜度，它用業務過程模型表示業務邏輯，通過業務過程引擎實現模型執行的自動化，并且封裝引擎與中間件、數據庫和操作系統的基礎設施接口模塊，從而屏蔽技術層的實現細節。本文將業務過程引擎及各個公共接口模塊統稱為業務過程執行環境。

圖1（a）為業務基礎平臺在軟件系統中的位置[2]；（b）為業務基礎平臺的結構。包括業務基礎平臺的軟件系統結構從底向上依次分為四層，即操作系統、數據庫、中間件和業務基礎平臺。其中：業務過程模型既是面向不同的領域應用、領域用戶可理解的業務邏輯表示，又是系統開發技術人員可以通過業務過程執行環境驅動的可執行程序對象。業務過程模型一方面適應不同領域應用背景；另一方面又通過業務過程執行環境屏蔽了執行中的技術細節，從而在業務邏輯的可變性和技術的標準性之間獲得恰當的平衡，由此提高開發效率。

基于業務基礎平臺的系統構建采用業務過程模型驅動的開發方法：領域專家和軟件開發技術人員首先構造BPM4DBL 模型，同時針對具體的領域應用需求設計特定的業務功能模塊；技術人員在業務過程執行環境中對BPM4DBL 模型進行調試，獲得正確、合理的模型，同時實現特定的業務功能模塊；最后對BPM4DBL 模型和業務功能模塊集成測試，獲得可靠的應用系統。需要指出的是，隨著業務基礎平臺的成熟，針對不同領域應用需要訂制的業務功能模塊會逐漸減少，而公共模塊則會逐漸擴充。由此可見，基于業務基礎平臺的系統構造只需要建立BPM4DBL 模型和訂制少量的業務功能模塊，并且通過BPM4DBL 模型適應業務邏輯的變化。BPM4DBL 模型因此成為業務基礎平臺成敗的關鍵。

2BPM4DBL 模型

一般來說，業務過程是活動的有序集合，通過活動之間結構化的邏輯偏序和依賴關系實現企業或組織的預定目標。由于本文著眼于業務密集型領域，為了適應領域應用基礎平臺業務過程的動態性，BPM4DBL 模型應該具有下述特點：a)可以從微觀層面描述領域知識或領域邏輯的內容，如政策和法規約束等，即領域應用是做什么（what）的；b)可以從宏觀層面描述領域應用中各個實體之間的關系，如前驅和后繼等依賴，即領域應用是如何做（how）的。同時從應用層來說，BPM4DBL 模型需要便于領域專家和開發技術人員的定義，從技術層來說BPM4DBL 模型需要支持分布式計算環境的動態執行。

2．1BPM4DBL 概念模型

BPM4DBL中概念模型既需要表達微觀層面的領域知識或邏輯，又需要描述宏觀層面實體之間的關系。業務規則可以方便地描述動態多變的領域知識或邏輯，但缺乏對業務實體結構間關系的宏觀表達，而業務實體結構間的關系則可以通過業務實體語義來表達。為方便描述及突出主題，下面的概念模型定義中只給出了過程的基本屬性，其他屬性如活動的名稱、相關數據和活動的時間限制等則忽略。

定義1BPM4DBL模型為四元組，BPM4DBL={AS，RS，RuleS，ES}。其中：AS為活動集；RS為活動間的結構關系集；RuleS為規則集；ES為活動或規則的觸發事件集。

上述定義中，AS表示模型的基本業務實體集，RuleS表示易變的領域知識或邏輯，同時，RuleS可以引用AS中的元素。

定義2活動集AS={ai|i∈N}，ai為集合中一項活動，N為自然數集。

在ai中活動類型包括遞階型和一般型兩種。其中：遞階型活動a′是指活動是粗粒度的，可細分為一個完整的或部分子BPM4DBL模型；一般型活動a″是指活動是細粒度的，不可以再遞階。另外，一般型活動中引入虛活動av，其不執行任何操作，只用于構造復雜活動之間的結構關系。

定義3遞階型活動a′={AS，RS，RuleS，ES}∨{AS，ES}∨{RuleS，ES}∨{AS，RS，ES}∨{AS，RuleS，ES}。其中：{AS，ES}、{RuleS，ES}、{AS，RS，ES}和{AS，RuleS，ES}分別是BPMDS的子結構。

定義4一般型活動a″={id， state，type，idata，odata，ioexp，impl，performer}。其中：id為活動標志；type為活動類型，分為auto/manual和empty/invoke/receive/reply/user兩個聚類，分別用于表示企業內部和企業間活動；state為活動狀態，包括就緒、運行、取消、終止和完成；idata和odata分別為輸入和輸出數據變量或常量；ioexp為輸入或輸出數據變量的賦值表達式；impl為活動的外部激活應用，屬性包括participant/interface/operation；performer為活動的執行者。

從定義3可以看出，遞階型活動可以只包括活動集和事件集，如{AS，ES}和{AS，RS，ES}結構。其前者結構AS集中為單項活動，后者結構AS集中活動為偏序關系；同時也可以只包括規則集和事件集，如{RuleS，ES}結構。另外，{AS，RuleS，ES}結構AS集中為單項活動。從上述定義也可以看出，每一個結構中都包括事件集ES，子結構的每次遷入和遷出都由活動的事件觸發。由定義3可知，虛活動av中type、state、idata、odata、iorules和performer都為空。

定義5活動結構關系集RS={ri|i∈N}。其中：r1和r2、r3和r4、r5和r6、r7和r8分別為與分支/匯聚、或分支/匯聚、異或分支/匯聚、順序/循環關系；r9和r10為KN分支/匯聚關系。

與分支/匯聚、或分支/匯聚、異或分支/匯聚、順序/循環關系的定義可參見文獻[5]，它們稱為活動之間的基本結構關系；KN分支/匯聚結構關系通過引入虛活動可以表達相鄰多個活動之間復雜的依賴關系。KN分支結構關系中，K指活動的相鄰后繼分支活動中有K個活動之間是與關系，其余N個分支中的活動與前述K個活動之間是或關系。KN匯聚結構關系中，K指活動的前驅分支活動中有K個活動之間是與的關系，其余N個分支中的活動與前述K個活動之間是或關系。同時，對于活動的分支/匯聚結構關系中存在K個活動之間的異或結構關系，也歸并為KN分支/匯聚結構。

活動集合AS描述了業務過程中的基本實體對象，RS描述了相鄰實體對象間的結構依賴關系。對于RS中r3、r4、r5、r6、r8、r9和r10結構關系來說，其需要控制變遷的觸發或變遷觸發的次序；同時，對于AS中非相鄰實體對象之間的約束依賴，或者單個實體對象控制自身行為方面的約束，都需要通過規則集中的規則進行描述。

定義6規則集RuleS={StruRuleS∪ActioRuleS}。其中：StruRuleS為結構規則子集；ActioRuleS為行為規則子集；StruRule、ActioRule分別表示集合中的結構規則和行為規則。

結構規則描述r3、r4、r5、r6、r8、r9和r10中變遷觸發控制條件，以及AS中非相鄰實體對象之間的約束依賴關系，如規則“ai的輸出值大于0”表示變遷觸發控制條件；行為規則描述AS單項活動中內部行為或外部資源的約束，如規則“ai的執行成員是其所屬業務過程啟動成員的直接負責人”。

定義7結構規則StruRule={term，fact}。其中：term為術語集；fact為事實集。

術語是業務過程中的基本實體對象、對象屬性以及業務過程資源和外部引用的特定表達，如“ai”和“ai的名稱”為術語；事實表示術語之間的關系，即fact={Rl(term)}，Rl為術語之間的關系符號，其中基本關系包括比較、成員、屬性、參與和繼承關系，如“aj的輸入數據是ai的輸出數據”為參與關系。另外，根據具體的領域應用可以擴展術語之間的關系。

定義8行為規則ActioRule={RuleWord(StruRule)}。其中RuleWord為規則詞，基本的規則詞包括如果-那么、必須、允許和禁止。

從定義7可以看出，行為規則通過規則詞和結構規則構建，但其作用對象是AS中單項活動。行為規則分為條件、一致性和權屬規則。條件規則定義給定條件下某種結果，規則詞為如果-那么；一致性規則為永真斷言，規則詞為必須；權屬規則定義某主體是否有某行為的權利，又可分為授權規則和禁止規則，授權規則定義主體有權（或被允許）進行某行為，規則詞是允許；禁止規則定義主體無權（不允許）進行某行為，規則詞是禁止。

定義9事件集ES={eventi|i∈N}。其中：eventi為集合中單項事件。

定義10 事件event={id，type，tr，ar}。其中：id為事件標志；type為事件類型，包括開始、結束和內部；tr為各類事件的觸發點。其中：開始事件觸發點包括時間和消息；結束事件觸發點包括消息、終止和異常；內部事件觸發點包括時間、消息和異常；ar為觸發點的屬性。其中：時間觸發點屬性包括日期和循環周期：消息觸發點屬性包括實現名稱；錯誤觸發點屬性包括錯誤代碼名稱；終止事件點表示過程的所有實例結束，屬性為空。

開始和結束類型的事件一般針對過程層，即每一過程的啟動和終止由開始和結束事件表示；內部類型的事件針對具體活動或規則，即活動的狀態變遷由相應事件點觸發。業務過程執行時，開始事件首先觸發流程執行，活動或規則的驅動由事件觸發，同時在活動或規則中可以引入相對或絕對時間約束，時間約束的邊界則作為時間事件的觸發點。需要指出的是，此處規則的時間約束是指規則或規則集作為整體而被啟動或執行的時間邊界，而非規則內部與時間相關的內容。ES為活動和規則的觸發事件集，事件觸發引起活動或規則狀態的變化，同時，活動或規則執行又觸發ES中相應的事件，如此往復直至業務過程執行結束。

在BPM4DBL模型中活動集AS、活動間結構關系集RS、規則集RuleS和事件集ES四類元素中，AS和RuleS是BPM4DBL 模型的實體構成元素。其中：AS反映了領域應用中的基本實體對象；RuleS反映了實體對象或實體對象間的業務邏輯。RS和ES是BPM4DBL 模型的連接元素。其中：RS描述了領域應用中相鄰活動之間結構上的控制依賴；ES則定義了AS和RuleS、RuleS和RS相互連接的方式。在建立BPM4DBL 模型時，如何根據具體的領域應用合理定義上述四類元素是構造BPM4DBL 模型的關鍵。

2．2BPM4DBL概念模型中基本元素構建方法

BPM4DBL概念模型中基本元素的構建遵循自頂向下、逐步細化的原則，步驟如下：a）識別領域應用中的頂層活動集。該集合中活動一般為遞階型，不包括虛活動。對頂層活動集中遞階型活動進行分解，直至其所有子活動均為原子活動為止，由此得到聚合程度不同的多層次活動集。b）建立各層活動集中活動之間結構上的控制依賴，即確定每一活動的前驅和后繼活動，建立鄰接和非鄰接活動之間的結構規則，并可加入虛活動來滿足復雜的結構約束；針對活動集中每項活動分析其內部行為或外部資源約束，構建活動的行為規則。c）對于每項活動和規則確定事件觸發點，并且通過時間約束設定其時間觸發事件點。

BPM4DBL概念模型中的活動和規則對象分別是從整體和局部對領域應用的描述，體現了關注點分離原則。恰當的關注點則是模型保持動態性并且適應業務基礎平臺的關鍵。模型構建時應遵循以下準則：

a）粒度適中準則。對企業內部的領域應用來說，活動分解為由單個組織、角色或成員負責執行的粒度，而組織內部成員或角色之間的協作方式由規則來定義；對于企業之間的領域應用來說，活動一般以企業對外暴露的單項功能操作為粒度大小。

b）優先級準則。當通過活動粒度的進一步分解或者大粒度活動和規則結合均可以描述領域應用時，優先取后者；當通過引入新活動或增加新規則均可以描述領域應用時，優先取后者。

c）沖突準則。規則加入前，需要檢測其與活動結構之間是否存在沖突，存在沖突的規則不被加入到規則集中。活動集中活動的名稱、屬性和數量修改時，需要檢測其與規則集中的規則是否存在沖突，存在沖突的規則應被維護。

d）一致性準則。結構規則應與活動間的結構關系相一致，活動間結構變遷應該關聯于恰當的結構規則。

根據上述構建過程和準則，可以確定領域應用的BPM4DBL 概念模型中的基本元素。然而，業務基礎平臺中業務過程引擎需要通過驅動可執行的業務過程語言來得到過程的自動執行。同時為了支持引擎之間的互操作，執行層的語言應該遵循一致的標準。因此BPM4DBL 概念模型需要映射到標準的可執行語言。

2．3 BPM4DBL執行層語言

工作流管理聯盟制定的XPDL[7]和IBM等制定的BPEL4WS[8]分別是面向企業內部和企業間應用事實上的業務過程標準執行語言，得到了研究界和工業界的廣泛支持，同時，這兩類語言的重點在于領域應用中宏觀層面業務實體結構間關系的描述，而未顯式給出微觀層面領域知識或邏輯的表示。為此，通過對XPDL和BPEL4W進行擴展，本文將其分別作為BPM4DBL 面向企業內部和企業間應用的執行層語言。下面給出XPDL和BPEL4W的擴展方式及具體映射規則。

2．3．1BPM4DBL 面向企業內部應用的執行語言

XPDL的基本語義元素包括activity、transition和dataField等，并且定義了各個元素的屬性；同時各個基本元素提供了屬性擴展機制。由此可以在不改變XPDL語義情況下，表達BPM4DBL 中規則語義。

BPM4DBL與XPDL之間映射的方法是：根據BPM4DBL 概念模型中的基本元素，分析XPDL的語義相近元素，對語義相近元素進行映射；若BPM4DBL中的元素在XPDL中不存在相近語義元素，則將其映射到XPDL中基本元素的擴展屬性或進行語義轉換。表1為具體映射規則。

表1BPM4DBL 與XPDL的映射規則

BPM4DBL元素所映射的XPDL中元素

a″a″與activity語義相近，但存在差異，兩者不能進行直接映射，但其中屬性值或元素的狀態可以進行如下的映射

a″.state映射為activity。XPDL中未顯式給出狀態概念，若將activity理解為活動的當前狀態，則a″中每一不同狀態對應于XPDL中惟一的activity

a″.type映射為activity中的startMode和finishMode，值為automatic或manual

a″.idataa″.odata映射為dataField，其dataType由a″.odata、a″.odata的類型確定

a″.ioexp映射為dataField中的description。其中：description中可以引用a″.idata和a″.odata，并且根據其表達式確定Script元素的Type為Java、Java Script或Python等

a″.impl屬性Interface映射為FormalParameter，屬性Operation映射為Application，屬性Participant不作映射

a″.performer

映射為activity中的performer。其中：description中可以引用a″.idata和a″.odata，并且根據其表達式確定Script元素的Type為Java、JavaScript或Python等

r1、r2、r5、r6映射為transition。其中：transition屬性元素condition、description和extendedAttributes設置為空；另外，還需要設置各結構關系中activity的transitionRestriction值。其中：r1和r5的值為split；r2和r6的值為join。同時，r1和r5中split元素、r2和r6中join元素的type屬性分別設置為AND和XOR

r3、r4、r7、r8映射為transition。其中：transition屬性元素condition非空，其值由結構規則確定（見下文）；另外，需要設置結構關系中activity的transitionRestriction值。其中：r3和r7的值為split；r4和r8的值為join，并且split和join元素的type屬性都為XOR

StruRuleSStruRuleS中term類型為比較關系的規則映射為transition中的condition，其余類型的規則映射為activity的extendedAttribute。其中：activity是term直接引用或者是屬性相關的activity

ActioRule映射為activity的extendedAttribute。其中：activity是StruRuleS中term的直接引用或者是屬性相關的activity

event映射為deadline。XPDLSchema中未包括顯式的event語義，但通過定義活動和規則的各個事件點變量，以及由事件點變量設置activity中deadline的deadlineCondition，可以通過deadline模擬活動和規則的事件

通過上述映射規則，可以將BPM4DBL 中基本元素映射為XPDL中元素或其擴展屬性。對于BPM4DBL 中復合元素a′，首先將其映射為XPDL中的blockActivity；其次遞歸分解a′至基本元素；然后由上述映射規則得到blockActivity中各個元素。BPM4DBL 映射后可以得到XPDL的基本元素，但映射后XPDL中的processHeader、redefinableHeader和version等描述性屬性可以根據實際情況單獨設定或者保持為空。

2．3．2BPM4DBL面向企業間應用的業務過程執行語言

BPEL4WS描述了多個Web service的復合方法，可以表達順序、并行、同步和異步復合形式，包括empty、invoke、receive、reply基本活動元素，sequence、switch、while、pick和flow結構活動元素以及partners、variables和correlationSets等上下文元素。

BPM4DBL 的規則元素與BPEL4WS中元素映射分為兩種方法:a)將BPM4DBL 中規則映射為Web service，并且定義message、portType和property等Web service屬性；b)在新命名空間中建立規則中各元素和屬性的表達式，并且在BPEL4WS中通過擴展類型extensibleElement引用。第一種方法不引入新命名空間及其元素，簡化了兩者之間的映射，能以較大的粒度描述BPM4DBL中的規則；第二種方法便于通過建立適合規則元素和屬性的表達式更加精細地刻畫BPM4DBL中的規則，同時也增加了BPEL4WS模型的復雜度。另外，兩種方法對業務過程執行環境也有不同的要求。本文采用第一種方法。表2給出了BPM4DBL中元素與BPEL4WS元素的映射規則。

通過上述映射規則，可以將BPM4DBL 中基本元素映射為BPEL4WS中基本活動和結構活動。對于BPM4DBL 中復合元素a′，首先將其映射為〈scope〉塊結構活動，其次遞歸分解a′至基本元素，然后根據上述映射規則得到〈scope〉中各個元素。需要指出的是，BPEL4WS文件中的Web service和message properties的定義需要在WSDL文件中描述，因此BPM4DBL 中活動屬性及映射應該生成WSDL文件；同時，BPEL4WS本身具有相關的語義約束，如流程的初始活動類型必須為〈receive〉，并且其〈createInstance〉值應為“yes”等，映射后生成的流程文件應該符合上述約束。另外，BPM4DBL 模型映射后所生成的各個元素應當根據BPEL4WS語義定義合理設定其位置。

3應用實例

在一個涉及跨部門的政府審批流程中，部門1在接收到審批請求后開始審批，若審批通過，則部門2和3并行審批，若審批通過后由部門4審批，部門4審批通過則流程結束。每個部門在一周之內未給出審批結果時，需要給出提醒通知；同時，部門1審批不通過則流程結束，部門2~4中任何部門審批不通過則返回部門1重復審批流程。另外，部門2的審批為子流程，部門3審批中涉及到易變的業務邏輯計算。

下面給出BPM4DBL 對該流程的描述：AS包括活動a1、a2、a3和a4，分別表示部門1~4的審批活動。其中:a2為遞階型活動；RS包括r1和r2兩類結構關系，即a1與a2、a3之間為與分支關系，a2、a3與a4之間為與匯聚關系；RuleS結構規則中的Term包括a1.x，a2.x。其中：a1.x為a1的輸出變量；a2.x為a2的輸出變量。AS活動之間變遷不存在觸發控制條件，因此AS結構規則中的Fact為空。由于a3中涉及到易變的業務邏輯計算通過行為規則表示，即ActioRule1:if a1.x<=A then a2.x=C;ActioRule2:if a1.x＞A then a2.x=D。ES包括開始、結束和內部類型事件。其中AS中所有活動的內部事件時間觸發點日期屬性設置為一周，開始事件的觸發點為消息，結束事件的觸發點為空。為簡化起見，a2的子流程不再具體說明。

由于是跨部門的審批流程，BPM4DBL 模型應該映射為BPEL4WS。下面具體說明映射過程：

a）映射流程的開始事件。開始事件映射為〈receive〉元素，并由消息屬性定義〈receive〉的屬性。

b）映射活動集中的活動。根據活動的類型映射a1、a2、a3和a4為〈invoke〉元素，并且由活動屬性定義〈invoke〉的屬性；a2為遞階活動，所映射的〈invoke〉屬性name為子流程名稱。

c）映射活動間結構關系。r1和r2映射為〈flow〉元素，并且定義〈flow〉中的〈link〉元素分別為r1和r2中的連接弧名稱。

d）映射ActioRule1和ActioRule2。ActioRule1和ActioRule2組成的規則集名Ars映射為〈input〉元素，Ars的推理結果Arr映射為〈output〉元素，并且定義〈operation〉元素名為規則推理引擎名。

根據BPEL4WS語義設定映射后生成各個元素的位置，則該審批流程的BPEL4WS描述為

〈process name=\"examineandapproveProcess\"〉

〈sequence〉

〈receive partnerLink=\"\" portType=\"\" operation=\"\" variable=\"\" createInstance=\"yes\" /〉

〈invoke name=\"\" partnerLink=\"\" portType=\"\"operation=\"\" inputVariable=\"a1x\" outputVariable=\"a1x\" /〉

〈switch name=\"Depar1Notion\"〉

〈case condition=\"bpws:getVariableProperty(a1x)=true\"〉

〈flow〉〈links〉

〈link name=\"a1toa2\" /〉

〈link name=\"a1toa3\" /〉

〈link name=\"a2toa4\" /〉

〈link name=\"a3toa4\" /〉

〈/links〉

〈scope〉 〈faultHandlers〉

〈catch faultName=\"7days_Notify\"〉

〈invoke name=\"\"〉 〈/catch〉

〈/faultHandlers〉

〈eventHandlers〉

〈onAlarm for=\"tns:oneWeek\"〉

〈throw faultName=\"7days_Notify\"〉

〈/onAlarm 〉

〈/eventHandlers〉

〈invoke name=\"Depa2Examine_Cycle_Process\" partnerLink=\"Internal\" portType=\"tns:processPort\" operation=\"call_Depa2Examine_Cycle_Process\" inputVariable=\"a2x\" outputVariable=\" a2x\"〉

〈target linkName=\"a1toa2\" /〉

〈source linkName=\"a2toa4\" /〉

〈/invoke〉

〈invoke name=\"Depa3Examine\" partnerLink=\"Internal\" portType=\"tns:processPort\" operation=\"ruleEngine\" inputVariable=\"Ars\" outputVariable=\"Arr\"〉

〈 target linkName=\"a1toa3\" /〉

〈source linkName=\"a3toa4\" /〉

〈/invoke〉

〈invoke name=\"Depa4Examine\" partnerLink=\"Internal\" portType=\"tns:processPort\"operation=\" depa4Examine\" 〉

〈 target linkName=\"a2toa4\" /〉

〈 target linkName=\"a3toa4\" /〉

〈/invoke〉

〈/scope〉

〈/flow〉

〈/case〉

〈otherwise〉

〈empty/〉

〈/otherwise〉

〈/switch〉

〈/sequence〉

〈/process〉

需要說明的是，同時映射生成的還有對Web service定義的WSDL文件，如規則集名Ars和其推理結果Arr即在WSDL文件中定義，此處略去。

4結束語

業務基礎平臺作為軟件系統的開發環境，可以滿足業務密集型領域應用中動態多變的業務邏輯，并且能提高軟件系統的開發效率；而創建適合描述業務密集型領域應用中多變業務邏輯的業務過程模型，則是基于業務基礎平臺快速構建應用系統的關鍵。本文通過對業務密集型領域應用中業務過程特點的分析，定義了融合微觀領域知識和宏觀實體結構的業務過程模型BPM4DBL 的元組表達，并且給出了模型的構建原則，從而適應領域應用中功能的動態性和結構的動態性；同時定義了BPM4DBL 向XPDL和BPEL4WS的映射規則，從而使模型在執行層面遵循一致的標準，支持業務基礎平臺的互操作。如何用適當的形式化方式表示BPM4DBL ，并且由此對其進行正確性、合理性和性能等分析，是下一步工作的重點。

參考文獻：

［1］HELLER D，KRENZELOK L，ORR J.Webtop:Realities in designing a Webapplication platform[C]//Proc of Conference on Designing for User Experiences.New York:ACM Press，2004:115.

[2]計世資訊.中國軟件平臺產業發展戰略研究[EB/OL]．(2004).http://www.ccwresearch.com.cn/.

[3]AGUILARSAVEN R S．Business process modelling:Reviewand framework[J]．Internal Journal of Production Economics，2004，90（2）：129－149.

[4]LINDSAY A，DOWNS D，LUNN K．Business processesattempts to find a definition[J]．Information and Software Technology，2003，45（15）：1015－1019.

[5]BERGHOLTZ M，JAYAWEERA P，JOHANNESSON P，et al．Process models and business models:a unified framework[C]//Lecture Notes in Computer Science.Berlin:Springer，2003:364－377.

[6]GORDIJN J，AKKERMANS H，VLIET H van．Business modelling is not process modelling[C]//Lecture Notes in Computer Science.Berlin:Springer，2000:40－51.

[7]Workflow Management Coalition．XML process definition language[EB/OL].(2005).http://www.wfmc.org.

[8]Business process execution language for Web services version 1.1[EB/OL]．(2003).http://www128.ibm.com.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”