转自：
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的学习，不过个人觉得收获还是挺大，马上我就可以自己设计出工作流咯，哈哈。