前言
从本篇文章我们开始介绍工作流框架activiti的相关知识，不过在介绍activiti的知识之前，我们很有必要对工作流的一些基本概念进行了解。
工作流重要概念
Workflow
Workflow(工作流)是“业务过程的部分或整体在计算机应用环境下的自动化，是对工作流程及其各操作步骤之间业务规则的抽象、概括描述”，它主要解决的是“使在多个参与者之间按照一种提前定义好的规则流程来传递与执行文档、信息或任务的过程，让这个过程可以自动进行或者部分自动执行，从而完成预期的业务目标”。
WfMC
提到工作流就不能不提到工作流管理联盟(WfMC，WorkflowManagementCoalition)，它是一个由涉及工作流和业务流程管理的推广学者（adopters）、开发工程师、顾问、分析师、大学和研究团体的全球性组织，它的成立，标志着工作流技术开始进入相对成熟的阶段。该组织创建并完善了工作流管理系统的相关术语、体系结构及应用编程接口等方面制定了一系列标准，是唯一的致力于工作流标准的专业组织。
WfMS
接下来要说的是工作流管理系统(WorkflowManagement System,WfMS)，它完成了工作量的定义和管理，并按照在系统中预先定义好的工作流规则进行工作流实例的执行的软件系统，这里要说明一下的是，并不是我们企业自己的系统应用了工作流就是工作流管理系统了，工作流管理系统不是企业的业务系统，而是为企业的业务系统的运行提供了一个软件的支撑环境。WfMS被用来定义、管理和执行工作流程，它的目标是管理工作的流程以确保工作在正确的时间被期望的人员所执行。同时也可以在自动化进行的业务过程中插入人工的执行和干预。
WfMS与工作流框架
WfMS我一般习惯于称它为工作流框架，常见的工作流框Activiti、JBPM、OSWorkflow、ActiveBPEL、YAWL等。
工作流引擎
个人觉得直接理解工作流引擎概念有点难度，我们可以先通过了解工作流引擎的职责再反过来理解工作流引擎，工作流引擎一般都做两件事情：
1.定义流程，也就是给我们提供某种规范来定义规则，以及如何定义一个流程的这种规范，同事我们可以根据工作流引擎提供的相关概念来定义更为复杂的流程，这就是工作流引擎做的第一件事叫做定义流程。
2.执行流程，也就是工作流引擎需要解释这个规则，还要负责流程，它相当于流程的调度者，监控每个流程的执行情况，并将流程操作发往下一步，或者根据条件休眠或终止流程的这么一个过程就叫做执行流程。
了解完工作流引擎的这两个职责，我相信对于什么是工作流引擎一定已经有了一定的认识了，我们在用一句稍微有点官方的话来总结一下工作流引擎，工作流引擎为我们提供相关规则概念的定义，给我们提供了相关的API来调用这个引擎去执行流程。流程的操作实际上就是工作流引擎提供相关的api我们去调用它。
工作流框架与工作流引擎
上面我们提及了常见了几个工作流框架，其中现在的Activiti和JBPM5.0之前的版本都是基于ProcessEngine 工作流引擎的工作流框架；JBPM5.0开始是基于DroolsFlow为工作流引擎的工作流框架；其中OSWorkflow是以工作流引擎命名的工作流框架，所以OSWorkflow是基于OSWorkflow工作流引擎的工作流框架；ActiveBPEL是基于工作流BPEL引擎的工作流框架…….
到这里关于工作流的相关概念就介绍完了，接下来我们先了解一下我们的主角activiti的前世今生。
Activiti前世今生
Activiti 的创始人是 Tom Baeyens 说到Tom Baeyens 就不能不提他与jbpm的渊源。TomBaeyens 是 jBPM 的创始人，在 2002年，Tom Baeyens创建了基于状态机原理的jBPM流程引擎。jBPM经过了JBoss和Redhat公司之后，发展到了 jBPM 4。由于jBPM使用的是 GPL开源协议，并且与JBoss和Redhat公司的其他产品线结合的越来越紧密，对jBPM在更广泛的范围使用形成了阻碍。JBoss内部对jBPM未来版本的架构实现产生了严重的意见分歧，在2005年 Tom Baeyens离开了JBoss公司加入了Alfresco 公司，创建了使用Apache based-license V2的、独立于Alfresco产品的开源流程产品Activiti 。Activiti在2010年3月份开始启动，到了2010年12月份正式发布第一个版本，新的基于jBPM4的开源工作流系统Activiti 5.0 ！所以说Activiti5是在jBPM 3、jBPM 4的基础上发展而来的，是原jBPM 的延续。
Activiti 与jBPM 5的比较
jBPM 5则与之前的jBPM3、jBPM 4没有太大关联，且舍弃了备受推崇的PVM（流程虚拟机）思想，转而选择jBoss自身产品DroolsFlow作为流程引擎的核心实现，工作流最为重要的“人机交互”任务（类似于审批活动）则由单独的一块“Human Task Service”附加到DroolsFlow上实现，任务的查询、处理等行为通过Apache Mina异步通信机制完成。
|
序号 |
技术组成 |
Activiti |
jBPM5 |
|
1 |
数据库持久层ORM |
MyBatis3 |
Hibernate3 |
|
2 |
持久化标准 |
无 |
JPA规范 |
|
3 |
事务管理 |
MyBatis机制/spring事务控制 |
Bitronix，基于JTA事务管理 |
|
4 |
数据库连接方式 |
Jdbc/DataSource |
Jdbc/DataSource |
|
5 |
支持数据库 |
Oracle、SQL Server、MySQL等多数数据库 |
|
|
6 |
设计模式 |
Command模式、观察者模式等 |
无 |
|
7 |
内部服务通讯 |
Service间通过API调用 |
基于Apache Mina异步通讯 |
|
8 |
集成接口 |
SOAP、Mule、RESTful |
消息通讯 |
|
9 |
支持的流程格式 |
BPMN2、xPDL、jPDL等 |
目前仅只支持BPMN2 xml |
|
10 |
引擎核心 |
PVM（流程虚拟机） |
Drools |
|
11 |
技术前身 |
jBPM3、jBPM4 |
Drools Flow |
|
12 |
所属公司 |
Alfresco |
jBoss.org |
从表格中的比较我们可以看出，Activiti最大的优势是采用了PVM（流程虚拟机），支持除了BPMN2.0规范之外的流程格式，与外部服务有良好的集成能力，延续了jBPM3、jBPM4良好的社区支持，服务接口清晰，链式API更为优雅；劣势是持久化层没有遵循JPA规范。
jBPM最大的优势是采用了ApacheMina异步通信技术，采用JPA/JTA持久化方面的标准，以功能齐全的Guvnor作为流程仓库，有RedHat(jBoss.org被红帽收购)的专业化支持；但其劣势也很明显，对自身技术依赖过紧且目前仅支持BPMN2。
我们对Activiti和jBPM进行比较目的是为了让我们可以对他们的特性更加的了解，只有了解了他们的特性以后，这样当我们遇到具体的项目时就可以根据需要来选用适合的工作流框架。
总结
我们这篇文章主要介绍了工作流相关的基本概念，同时又了解了Activiti的前世今生，最后将Activiti与jBPM进行了比较。
http://blog.csdn.net/zwk626542417/article/details/46592471