Java开源工作流对比

Java开源工作流对比

工作流(Workflow)

1、业务过程的部分或整体在计算机应用环境下的自动化；

2、是对工作流程及其各步骤之间业务规则的抽象、概括描述；

3、工作流主要解决的问题是：为了实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务；

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

5、Georgakopoulos给出的工作流定义是：工作流是将一组任务组织起来一完成某个经营过程：定义了任务的出发顺序和触发条件，每个任务可以由一个或多个软件系统完成，也可以由一个或一组人完成，还可以由一个或多个人与系统软件协作完成；

6、工作流的特点：（1）极大地提高了工作效率；（2）本身只是业务逻辑决定的一个事务流程；（3）一旦启动，自动流转；（4）具有事务的特征；（5）流程节点灵活可配；（6）符合面向对象的思想

7、工作流的分类：（1）顺序工作流；（2）流程图工作流；（3）状态机工作流

8、工作流就是：在一个工作群组中，为了达成某一个共同目的而需要多人协力以循序或平行工作的形式来共同完成的任务

关于工作流的几个名词解释：
任务	泛指各种事务上所必需执行的流程性工作
循序或平行工作	工作的流动性是一个人接着一个人执行，或同时由多个人分开执行，或是上述两类工作合并之后的混合型工作
多人	若是单人就可以完成的工作，则不能归类为流程工作；凡是一件工作必须由两个人或更多人来协力完成的工作才能称之为流程工作；
共同目的	多人参与的流程性工作，必须是以完成共同目的为前提；如果一群人是分别针对不同的专案来执行个别的工作，并不算构成一个工作流程；

 

9、 链接：   从程序员的角度来看为什么我们需要工作流

10、 链接：   工作流简介及其6种常用的工作流引擎

 

J2EE常用工作流比较

引用链接	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都具有了强劲的动力。

 

用OSWorkFlow和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节点供我们使用，通过这个节点我们可以实现节点动作的定时触发。

 

 

深入了解jBPM5与Activiti之间的差异对比

引用链接	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。