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