轉自：
http://www.guodanpi.com/zblog/post/24.html
今天比較高興，上班一個小時就覺得終于把powerstone給研究清楚了，覺得可以開始依據這個版本有些自己的想法和修改，還是先總結一下powerstone的優缺點：
1. 優點：確實很好的解決了業務和工作流之間的數據傳遞。通過每個步驟的輸入和輸出參數定義，并通過保存每一步的輸出參數（直接保存到數據庫），來進行業務和工作流引擎的解耦，做到了“業務渾然不覺”在工作流中的這一點。
缺點：實際上業務部分的很多數據仍然依賴于工作流引擎的傳入，比如他的例子中的輸出參數“_orderID”幾乎是貫穿于整個業務的，而獲取這個值方法是通過工作流引擎得到（private方法）的Map中獲得，可以說這部分仍然使得業務不得不考慮工作流引擎的存在。
2. 優點：提供了Spring MVC的基類，使用起來應該還是很方便的。業務方面基本上不用考慮工作流的存在，只需要關注業務的實現即可。
缺點：和作者討論過，他覺得使用MVC的方式不是一種對業務的侵入。我覺得侵入性還是比較大的。比如我這種用webwork的人對spring的mvc屬于白癡級，為了和現有系統交互，將會使用webwork框架開發工作流，就不能直接對powerstone實行“拿來主義”了，我倒更傾向于引擎提供接口出來，而不是強行的繼承Spring mvc被加工后的一個基類。
3. 優點：使用url作為工作流與業務之間的交互數據接口，使用cookie作為部分數據的傳遞，使得工作流引擎和業務系統可以獨立發布。
缺點：使用url作為數據交換唯一接口的方式決定了引擎的工作范圍是基于http的b/s方式，如果想在一個app引用中驅動引擎將不可能，使用cookie是的數據的傳遞依賴于客戶端瀏覽器的設定，不利于工作流引擎的利用。就我目前的了解而言，cookie的讀取范圍是在同一個domain之類，也就是說雖然業務可以和引擎獨立發布，但是必須發布在同一domain的玉米（玉米：剛學的一個流行詞匯，哈哈）之下。
4. 優點：powertone對部分數據的需求采取直接讀取源xpdl，這使得powerstone的實現是非常規范的，也是完全基于xpdl文檔開發的，有很好的通用型（基本上可以實現對xpdl的通吃）。
缺點：感覺沒有將xpdl的信息完全轉化為dbms存儲，使得一些關鍵信息仍然要使用xpdl的xml數據作為依據，來爬xmldom這顆樹。當然，作者好像做了緩存，速度方面暫且不說，對于這種做法個人不是很贊同，應該完全有可能將xpdl的信息轉化到數據庫中。
5. 優點：完全依照xpdl的“join”和“split”等規則處理合、分。基本上覆蓋了xpdl中定義的condition，采用每一步的輸出數據作為數據依據來進行condition的判斷。
缺點：感覺作者對condition等方法的處理不夠，很簡單的String比對和直接轉化為Integer等方法覺得遠遠不夠，個人打算引入ognl等表達式的處理，直接使用這些成熟的工具來作為condition等判斷語句的處理（當然現在也在考慮使用規則引擎drools來處理，但是覺得有點用牛刀之嫌），并將這塊獨立。
6. powertone的數據庫感覺非常臃腫，按照作者的思路確實走通了整個工作流，但是應該有更簡潔的數據庫設計，這一點也正是我最想改變的地方。
7. powerstone中完全采用引擎驅動業務的方式，沒有業務主動請求工作流的地方，作者介紹這是要嚴格分離兩邊的數據，解耦處理的。但是個人覺得應該給業務留有主動要求加入工作流和獲取業務當前自身在工作流中所處狀態的能力，但是powerstone沒有這一點，不知道算設計上的優點還是缺點。
其他的有點太多啦，由于沒有自己的想法就不說啦。
總得來說powerstone可以說是一個完全按照wfmc的規范實現的“乖孩子”，處理的很不錯，但是直接拿來用，還覺得需要自己加工，增加或減少點什么。
btw：逐漸從工作流的學習轉化為了powerstone的學習，不過個人覺得收獲還是挺大，馬上我就可以自己設計出工作流咯，哈哈。