关于工作流的几个名词解释：

任务

泛指各种事务上所必需执行的流程性工作

循序或平行工作

工作的流动性是一个人接着一个人执行，或同时由多个人分开执行，或是上述两类工作合并之后的混合型工作

多人

若是单人就可以完成的工作，则不能归类为流程工作；凡是一件工作必须由两个人或更多人来协力完成的工作才能称之为流程工作；

共同目的

多人参与的流程性工作，必须是以完成共同目的为前提；如果一群人是分别针对不同的专案来执行个别的工作，并不算构成一个工作流程；

引用链接

Shark(EnhydraShark)

Osworkflow opensymphony

JBPM(JBoss JBPM)

Java Business Process Management

工作流描述语言

XPDL：WFMC制定的描述业务流程控制流的XML格式规范，格式复杂，与具体语言无关，不灵活

1、XML：流程定义格式简单，使用灵活

2、基于有限状态机模型

1、JPdl：JBoss jBPM Processdefinition language，一个商务流程被看作是一个UML状态图。

2、基于UML的状态图和活动图来定义流程，已加入JBOSS大家庭，市场前景看好。

是否开源，开源协议

一个可扩展的工作流引擎框架。现在不再开源，用于商业用途

开源的嵌入式工作流引擎 ，它的使用遵循 Apache License

一种基于J2EE的轻量级工作流管理系统，它的使用遵循 Apache License

相关开源项目

Jawe

Osworkflow for .net

支持是否全面

流程定制工具JAWE

1、带有一个简陋的流程定制工具，但十分简陋且常有错误 

2、需要专业技术用户使用

1、Jbpm3的图形化流程定义嵌入到jbosseclipse IDE

2、流程定制方式更接近用户的理解

拓展性

体系和功能最为复杂，秉承“模块化”的思想，比较容易扩展

有良好的扩展性，绝对的灵活（同时也增加了开发者的工作量，需要自己写一些必要的函数）

最适宜扩展（Jbpm的过程模式支持是比较固定的，但是其对任务的中action扩展是很的灵活）最适宜被商业化应用

持久化

Shark的持久层采用DODS来实现

1、它提供的持久化API：EJB,Hibernate,JDBC等 

2、Osworkflow 可以与Spring集成。

利用hibernate持久化

小结

      Shark是体系和功能最为复杂的代表。它是一款遵循WfMC的XPDL标准开源工作流引擎，并且同时遵循OMG组织的WorkflowManagement Facility规范。XPDL的两个最重要的概念是Process和Activity。XPDL中的Activity是基于UML1.x中的活动图的概念。活动图天生的适于工作流程建模，它相对于状态图的一个最大的优点是容易做并发线程的分叉控制，这些并发线程可以同时执行也可以顺序执行；它还有一个优点是有泳道的概念，可以控制工作流引擎中的任务的产生。

    在所有开源工作流引擎中，Shark的体系最为完备和复杂。其一直秉承着“模块化”的思想，所以比较容易扩展。但是自从被Together公司收购后，Shark的商业化色彩已经越来越浓，改称为Together Workflow Server，并仅以Community Edition的形式提供了部分开源代码供参考。

     OSWorkflow是最轻量型的代表，也是一款非常灵活和低级别定位的工作流引擎的实现框架。低级别定位的意思是说，它不是定位在解决流程模型对象和运转场景，而是提供一套可维护调度的机制，供开发人员自主扩展。这个维护流程调度机制OSWorkflow选择的是基于行为（Action）的FSM理论，所以OSWorkflow更像是一个复杂而灵活的有限状态调度机。

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

    OSWorkflow在国内项目应用得较多，很多国内的简易审批流程项目都是基于其引擎二次开发而来。这主要是由于OSWorkflow是基于Action驱动的，而国内的客户也很容易接受这样的操作习惯。但OSWorkflow所依赖的FSM模型对于分支、聚合、子流程的支持度很低，这一点在实施过程中需要注意。

     Jbpm结合应用了状态图+活动图+PetriNet的知识，而且这里的活动图还是UML2.0版的。UML2.0的活动图中，节点不叫活动（Activity）而叫动作(action)，活动成了一个高层次的概念，它包含一个动作序列。一个活动图展现一系列的动作，这些动作组成了活动。Jbpm把action也改名了，称为state。Jbpm使用的状态图的概念有transition/event等。Jbpm来内部实现中还采用了PetriNet的概念，如token,signal等，jBpm对Token的应用很有特色，巧妙地利用Parent-Child Token的机制处理分支、父子流程等复杂应用场景。

    jBpm是最适合扩展的代表，是在所有开源引擎中最适宜被商业化应用的一款。首先其流程建模模型是基于Activity Diagram（活动图）的，并在引擎构建上融入了FSM和PetriNet思想，所以其内核和根基比较牢固扎实。其次，自从被JBoss收购后，其3.x系列的结构更加趋于微内核，Plug-in思想也更加深入。其同时还提供了对BPEL扩展，存储支持JBossHibernate实现，集成了JBoss seam，规则引擎准备采用JBossrules，并准备集成JBoss Messaging。这样，不论从内核和外围应用，jBpm都具有了强劲的动力。

