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

多谢鼓励，这个开源产品一定会继续下去的。目前正在写最后一篇文档《6_工作流引擎的结构及其扩展》，写完之后，会修正目前的发现的一些bug，发布一个稳定版本。

我向来认为好的系统首先不在于其功能有多么完备，而是设计要好，能够真正做到“可扩展性”、“可移植性”。这个要求在我们写投标文件和需求说明书的时候写了n遍，遗憾的是很多时候我们理解并不深刻。




变量表T_FF_RT_ProcessInst_Var用于保存流程变量，流程变量在Fire Workflow中有两个作用：1、用于计算流转条件，2、用于填充“扩展任务实例表（如 Example中的T_Biz_MyTaskInstance）”。

不是很理解你说的“直接WEBSERVICE提供接口”是指哪个API以Webservice方式提供，是所有的Fire Workflow API吗？
Fire Workflow API是包org.fireflow.engine下面的几个接口（ITaskInstance，ITaskInstance，IWorkItem等）

看了你的部分文档，暂时提两点意见：
1. 规范还是很重要滴，虽然从最新的xpdl2.1看来，它为了兼容老规范和适应bpmn，复杂得一塌糊涂，但是规范就是大厂商设的门槛，用户评价产品标准性和开放性的依据，因此，我建议流程定义还是可以采用xpdl，可以根据目前支持的元素做适当裁剪，后面根据需求慢慢补充。
2. 看了你的业务数据与工作流数据的那一章，我觉得还有一种方式，我的想法是业务数据是业务数据，过程数据是过程数据，两者是独立的，当两者有关联的情况通过关联来搞定，比如讲业务对象的某个属性绑定到一个流程变量，这样就既能保证它们的独立性，又能保证流程变量值跟业务变量值的同步，流程能够正常运转。

不知道楼主大侠看过BPMN规范没有，最新我大略看了一下。
BPMN中将流程分为三类，一类是Global Process，一类是Private Process，最后一类是Abstract Process。
其中Abstract Process是Private Process的一种声明，类似java类跟java接口的关系。还是属于Private Process的范畴，而规范中说BPEL是Privatge Process的一种实现，BPMN建立了到BPEL的转换映射，但是BPEL有局限性，只能用于编排webservice，个人觉得对开发者，和对性能都不好。因此，我觉得现在的BPEL如果不继续演进，那么适用场景非常有限。但是我估计它是会继续演进的。那么演进的方向是什么呢？我估计会在这两个层面：
1. 服务泛化，就像SCA一样，支持将各种实现技术实现的服务接入，并暴露为各种形式的服务
2. 人工参与能力增强。
这里我为什么要提bpel这个东西呢，这是基于目前这样一个现实，工作流领域目前是由IT大厂商在主导。如ibm和oracle之流。它们最善于定标准，设门槛。我们要跟他们一起竞争，就一定要跨越这些门槛，这些门槛就是规范。（当然还有其他的，担不是最迫切的）。

我非常佩服楼主的技术，GUI、server端编程样样都行。我是不行了，呵呵。这里我希望楼主能考虑一下支持业界的标准，流程建模bpmn，流程定义采用xpdl，流程执行采用bpel（可做增强，看看可否参考一下我的建议）如果后续你的开源项目做起来了，支持各种标准绝对是你的项目的一大核心亮点。

我的意思就是engine核心流程引擎,可以做为一个独立应用启动,webservice的方式向外界提供接口,来处理流程,不要
业务和流程耦合在同一项目中,当然里面有很多技术难点,如事务的统一,流程的流转处理,这些难点就是需要去思考的了,个人的观点!

http://gocom.primeton.com/modules/newbb/item53655_53655.htm

众多workflow感兴趣者看看这篇文章

看来大家还是很有热情的。那我就把自己做的工作流跟大家分享一下吧。
不过由于不是开源的，所以没有什么说明文档，只有数据库表设计和源码。但源代码注释很详细，对于想学jbpm的人而言，可能会很有用。
在实际应用中，这个工作流引擎配有一个web流程定制系统，纯js开发的，有图为证，

但代码不包含在这个项目中。这个系统是作为我们公司内部系统开发的，是有商业版权的 ，仅供大家参考学习。

严重坚持楼主！！！

太好了,正在学习工作流,先看看你的

我从来不认为工作流可以自定义.

这句写的实在太好了....就是有部分傻啦吧唧的用户,老提出要自定义工作流,然后又搞半天不知道怎么用...唉~~~~~~~~~~~