轉自：http://www.guodanpi.com/zblog/post/23.html
繼續工作流的學習和開發工作。
繼續研究Powerstone，繼續思考，繼續做一些自己的數據庫設計。越深入一點Powerstone的設計，越覺得他確實設計得非常不錯，考慮到了很多東西，也實現得不錯，今天再度請教了作者daquan關于節點中為什么要bind數據的問題，答案讓我一下茅塞頓開，非常感謝！但是個人還是覺得是否有必要，所以當前的設計暫時沒有加入這方面的考慮。
初步的設計可以看這里(pdm文檔沒法下載，呵呵，jpg查看)。圖片如下所示：
大致的定義流程如下：
1． 首先定義工作流（只是名稱、是否發布等簡單屬性，主要是獲取一個id）
2． 設置該工作流存在的狀態
1) （設定參與者，這里打算直接通過Group:32;Role:98等這種方式處理，詳細的處理將交給用戶角色模塊，可返回參與者的user集合）
2) 設定前驅進入規則：主要是通過定義的“工作流規則”，將“聚合、順序、and、xor、or、投票”等一系列的規則放入工作流規則中統一處理（處理工作流規則將是一項艱巨的工作，所以感覺表[工作流規則]的設計還需要考慮。
3) 是結束狀態：個人覺得結束狀態是比較特殊的狀態，應該不需要每個工作流都需要定義，可以公用，但是暫時還是每個工作流都定義這樣的狀態好處理（還沒想到更好的辦法）
4) 是否開始狀態：開始狀態同樣很特殊，實際上在將事件放入到工作流時就已經開始，這時候主要需要的可能就是能夠使該事件進入工作流的參與者的定義。
3． 設定個狀態間的路由：也就是各狀態間的連線
1) 指定[從狀態]和[到狀態]，
2) 指定[從狀態]到[到狀態]的使用規則：比如說明在一個從狀態存在多個后續狀態時，是否選擇該路由的規則。
3) 定義業務是否可主動選擇參與者的具體用戶：由于參與者存在多個用戶的情況，所以存在兩種需要考慮的狀況a.參與者中某個具體的[人]主動請求任務，b.在定義業務可主動選擇參與者的情況下，可以讓業務指定參與者中的具體的[人]。
感覺工作流引擎純粹的定義好像就是這么簡單（當然現在我仍然在是否需要在狀態中綁定數據上猶豫，雖然在狀態中綁定數據是wfmc已經說明了的），但是我現在的考慮在下面將會提到。
對應與純粹的工作流定義，需要“事件”的參與，這里面定義為“工作流實體”
4． 設定工作流實體：指定實體id，實體類別，選取的工作流，當前在工作流中的狀態信息
5． [實體在工作流中狀態]將由工作流引擎驅動并生成數據
6． 用戶驅動生成[用戶參與記錄]，或由業務驅動主動生成[用戶參與記錄]
到現在為止，關于數據和工作流的關聯關系已經建立，業務端可以完全可以通過上面的工作流引擎提供的接口來對“實體”進行操作，但是我覺得powerstone中采用url來驅動的設計非常好，引用之，呵呵
7． 定義外部業務web應用
8． 定義web具體的url
9． 定義url與工作流每一步狀態的關系，從而可以從當前狀態獲取需要交互的url信息。
大致上的數據庫如此，需要繼續研究和討論，做個記號先！