引用链接

JPBM

OSWorkFlow

编写流程描述文件方式

      BPM是通过图形化的编辑工具（JBPM自带的Eclipse插件）来编写业务流程如开始状态，结束状态，以及状态之间的转换，之后会自动生成XML文件，但具体每一步相关的细节操作还是要手工配置（如该节点是属于什么类型节点，相关的函数，要不要较验）。

      OSWorkFlow则要通过手工写XML文件来定义流程文件，而且它涉及的标签元素比较多，其用户手册上也建议实施人员不要去修改流程，否则流程很容易破坏。

工作流信息保存方式

      JBPM是将流程信息直接保存到数据库，可以用任何方式对数据库的操作，这样就要引入保存工作流信息的相关表。

      OSWorkFlow是既可以保存在XML文件里，也可以保存在数据库中，保存在数据库中时需要配置propertySet.xml文件，比较复杂，而且它不是完全支持hibernate（如引入osuser来作权限分析时），此时要自定义操作数据库的方式。

与系统集成

      JBPM集成比较容易，加入Spring支持包spring-modules-jbpm31.jar,该包加入了Spring对JBPM的包装，所有的集成都是在此包基础之上。之后还要配置sessionFactoryForJbpm ,jbpmConfiguration,jbpmTemplate, jbpmDao。

      OSWorkFlow跟Spring集成须要如下所需组件：

    1)SpringHibernateWorkflowStore，让工作流程实例(如果需要的话)分享当前事务。      2) SpringTypeResolver，允许 OSWorkflow 从 Spring ApplicationContext中获得业务逻辑组件(conditions, functions等等)。      3)SpringConfiguration， 这是一个 Workflow Configuration 接口的实现类， 它包含指向 store和 factory的引用，这样可以在 spring 中注射或者连接。      4) SpringWorkflowFactory，这是一个 XMLWorkflowFactory 封装包，它可以允许从容器中注入 configuration，从而不再从其它的 XML 配置文件中读取它们。

    如果OSWorkFlow引入osuser.xml来设置权限，则不支持Hibernate3，因为osuser是比较独立的模块，目前还没有支持hibernate3，所以跟Spring集成时要修改配置文件applicationContext-hibernate3.xml

重点难点

      JPDL语言的学习，主要是用来编写流程文件；理解3个接口:动作处理接口(提供影响流程执行的方法，在event和action元素中被回调)，判定处理接口（用在decision判定节点中，提供方法来判定节点的转向），委派处理接口（用在task的委派子元素assignment中，用来指定将任务分配给指定的人员或角色）。

      工作流文件定义的元素，主要用来编写工作流；OSWorkFlow.xml及propertySet.xml文件的配置；InputMap接口、Workflow 接口及WorkflowDescriptor接口。

开发步骤

      通过图形编辑工具编写业务流程――>生成xml流程文件――>修改流程文件（判断节点是任务节点、普通节点还是判定节点,之后作相应修改）――>导入保存流程信息的数据库表――>部署流程定义文件（将流程文件中的内容放到数据库中）――>创建流程实例――>调用JBPM提供的signal方法执行流程流转

      手工编写工作流文件——>配置OSWorkflow.xml――>配置WorkStore——>配置propertySet.xml,osUser.xml文件（如果需要用户权限）――>调用AbatractWorkflow类加载OSWorkflow.xml(它会自动加载工作流文件及数据库配置文件)――>调用WorkFlow接口方法(initial()方法,transitionWorkflow（）方法，doAction（）方法)

