轉自：http://www.guodanpi.com/zblog/post/21.html
今天幾乎沒有再看關于工作流的一大堆規(guī)范，而是看了一下國人的PowerStone開源工作流實現(xiàn)（其實之前幾天也花了些時間來研究），畢竟對他用的那個套路比較熟（spring+hibernate），大體上能了解他想干什么，但是還是不懂，第一步還是分析了他所使用的數(shù)據(jù)庫，遺憾的是終究還是沒有找到我想看到的東西。同時他的說明里面提到實現(xiàn)了WfMC的1、2、5接口，由于對WfMC沒什么興趣，所以也就不管它，只是想弄清楚他考慮的和我所想的有什么差距。
事實上是我以前接觸過一個Fatwire公司（在google里面搜索contentserver，它排第一，以前可真是名不見經(jīng)傳）的contentserver，我還是比較贊同它里面的搞法，通過web頁面+dbms來定做工作流，并自動生成工作流的最終圖形給用戶驗證是否正確，而不是輸入一個xpdl這種東西。
多少給我的收獲在于它對工作流和實際操作的數(shù)據(jù)的結合部分，也是我以前從來沒有想到過的結合方式，通過記錄每一個state的輸出和輸入?yún)?shù)來與數(shù)據(jù)交互！好像這也是wfmc的一個通用數(shù)據(jù)庫設計。不敢說他設計的不好，只是總覺得這樣設計有點別扭。
還是先看一下真實使用工作流時，業(yè)務數(shù)據(jù)在“流動”的過程中可能碰到的操作結果：
通過、退回、取消、取回
這些也就是概念上的東西，對應到真實世界操作簡直太容易了。
如果說if..else..、for..和順序執(zhí)行能構成完整的程序的話，工作流應該也不例外，關鍵或者說難點在于將一些條件、一些業(yè)務數(shù)據(jù)如何與工作流互交，或者說如何讓工作流能夠識別前面提到的fromCondition和toCondition，這一點的設計估計要留到最后了。
不管工作流將要處理的對象有多復雜，有多少屬性，應該有一個表用來記錄唯一的標示這些對象的表(暫且稱之為實體，也正是因為想在PowerStone中找到這個表未果，所以充滿疑惑)：
class WorkflowEntity {
Long id;
String targetId;//或者直接是某張表的id
String targetType;//或者直接是某張表的表名
Workflow workflow;
}
只要拿到entity的id，自然可以得到它所對應的操作對象(table+id完全可以定義到某一條數(shù)據(jù))，也能知道當前所使用的工作流。這一點有需要考慮的地方，是否需要（targetId+ targetType）的唯一索引，這樣才能比較好的處理。
也需要記錄該實體的當前狀態(tài)信息
class Task{
Long id;
State currentState;
WorkflowEntity wfEntity;
}
明顯我們可以看到現(xiàn)在為止所設計的表中都沒有“人”這個東西的出現(xiàn)，想想我們幾乎每一步都離不開人，自然需要修改上面的State，加入人的信息，這一點確實很矛盾，因為“人”有多種的表現(xiàn)形式，有“組織”、“團隊”、“角色”，這些全部可以包含人的信息，那么具體應該采用哪一種比較合適？（還沒想好），姑且先放進去再說。
那現(xiàn)在實際上已經(jīng)可以把這個實體“流動”起來了，但是太粗糙了！沒有細致的沒一步的規(guī)則定義，也許fromCondition和toCondition應該是一個規(guī)則(Rule)，那么定義如下：
class Rule{
Long id;
//其他未知
}
class State{
Long id;
Workflow workflow;
Rule fromRule;
Rule toRule;
String actor;
}
實在有很多東西沒有想明白，先記錄下這些現(xiàn)在的糊涂想法，再慢慢改進，估計要真正想明白了再接著寫了。