对工作流系统的思考

说起工作流，本人一般遇到两种场景：一种是某些人对工作流的向往之情非常强烈，他们的说法一般是“这个问题就应该用工作流来解决”，而他们却未必对工作流有详细的了解，只是对这种技术有道听途说式的理解；另一种是对工作流的强烈反对，认为工作流根本就不好用，即使用了也是“假”的，业务系统该怎么样还是怎么样，用了工作流也就是对客户宣传的噱头而已。

本人先后试用了3种java开源的工作流产品，无一例外都要在业务系统中加入一些工作流的代码，这就造成工作流产品与业务系统的紧密耦合。在松耦合是开发系统目标之一的情况下，工作流产品与业务系统的紧密耦合显得有点背道而驰。而发生这种问题的原因是工作流引擎与业务系统确实存在通信的必要，例如报销数量超过5000元的报销单需要老板审批，工作流引擎如果无法从业务系统得到报销金额能正常工作吗？再比如客户下了一个订单，订单以工作流的形式在各个部门中执行，客户在查询订单状态的时候需要从工作流引擎中获得最新的状态。而工作流产品与业务系统的这些交互，很多是需要通过代码来实现的，在业务系统中写一些无关的工作流代码，感觉确实不是太好。

工作流已经存在了很长时间了，最早的使用甚至可以追溯到上个世纪60年代，经过这么多年的发展，出现了很多工作流产品，这几年随着SOA架构的应用，又出现了工作流（Workflow）的升级版本业务流程管理（BPM，Business Process Management）。一种技术发展了30年了，也应该非常成熟了，可是实际应用中还是不甚理想，甚至还有很多业务系统没有使用工作流产品，出现这样的情况我们不能不对工作流系统进行反思。总体来说，工作流系统存在以下问题：

• 工作流产品与业务系统的紧密耦合。
• 数据量大时工作流引擎可能会出现的性能问题。
• 工作流产品适应不同业务环境以及随业务环境变换进行微调的能力不足。

当然以上也只是一个大致的总结，不同的工作流产品有不同的特点，例如对于实现会签这样的流程，有的工作流很容易做，有的则要费劲一些。

也许我们应该换个角度看问题，而不是要求工作流产品尽善尽美。我们提供的最终系统是以业务系统的形式出现的，而不是工作流如何，充分利用他们的优点，使用户在使用业务系统的时候更加方便才是最终的目标。对于界面展现，我们可以用业务系统来实现，而不是工作流提供的界面；对于任务的流转、分配，可以充分利用工作流的特性；对于业务系统与工作流的信息交互，完全可以看成是一个统一的系统，而不用划分彼此。

只要实现了多人协作完成同一个任务的系统都可以叫做工作流应用系统，而不是非要使用工作流产品。尽管WfMC制定了工作流的相关规范，只有遵从规范的才叫做工作流吗？没有遵从规范的也存在不少优秀的工作流产品。

没有采用工作流的业务系统未必不优秀，而使用了工作流的系统也可能很烂，评判标准掌握在用户手里，由市场来决定，而不是所采用的技术。