流转方法

      先确定节点是什么节点，如果是普通的Node节点，则是流程执行到此节点不会中断，继续执行；如果是state节点，则流程执行到此节点会中断，直到系统外的参与者发会命令才能继续执行，即调用signal（）或end（）方法；如果节点是Task-node，则会根据task任务列表的任务有没全部执行完来决定流转。

      一个工作流包含多个步骤。每一个步骤都有一个当前状态(例如, Queued, Underway, or Finished)。每一个步骤中都有一个或者多个动作可以被执行。每一个动作都可以设置执行条件(condition)，也可以设置执行函数(pre-function or post-function)。动作产生结果(result)，导致工作流的状态和当前步骤发生改变

流程定义文件主要元素

      一个JBPM的流程定义XML文件中包含一个< process-definition>元素，而一个< process-definition>元素又包含零个或一个< description>元素，零个或多个的< swimlane>元素，一个< start-state>元素，零个或多个的< state>元素或< decision>元素或< fork>元素或< join>元素，以及零个或多个的< action>元素，零个或多个<task-node>和<node>元素，一个< end-state>元素等等。此外，< process definition>元素有一个标示符，以“name”属性来表示，这个属性必须存在，用来表示该流程的名称。

步骤（step）、条件（conditions）、循环（loops）、分支（spilts）、合并（joins）、角色（roles）、函数（function）

其他

      JBPM的Scheduler可以实现在JBPM流程中定时触发某一动作。在流程中JPBM提供了timer节点供我们使用，通过这个节点我们可以实现节点动作的定时触发。

引用链接

Activiti

JBPM5

相似之处

1、都是BPMN2过程建模和执行环境。

2、都是BPM系统（符合BPM规范）。

3、都是开源项目-遵循ASL协议（ Apache的 软件许可）。

4、都源自JBoss（Activiti5是jBPM4的衍生，jBPM5则基于Drools Flow）。 

5、都很成熟，从无到有，双方开始约始于2年半前。 都有对人工任务的生命周期管理。 

6、Activiti5和jBPM5唯一的区别是jBPM5基于WebService – HumanTask标准来描述人工任务和管理生命周期。 如有兴趣了解这方面的标准及其优点，可参阅WS – HT规范介绍 。

7、 都使用了不同风格的 Oryx 流程编辑器对BPMN2建模。 jBPM5采用的是 Intalio 维护的开源项目分支。 Activiti5则使用了Signavio维护的分支。

数据库持久层ORM

MyBatis3

Hibernate3

持久化标准

无

JPA规范

事务管理

MyBatis机制/Spring事务控制

Bitronix，基于JTA事务管理

数据库连接方式

Jdbc/DataSource

Jdbc/DataSource

支持数据库

Oracle、SQL Server、MySQL等多数数据库

Oracle、SQL Server、MySQL等多数数据库

设计模式

Command模式、观察者模式等

内部服务通讯

Service间通过API调用

基于Apache Mina异步通讯

集成接口

SOAP、Mule、RESTful

消息通讯

支持的流程格式

BPMN2、xPDL、jPDL等

目前仅只支持BPMN2 xml

引擎核心

PVM（流程虚拟机）

Drools

技术前身

jBPM3、jBPM4

Drools Flow

所属公司

Alfresco

jBoss.org

集成

      Activiti5使用Spring进行引擎配置以及各个Bean的管理，综合使用IoC和AOP技术，使用CXF作为Web Services实现的基础，使用MyBatis进行底层数据库ORM的管理，预先提供Bundle化包能较容易的与OSGi进行集成，通过与Mule ESB的集成和对外部服务（Web Service、RESTful等）的接口可以构建全面的SOA应用；

      jBPM5使用jBoss.org社区的大多数组件，以Drools Flow为核心组件作为流程引擎的核心构成，以Hibernate作为数据持久化ORM实现，采用基于JPA/JTA的可插拔的持久化和事务控制规范，使用Guvnor作为流程管理仓库，能够与Seam、Spring、OSGi等集成。

优劣对比

      从技术组成来看，Activiti最大的优势是采用了PVM（流程虚拟机），支持除了BPMN2.0规范之外的流程格式，与外部服务有良好的集成能力，延续了jBPM3、jBPM4良好的社区支持，服务接口清晰，链式API更为优雅；Activiti上手比较快，界面也比较简洁、直观

      劣势是持久化层没有遵循JPA规范。

      jBPM最大的优势是采用了Apache Mina异步通信技术，采用JPA/JTA持久化方面的标准，以功能齐全的Guvnor作为流程仓库，有RedHat(jBoss.org被红帽收购)的专业化支持；

      但其劣势也很明显，对自身技术依赖过紧且目前仅支持BPMN2。