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

http://www.tkk7.com/ronghao 榮浩原創(chuàng)，轉載請注明出處：）