最近結(jié)束了一個(gè)企業(yè)OA系統(tǒng)的項(xiàng)目，客戶是一家海洋航運(yùn)行業(yè)的企業(yè)，散運(yùn)業(yè)務(wù)全球第一。該系統(tǒng)以工作流系統(tǒng)為基礎(chǔ)平臺(tái)，對(duì)員工工作進(jìn)行電子化和規(guī)范化，由系統(tǒng)來(lái)驅(qū)動(dòng)員工自動(dòng)、快捷、可管地完成日常工作。在開(kāi)發(fā)過(guò)程中，在綜合評(píng)比多種工作流產(chǎn)品之后，我們選擇了開(kāi)源工作流產(chǎn)品——OSworkflow作為底層工作流引擎支撐，通過(guò)擴(kuò)展OSworkflow的接口把業(yè)務(wù)系統(tǒng)和工作流引擎完美無(wú)縫地集成在一起。本文就是跟大家一起分享osworkflow擴(kuò)展過(guò)程中的經(jīng)驗(yàn)心得，希望能對(duì)其他朋友有幫助。
在我們開(kāi)發(fā)團(tuán)隊(duì)介入系統(tǒng)開(kāi)發(fā)過(guò)程之前，這個(gè)項(xiàng)目已經(jīng)完成了 quickstart 階段，留給我們的階段產(chǎn)品有：系統(tǒng)實(shí)現(xiàn)的proposal、一個(gè)能體現(xiàn)用戶page flow的lo-fi，以及在mingle上的 story list和iteration原始計(jì)劃。當(dāng)然，還有項(xiàng)目團(tuán)隊(duì)跟客戶形成的一個(gè)良好的互信基礎(chǔ)和溝通渠道。于是，左 proposal，右 lo-fi，客戶溝通在中間，我們就開(kāi)始了系統(tǒng)設(shè)計(jì)的 inception。inception階段的目標(biāo)根據(jù)不同項(xiàng)目會(huì)有不同。在這個(gè)系統(tǒng)里面，我們完成的目標(biāo)有：確定系統(tǒng)實(shí)現(xiàn)使用的技術(shù)、針對(duì)技術(shù)進(jìn)行spike探討可行性、結(jié)合master story以及比較粗略的story list實(shí)現(xiàn)一個(gè)系統(tǒng)prototype。好，工作開(kāi)始了！
為什么選擇OSworkflow？
工作流系統(tǒng)其實(shí)在理論界已經(jīng)是研究得非常成熟了，有 WfMC 組織來(lái)規(guī)范工作流定義語(yǔ)言，而且各種工作流引擎，不僅商業(yè)產(chǎn)品，像 JBPM、OSworkflow、ofbiz等開(kāi)源產(chǎn)品也都很多。這些產(chǎn)品都各有特點(diǎn)，應(yīng)該如何選擇呢？從使用率和文檔完整度來(lái)看，JBPM 和 OSworkflow 占了上風(fēng)，我們就從這兩者里面選了。JBPM基于UML的狀態(tài)圖和活動(dòng)圖來(lái)定義流程，已經(jīng)加入JBOSS大家庭，但是相對(duì)比較重。osworkflow是個(gè)非常輕量級(jí)的工作流產(chǎn)品，但是自從2006年就停止活動(dòng)了。不管如何，選擇的技術(shù)都是要為解決未來(lái)系統(tǒng)開(kāi)發(fā)會(huì)面臨的問(wèn)題，才算是一個(gè)好的可行的選擇。
通過(guò)分析quickstart階段的proposal和lo-fi prototype，然后再反復(fù)跟客戶確認(rèn)，我們知道了客戶在現(xiàn)階段對(duì)系統(tǒng)的要求是：
-
只需要處理線性的工作流（未來(lái)可能需要增加對(duì)分支/合并的支持）
-
不需要功能復(fù)雜強(qiáng)大的工作流編輯器
-
節(jié)點(diǎn)流轉(zhuǎn)主要是手工觸發(fā)，不需要基于規(guī)則
-
需要能和遺留系統(tǒng)已有的工作流定義集成，而已有工作流定義用 osworkflow 定義
根據(jù)客戶對(duì)系統(tǒng)的要求，我們選擇了osworkflow作為最終的候選工作流引擎。因?yàn)槲覀儗?duì)這幾種工作流產(chǎn)品都不是很熟，對(duì)它們是否能滿足系統(tǒng)要求答案不確定。而從另外一個(gè)方面來(lái)講，如果系統(tǒng)足夠簡(jiǎn)單，我們也可以自己實(shí)現(xiàn)一個(gè)狀態(tài)機(jī)，自己實(shí)現(xiàn)對(duì)流程節(jié)點(diǎn)流轉(zhuǎn)的維護(hù)。
為了做出選擇，我們又分頭對(duì) osworkflow 的配置文件以及技術(shù)架構(gòu)都進(jìn)行了細(xì)致的研究。研究過(guò)程和結(jié)果就不細(xì)說(shuō)了，網(wǎng)上有很多 OSworkflow 的介紹文章，大家可以參照。OSworkflow 會(huì)把一個(gè)簡(jiǎn)單的xml配置文件，轉(zhuǎn)換成它定義的流程描述類（XXXDescriptor，我們也把它們稱為osworkflow的models），然后在流轉(zhuǎn)的過(guò)程中，將其轉(zhuǎn)換成工作流實(shí)例和工作流節(jié)點(diǎn)，并通過(guò)相應(yīng)的持久化接口持久化工作流的狀態(tài)。整個(gè)過(guò)程用一個(gè)簡(jiǎn)圖來(lái)表示，就會(huì)是：
圖1 OSworkflow model
考慮到 OSworkflow 的實(shí)現(xiàn)也是非常輕量級(jí)，并且結(jié)構(gòu)非常清晰，而且為了提供以后對(duì)分支/合并、以及自定義規(guī)則等流轉(zhuǎn)形式的支持，我們還是選擇了 OSworkflow，而不是自己去實(shí)現(xiàn)一個(gè)基于狀態(tài)機(jī)的工作流引擎。但是，我們還不能直接把 OSworkflow 放進(jìn)項(xiàng)目里面，然后直接引用：一方面我們不想讓開(kāi)發(fā)團(tuán)隊(duì)都糾纏于底層 OSworkflow 的技術(shù)細(xì)節(jié)，另外一方面也是因?yàn)?OSworkflow 并不能完全滿足客戶的系統(tǒng)要求。我們需要擴(kuò)展！
為什么去擴(kuò)展？
依然是問(wèn)答模式，OSworkflow 有哪些方面不能滿足我們系統(tǒng)的要求？
1. 系統(tǒng)對(duì)各個(gè)流程的定義都能有版本跟蹤
客戶會(huì)對(duì)流程定義進(jìn)行修改，但是流程修改的過(guò)程中，流程應(yīng)該繼續(xù)按照原來(lái)的定義進(jìn)行流轉(zhuǎn)。這樣，對(duì)于同一份流程，系統(tǒng)會(huì)同時(shí)存在兩個(gè)不同的定義，并且都能正常流轉(zhuǎn)。OSworkflow 基于XML文件的流程配置方式在這種情況下就不能滿足。
2. 系統(tǒng)對(duì)流程定義的修改能實(shí)現(xiàn)“hot deploy”
客戶對(duì)流程定義進(jìn)行修改后，系統(tǒng)能自動(dòng)提供給用戶新的流程定義，而不需要重啟服務(wù)器。因?yàn)?OSworkflow 是在系統(tǒng)啟動(dòng)的時(shí)候，將所有的流程定義都載入內(nèi)存，在系統(tǒng)運(yùn)行期不會(huì)去檢測(cè)流程定義的修改。這樣，OSworkflow 也不能滿足。
3. 相對(duì)于系統(tǒng)的要求，OSworkflow 提供的功能還是太復(fù)雜了
因?yàn)?OSworkflow 是提供一個(gè)通用的工作流引擎，所以考慮了很多復(fù)雜的情況。這些復(fù)雜性對(duì)我們系統(tǒng)來(lái)講，都是額外的不能對(duì)客戶產(chǎn)生價(jià)值的特性，而且那些復(fù)雜性的存在，也會(huì)讓我們開(kāi)發(fā)的時(shí)候必須考慮到那些方面，從而影響我們的模型設(shè)計(jì)和開(kāi)發(fā)。
除了上文提到的幾個(gè)原因，我們考慮的因素還有很多方面，最終我們決定是在OSworkflow基礎(chǔ)上進(jìn)行擴(kuò)展，來(lái)滿足我們的要求。
如何進(jìn)行擴(kuò)展？
如何進(jìn)行擴(kuò)展？我們的原則是什么？沒(méi)有一個(gè)清晰的目標(biāo)，很可能最終擴(kuò)展的方向和最終實(shí)現(xiàn)就會(huì)跟我們想要的目標(biāo)離得比較遠(yuǎn)了。
原則一. DDD，MDA
我們希望開(kāi)發(fā)團(tuán)隊(duì)在設(shè)計(jì)開(kāi)發(fā)的過(guò)程中只需要考慮系統(tǒng)領(lǐng)域的模型，而不會(huì) involve 到底層的流程流轉(zhuǎn)細(xì)節(jié)。
“find core domain models”，我們重新研究了系統(tǒng)的 proposal 和 lo-fi prototype，找出系統(tǒng)里面的領(lǐng)域?qū)ο螅鼈冎g存在這樣的一個(gè)關(guān)系：
圖2 系統(tǒng)model
從圖1 OSworkflow model 關(guān)系圖和圖2 系統(tǒng) model 關(guān)系圖可以看出，它們兩者還是存在著一定的相似點(diǎn)和不同點(diǎn)的。
相同點(diǎn)：
1. 相應(yīng) model 完成的功能和職責(zé)是非常類似的
2. 不同 model 之見(jiàn)的關(guān)系也是非常類似的
不同點(diǎn)：
1. model 的屬性
2. model 的一些行為
原則二. decoupling
我們希望項(xiàng)目實(shí)現(xiàn)不依賴于某個(gè)工作流產(chǎn)品，而是可以很方便地遷移到其他的工作流產(chǎn)品。第一想法就是——“laying, isolate by interface”。
其實(shí)工作流產(chǎn)品除了工作流引擎負(fù)責(zé)流程節(jié)點(diǎn)流轉(zhuǎn)之外，都另外包括這三部分：流程定義、定義解析和狀態(tài)持久化。而成熟的工作流產(chǎn)品，不管是JBPM，還是OSworkflow，都會(huì)提供接口進(jìn)行隔離。在OSworkflow里面，接口WorkflowFactory會(huì)負(fù)責(zé)流程定義的解析和OSworkflow models的初始化，接口WorkflowStore則負(fù)責(zé)將Workflow和WorkflowEntry的狀態(tài)持久化。這樣，我們就可以定制實(shí)現(xiàn)接口，將domain models轉(zhuǎn)換成 OSworkflow models，在流程流轉(zhuǎn)需要持久化流程狀態(tài)的時(shí)候，則會(huì)去持久化domain models。
經(jīng)過(guò)這樣幾個(gè)方面的論證和分析，得到的最終方案如下：
-
使用domain model，而不是工作流model
-
擴(kuò)展接口將 domain model 轉(zhuǎn)換成工作流 model
-
擴(kuò)展接口提供自定義的工作流狀態(tài)持久化
-
不改動(dòng) osworkflow 內(nèi)核
最終實(shí)現(xiàn)
圖3 系統(tǒng)實(shí)現(xiàn)圖
我們得到了什么
- 使用 domain model 進(jìn)行開(kāi)發(fā)
- 底層工作流引擎對(duì)開(kāi)發(fā)團(tuán)隊(duì)透明
-
設(shè)計(jì)、優(yōu)化工作在應(yīng)用層次來(lái)進(jìn)行
（本博未來(lái)會(huì)以同一個(gè)項(xiàng)目為例對(duì)敏捷項(xiàng)目各個(gè)階段過(guò)程進(jìn)行簡(jiǎn)單的介紹，敬請(qǐng)期待）