思考：开源工作流在应用程序中的位置--80%

我工作以来所经历的项目是依次如下

一、基本没有工作流概念，建一个流程表，一张大横表，每一个环节是一个字段，用一些标识代表状态，如0未完成、1已完成、x异常、c撤单...，程序员自己编码维护，而且绝大多数的情况都是业务逻辑、流程控制、数据库读写混在一起 。这主要适合流程单一、改动不大、用户数较少的系统，但是也带来了很多开发、测试、维护的问题。而且随着程序的逐渐庞大，这些问题也会愈演愈烈，最终的解决就是推倒重来，上2版。

二、后来的项目有一些改进，虽然同样没有采用工作流，但是对整个应用程序进行了合理的分层，如下：

view(视图层。仅仅与用户进行交互：接受用户输入请求、信息展现)

control(控制层。调用业务层方法、流程控制)

model1（模型层-业务逻辑层。所有的商务逻辑在此处实现。）

model2（模型层-持久化层。仅仅负责数据的持久化，就是将暂态的数据保存成定态的）

这就是经典的MVC模式，下层独立于上层，这样的好处是类似于模块化各个功能，便于拆卸。比如，模型层分为2层，这样我们可以在保持业务逻辑层代码不需要改变的情况下轻松的实现下层的切换，比如原来我们是持久化到mysql进行前期开发的，现在上线了要切换到oracle。甚至是我们不采用数据库了，采用xml来存储数据。

回到我们工作流的主题，MVC的工作流处理一般在"C"，如用struts的action来实现，调用"M"将流程信息保存到自己建的数据表中，对于流程复杂多变的项目，这个自行设计的工作流是很有难度的。稍有不慎或者设计师偷点懒就会变成文章开头所说的混乱局面。为了避免这种情况有一种实用方法是，将C和M分得再开一点，在它们中间引入了业务代理接口层，C不直接调用M中的类，而是调用这个代理接口，代理接口定义了所有的业务处理方法，仅仅是定义，实现全部在M层实现。

同时还有另一个好处，我们可以在保持业务逻辑层不变的情况下随意的开发上面的client端，既可以是B/S也可以是C/S；或者在保证前端客户程序不变的情况下随意的更改后台实现，ejb/ormapping/jdbc+javabean。

上面的系统仅仅是将应用的各层进行了合理的划分，变相缓解了工作流编码的压力，但是我们还是要自行维护工作流数据与业务数据的关系，还是将工作流和业务关联的非常紧，甚至将工作流数据看作是业务数据的一部分。如何才能有效地将工作流数据和业务数据进行解耦呢？这才是我们问题的核心。

 三、前段时间看了开源工作流jbpm，它为我们做了很多事：

• 设计好的工作流定义规范——我们只需要定义一个xml，里面包含相应的元素（如：分支节点、汇聚节点、判断节点、任务节点）就可以表示一个流程，甚至有一个ide工具，我们可以通过拖拉完成流程框架的定义。
• 设计好的工作流持久化方案——我们只需要运行一个命令就可以在指定的数据库（包括oracle/mysql/mssqlserver/sybase等10余种数据库）中生成工作流表（大概25张表，你自己设计的工作流肯定没有那么全面）。编程的时候，我们不需要知道这些表，因为jbpm已将这些表映射成了对象，我们只需要操作java对象，所以这些表我们不需要修改。
• 还有一些好的功能，比如：任务定时器，到指定时间任务自动执行；在一个xml中指明日历中那些是工作日期、哪些是工作时间；结合JMS实现异步工作流；结合Jboss rules实现规则引擎...

虽然他解决了很大一部分工作，但是我们还是要面对了很多挑战：

•  如何应用到我们现有的应用层次中，保证各层之间低耦合。
• 如何和我们现在的组织模型结合，完成任务的分派便捷性。
• ...还有的要去实践中挖掘了。

 这里有我的一些想法，还不是很成熟：

jbpm是默认采用hibernate做持久化的，可以将jbpm的流程