py工作流是國(guó)內(nèi)比較好的工作流之一。大概看過它的一些文檔，分析一下。
1、路由模型
 py支持的工作流模式其實(shí)并不多，只是支持1到7七種模式而已，其中比較重要的是模式6和模式7，即M選N分支和M選N聚合，看過它的實(shí)現(xiàn)，利用轉(zhuǎn)移線條件來觸發(fā)轉(zhuǎn)移線，從而觸發(fā)后續(xù)的節(jié)點(diǎn)。這樣做比較簡(jiǎn)單，但是同時(shí)也存在很多問題，例如在路由非常復(fù)雜的情況下，例如多個(gè)分支節(jié)點(diǎn)的串聯(lián)，以及并發(fā)路由存在多個(gè)節(jié)點(diǎn)時(shí)，這種做法實(shí)現(xiàn)起來就非常困難。另外，并發(fā)路由的工作流變量會(huì)存在相互沖突的情況，也包括業(yè)務(wù)數(shù)據(jù)的沖突。可以說py的路由模型還是很簡(jiǎn)單的，支持簡(jiǎn)單的業(yè)務(wù)可能沒有問題，對(duì)于復(fù)雜的業(yè)務(wù)可能需要很多其他額外的辦法。當(dāng)然，很多國(guó)內(nèi)的工作流甚至連模式6和模式7都支持不了，同時(shí)工作流的應(yīng)用目前還具有很濃的“審批”的影子（貌似有人很討厭審批這個(gè)說法），所以目前的路由模型應(yīng)該滿足需求了。
2、任意路由和回退
 沒有看到任意路由和回退的復(fù)雜示例。關(guān)于任意路由，產(chǎn)品說明中說到可以在整個(gè)流程范圍內(nèi)任意自由路由，我覺得這個(gè)說法本來就是有問題的，并發(fā)路由的情況下，并發(fā)支線往主線上跳轉(zhuǎn)，這種情況會(huì)有很多問題存在，其他并行的支線如何處理？或者說根本就沒有考慮到這些復(fù)雜的情況？回退也是一樣的道理，至于業(yè)務(wù)補(bǔ)償?shù)奶岢鲞€是不錯(cuò)的，不過推給了用戶自己設(shè)置回退動(dòng)作。
3、關(guān)于WFMC和BPEL規(guī)范
 看看流程定義文件就知道了，它不支持任何規(guī)范。敢說國(guó)內(nèi)工作流的流程定義就沒有遵循規(guī)范的。
4、參與者的指定
 提供了組織機(jī)構(gòu)、角色、個(gè)人這三種常見的參與者設(shè)置模式，還提供了流程啟動(dòng)者、活動(dòng)執(zhí)行者、從相關(guān)數(shù)據(jù)或從規(guī)則邏輯中獲取參與者的模式。
5、工作的代理和代辦
6、時(shí)間服務(wù)
 提供了四種時(shí)限。活動(dòng)提醒、活動(dòng)執(zhí)行、流程提醒、流程執(zhí)行。
7、業(yè)務(wù)開發(fā)
 感覺這是非常出彩的地方，在一個(gè)簡(jiǎn)單的示例中幾乎不需要任何編碼，比如一個(gè)簡(jiǎn)單的請(qǐng)假管理。看看它的流程定義文件，它幾乎將整個(gè)業(yè)務(wù)表單都嵌入到流程定義里去了。這樣做是否合適？我個(gè)人傾向于引擎與業(yè)務(wù)完全分開，通過反射或者某種映射將兩者關(guān)聯(lián)到一起。如果是用戶自己開發(fā)已有的復(fù)雜業(yè)務(wù)，如何將工作流嵌入？至于studio也是非常出色的，具有開發(fā)調(diào)試的功能。調(diào)用接口非常的清晰。
總結(jié)一下：py工作流還是一個(gè)不錯(cuò)的工作流引擎，拋開它的宣傳，感覺引擎的實(shí)現(xiàn)還是有些簡(jiǎn)單，或者說只是滿足了目前的一些常見需求，至于所說的SOA和服務(wù)編排，我覺得目前還不現(xiàn)實(shí)。它的優(yōu)勢(shì)在于與其平臺(tái)的完全融合，能夠利用很多既有設(shè)施，可是這又何嘗不是把雙刃劍？另外，強(qiáng)大的市場(chǎng)宣傳和良好的服務(wù)團(tuán)隊(duì)也是選擇工作流時(shí)的重要考慮。

http://m.tkk7.com/ronghao 榮浩原創(chuàng)，轉(zhuǎn)載請(qǐng)注明出處：）