国内开源工作流 Fire Workflow 出炉了

在我的blog中已经有了初稿，关于工作流的性能问题还没有写完，其他的都写了。欢迎交流。下面是关于流程数据保存于事务一致性的设计方案。

3、流程数据存取设计与事务一致性

    Fire Workflow的流程数据的存取都是通过org.fireflow.engine.persistence. IPersistenceSerivce的实现类完成的，假设这个实现类的名字是MyPersistenceService。那么MyPersistenceService其实就是一个存取多张工作流表的DAO而已，和你的业务系统的DAO处于相同的地位，没有任何区别。示意图如下。

    如果你的系统采用的是申明式事务，将事务申明添加到MyPersistanceService上即可以实现业务操作和流程操作在同一个事务中。
    如果你的系统采用的是编码实现的事务，只要将调用流程引擎的代码和和业务逻辑代码放在同一个事务中即可。在Fire Workflow Example中，采用的是编码实现的事务，可以参考。
    Fire Workflow已经提供了org.fireflow.engine.persistence. IPersistenceSerivce一个缺省实现类org.fireflow.engine.persistence. hibernate.PersistenceServiceHibernateImpl，该类基于hibernate的，你当然也可以自行编写基于iBATIS，Toplink，甚至JDBC的实现类。

是环节和任务的名字出现乱码吗？

这是20090202版本的设计器的bug，输出文件的编码格式有点问题。你创建一个新的流程看看有无乱码。

或者贴图上来看看。

呵呵 谢谢楼主了 正好我还没用过工作流呢

从你的描述看，flow与application采用了嵌入式方式进行整合。
我有个问题，如果flow支持独立部署，application和flow的事务怎样来保证，你是怎么考虑的？

你是基于何种考虑要把Workflow 独立部署呢？在我看来目前暂时不存在Workflow独立部署的业务场景。

对于一个把应用进行了集群配置的业务系统，使用了一个需要许可的Workflow产品，如果Workflow与app全部嵌入整合，那么需要购买多个Workflow许可，而使用独立部署的Workflow，则购买一份许可就可以了。
当然，这个是个采用Workflow产品产生的问题，我看到你的帖子后联想到的。

有赖大家支持啊，哈哈。

Fire workflow站在JBPM的肩膀上，某些地方借鉴了。但是和JBPM实现方法的区别还是很大。相较于jbpm应该更简洁，性能更好些。Engine算法应该更加严谨。

对应工作流最近1年有一个心酸的体验，工作流往往会成为系统中最不稳定的一个环节。
希望楼主解决好以下几个方面。

• 持久层至少要支持spring jdbc,hibernate两种方式。
• 和业务代码必须保证在同一个事务里面，否则后果很严重。最好能够自动加入jdbc，hibernate两种事务管理器的事务范围
• 设计通用工作流节点的人员过滤接口
• 工作流表结构不要太复杂
• 定义好的URL形式与业务表单关联上

到http://code.google.com/p/fireflow下在文档吧，文档里回答了你所有的问题。

说的太好了，强烈赞同，没有团队就没有企业敢用，没人用就没有继续的动力，最后就不了了之了