土著的工作流学

工作流的书现在不少了，规范也不少了，开源项目更不少了，学起来要好久了。但是到底一个工作流系统要有什么用呢？记得看过一篇文章，还列了100多点功能，看着头大。能不能简单的说明，工作流是做什么的？用了一个工作流后，一个系统应该有什么样的效果呢？

在我这个土包子看来，一个好的工作流有这三个功能：

第一个最大的功能是流程控制。简单的说，就是消灭if-else和switch-case语句。一个使用工作流的系统，在页面和业务类都不应该有太多的if-else和switch-case。这两者都是控制业务流程流转的，而这项工作，是工作流的天职。所以如果系统用了工作流，还是有大量的这种语句，那么这个系统就是失败而毫无意义的。其实二和三都是这个功能的子功能。

第二个功能是状态控制，简单的说，就是消灭对业务表的getStatus和setStatus，无论pestiNet比FSM的理论先进多少，状态控制始终也是工作流最大好处之一。伴随着流程的流转，在某个点状态都是定好了，我们无须操心，直接打印出来就OK了，这个是对于有一个主业务数据，并关心其状态的业务模型，这个是重中之重。就好像无论你吹嘘社会主义比资本主义先进多少倍，保证人民的温饱才是最重要的。如果我用了工作流，还整天要去关心和update一个唯一主业务表的状态，那无疑是悲哀的。当然，多业务数据状态是另外一回事。

第三个功能是角色控制。简单的说，就是消灭if (user == ***) || (roles == ***))这种语句。角色或者用户所能获得的任务，所能进行的操作，都是在工作流引擎里面返回出来的时候，都已经做了过滤判断了，上层代码，无须关心。

为了有效的完成这三个功能，一个工作流引擎，无论基于那种理论进行内部流转，都还应该提供足够的支持，能够灵活的插入业务判断和执行点，根据业务，进行原子业务逻辑判断和操作，角色处理。

这三个功能的实现，是一个工作流系统成功应用的标准，如果一个工作流引擎，不能满足这样的需求，那么无论它的核心理论是多么先进的，那么它也始终是学院派的一个玩具而已，而不是一个对于企业应用系统真正有用的产品。

楼上说的很对，道出了工作流设计的要点。
另外我觉得还应该考虑：
流转与具体功能的分离；
功能的重用机制等。

呵呵，我觉得这里是工作流和业务流的结合问题

一是用工作流驱动业务流，二就是业务功能类的重用

这方面除了工作流引擎支持，还需要公司在业务方面的归纳，整合。

对于完整的工作流产品，支持二次开发的能力，实际上是必不可少的。

不错
这里说的流转是指流程的退回、取回、终止、结束等。就说退回吧，工作流系统应该怎么来设计呢？退回有些可以直接退回，有些可能要做一些处理后才能退回。

那满足楼主提出几点的开源工作流引擎有哪些呢？

工作流这个概念太宽泛，似乎任何与流程控制相关的东西，都可以塞到这个概念里。

我倒是觉得，楼主提出的第二点，才是核心：状态保持。

顺便帮我推荐几本书呀

http://www.wf800.com/
上面有些关于工作流的资料

取回不明，愿闻其详
终止和结束有何区别？

退回在我看来，不过对某个结点显式是多一个流回原来结点的指向，并非每个结点都需要有这个功能，退回的时候，此结点已非彼结点。

osworkflow基本符合，除了不符合规范，还有需要相当的二次开发。核心思想基于状态机，其状态保持能力是不错的。其实，很多中小型系统，用工作流的目的，不过如此而已。

工作流的概念是很广泛，需要根据具体业务分析，那些是归工作流控制，那些是归业务控制，并非一股脑的放入工作流中，那样的话，恐怕没有什么引擎是胜任的。

1. “取回”大概是指，当A处理完工作后发给B，在B还未处理的情况下，A可以把工作要回来重新处理。
2. “终止”大概是指，本来A处理完后要给B的，现在A不想让流程往下走了（也可以叫Stop）。“结束”大概是指流程按预先的定义正常结束（也可以叫Finish）。
3. “退回”的模式有多种，退回有可能会造成前面工作的重做。例如当A处理完工作后发给B，现在B退回给A重做。有时候A这个工作不能重复做，必须在退回之前先把第一次A做的工作注销掉，那么这个注销的功能又该在哪里实现呢？