java开源工作流引擎

新接项目，要开发一个工作流引擎平台来实现业务协同。以前只知道一点工作流的概念，动手之前先补充下这方面的知识吧。

几个比较重要的概念：

1. 工作流(Workflow)

就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。

工作流要解决的主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档、信息或者任务。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。我们可以将整个业务过程看作是一条河，其中流过的河水就是待审核的表单。

工作流概念起源于生产组织和办公自动化领域，是针对日常工作中具有固定程序活动而提出的一个概念，目的是通过将工作分解成定义良好的任务或角色，按照一定的规则和过程来执行这些任务并对其进行监控，达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。

2. 工作流引擎

是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。

3. WFMC:http://www.wfmc.org/

成立于1993年，工作流管理联盟（Work Flow Management  Coalition ）是一个由涉及工作流和业务流程管理的推广学者（adopters）、开发工程师、顾问、分析师、大学和研究团体的全球性组织。该组织创建并完善了工作流的相关标准，开拓了相关市场，是唯一的致力于工作流标准化的专业组织。该组织推出了工作流XML（Wf-XML）和XML过程定义语言（XPDL） ，现在有超过80种有名的解决方案中使用了这两种语言来存储和交换过程模型。 

4. XPDL

XPDL（XML Process Definition Language）是由Workflow Management Coalition所提出的一个标准化规格，使用XML文件让不同的工作流程软件能够交换商业流程定义。

XPDL是一个通用的框架，这也是XPDL的一个重要特性，这个框架可以支持开发者的特殊使用目的，而对外表现形式却相同。开发者的实现和它的外部接口可以独立分开，因为不管你如何实现的，采用什么图形描述(状态图，活动图等)，只要外部接口符合XPDL 规范，那么就可以保持相同的表示形式。希望在WFMC 接口1的未来发布版本中，能够包含现版本中缺少的属性。

几个流行的JAVA开源工作流引擎：

最为流行的是JBPM和OSWorkflow，其他的如shark、JWFD、OpenWFE

1. Shark

Shark的靠山是Enhydra。Enhydra开发过j2ee应用服务器、o/r mapping工具以及工作流引擎等等。Shark的持久层采用Enhydra自己的DODS来实现。

    Shark的流程定义语言是XPDL， XPDL的两个最重要的概念是Process和Activity。XPDL中的Activity是基于UML1.x中的活动图的概念。活动图适于工作流程建模，它相对于状态图的一个最大的优点是容易做并发线程的分叉控制，这些并发线程可以同时执行也可以顺序执行；它还有一个优点是有泳道的概念，可以控制工作流引擎中的任务的产生。Shark的如来神掌是活动图。

2.JBPM

Jbpm的靠山是jboss。Jbpm3和JBPM4的持久层采用hibernate3来实现。Jbpm3的图形化流程定义通过嵌入到jboss eclipse IDE中实现图形化编辑。

Jbpm结合应用了状态图+活动图+PetriNet的知识，而且它的活动图还是UML2.0版的。UML2.0的活动图中，节点不叫活动（Activity）而叫动作(action)，活动成了一个高层次的概念，它包含一个动作序列。一个活动图展现一系列的动作，这些动作组成了活动。Jbpm把action也改名了，称为state。JBPM使用的状态图的概念有transition/event等。Jbpm来内部实现中还采用了PetriNet的概念，如token,signal等。

JBPM提供图形化绘制流程描述文件便于工单流开发并提高了用户体验;

JBPM的扩展支持做得很好便于与各种开源矿建结合,但不足之初在于持久层只能使用hibernate3及hibernate所支持的数据库.

JBPM对工作流中所需的各种应用提供很好的支持为开发应用提供方便,但JBPM的流程定义GPD插件与Eclipse支持不完善,目前jbpm4版本只支持Eclipse4.3版本,Jboss组织整合的IDE工具Red Hat Developer Studio又为收费软件.

JBPM应用前景被行业内人士很看好,被誉为顶替Shark和Osworkflow的新一代工作流引擎.

JBPM4.0版本目前还是阿尔发版,还没有发展成为稳定的发布版本,并且现在一直在不停的重构,目前还不便于极力推广应用,而JBPM4.0较之JBPM3.0又做了很大的改进和变动,转而使用JBPM3.0有点得不偿失.JBPM4.0相关技术应用和文档支持都还不够,使用该框架还有待时日,需要静观其变.

3. OSWorkflow

Osworkflow的靠山是opensymphony。该组织开发过很多,webwork2就是其中之一.

Osworkflow有个重要概念是State，它的如来神掌是FSM。Osworkflow中的State是由step和status联合表达的，一个State就是一个step中的某个status；而state的转换由action来驱动，类似状态图中的event,因为一个event对应一个action。

Osworkflow应用相当灵活,被誉为最灵活的工作流引擎, 几年前osworkflow为国内的工作流引擎使用率最高的工作流引擎,它可以灵活的将流程和流程控制逻辑结合起来.

Osworkflow不支持较好的图形化流程定义模式,流程定义文件必须由专业的技术开发人员开发和维护,但是在项目开发过程中可以极大的提高开发效率.在各种轻量级应用中可以灵活应用该套工作流框架.

简单总结来说：Shark的优势时使用了WFMC定义的工作流标准XPDL，为不同工作流引擎间的交互提供了可能性；Osworkflow的优点的灵活，但是前期要做很多设计工作，跟Spring等web框架结合的也比较好；而JBPM的优势是功能全，其目前的开发环境也比较活跃，但是有一定的复杂性。