Activiti源码分析.docx
《Activiti源码分析.docx》由会员分享，可在线阅读，更多相关《Activiti源码分析.docx（15页珍藏版）》请在冰豆网上搜索。
Activiti源码分析
Activiti源码分析
Activiti是业界很流行的java工作流引擎，关于Activiti与JBPM5的关系和如何选择不是本文要讨论的话题，相关内容可以baidu一下。
Activiti从架构角度看是比较优秀的，是很面向对象的，是我所阅读过的代码结构很棒的开源软件，个人认为比Spring，Hibernate的要好。
Activiti的基础编程框架
Activiti基于Spring，ibatis等开源中间件作为软件平台，在此之上构建了非常清晰的开发框架。
上图列出了Activiti的核心组件。
1.ProcessEngine
流程引擎的抽象，对于开发者来说，它是我们使用Activiti的facade，通过它可以获得我们需要的一切服务。
2.XXService（TaskService,RuntimeService,RepositoryService...）
Activiti按照流程的生命周期（定义，部署，运行）把不同阶段的服务封装在不同的Service中，用户可以非常清晰地使用特定阶段的接口。
通过ProcessEngine能够获得这些Service实例。
TaskService,RuntimeService,RepositoryService是非常重要的三个Service：
TaskService：
流程运行过程中，与每个任务节点相关的接口，比如complete,delete,delegate等等
RepositoryService:
流程定义和部署相关的存储服务。
RuntimeService：
流程运行时相关服务，如startProcessInstanceByKey.
关于ProcessEngine和XXService的关系，可以看下面这张图：
3.CommandContextIntercepter（CommandExecutor）
Activiti使用命令模式作为基础开发模式，上面Service中定义的各个方法都对应相应的命令对象（xxCmd）,Service把各种请求委托给xxCmd，xxCmd来决定命令的接收者，接收者执行后返回结果。
而CommandContextIntercepter顾名思义，它是一个拦截器，拦截所有命令，在命令执行前后执行一些公共性操作。
比如CommandContextIntercepter的核心方法：
Java代码
1publicTexecute（Commandcommand）{
2CommandContextcontext=commandContextFactory.createCommandContext（command）;
3
4try{
5//执行前保存上下文
6Context.setCommandContext（context）;
7Context.setProcessEngineConfiguration（processEngineConfiguration）;
8returnnext.execute（command）;//执行命令
9
10}catch（Exceptione）{
11context.exception（e）;
12
13}finally{
14try{
15//关闭上下文，内部会flushsession，把数据持久化到db等
16context.close（）;
17}finally{
18//释放上下文
19Context.removeCommandContext（）;
20Context.removeProcessEngineConfiguration（）;
21}
22}
23
24returnnull;
25}
关于命令模式的细节说明，网上有很多资料，这里不展开。
我只是想说一下我看到Activiti的这种设计之后的两点感受：
1）一个产品或者一个项目，从技术上必须有一个明确的、唯一的开发模型或者叫开发样式（真不知道怎么说恰当），我们常说希望一个团队的所有人写出的代码都有统一的风格，都像是一个人写出来的，很理想化，但做到很难，往往我们都是通过“规范”去约束大家这样做，而规范毕竟是程序之外的东西，主观性很强，不遵守规范的情况屡屡发生。
而如果架构师给出了明确的开发模型，并使用一些基础组件加以强化，把程序员要走的路规定清楚，那你想不遵守规范都会很难，因为那意味着你写的东西没法工作。
就像Activiti做的这样，明确以Command作为基本开发模型，辅之以Event-Listener，这样编程风格的整体性得到了保证。
2）使用命令模式的好处，我这里体会最深的就是职责分离，解耦。
有了Command，各个Service从角色上说只是一些协调者或者控制者，他不需要知道具体怎么做，他只是把任务交给了各个命令。
直接的好处是臃肿的、万能的大类没有了。
而这往往是我们平时开发中最深恶痛绝的地方。
4.核心业务对象（Task，ProcessInstance，Execution...）
org.activiti.engine.impl.persistence.entity包下的类是Activiti的核心业务对象。
它们是真正的对象，而不是只有数据没有行为的假对象，搞java企业级开发的人也许已经习惯了下面的层次划分：
controller->service->dao->entity,entity只是ORMapping中数据表的java对象体现，没有任何行为（getter/setter不能算行为），对于面向对象来说，这当然是有问题的，记得曾听人说过这样的话“使用面向对象语言进行设计和开发与面向对象的设计和开发是两回事”，面向对象讲究的是“封装”，“多态”，追求的是满足“开-闭”原则的、职责单一的对象社会。
如果你认同上述观点，那么相信Activiti会让你感觉舒服一些，以TaskEntity为例，其UML类图如下：
图2：
TaskEntity类
TaskEntity实现了3个接口：
Task，DelegateTask和PersistentObject。
其中PersistentObject是一个声明接口，表明TaskEntity需要持久化。
接口是一种角色的声明，是一份职责的描述而TaskEntity就是这个角色的具体扮演者，因此TaskEntity必须承担如complete,delegate等职责。
但是这里有些遗憾的是像complete这么重要的行为居然没有在3个接口中描述（难道是因为工期紧张？
^_^），因此“面向抽象”编程对于TaskEntity来说还没有完全做到。
但至少Activiti告诉我们：
1）牢记面向抽象编程,把职责拆分为不同的接口，让接口来体现对象的职责，而不用去关心这份职责具体由哪个对象实现；
2）entity其实可以也应该是真正的对象。
5.Activiti的上下文组件（Context）
上下文（Context）用来保存生命周期很长的、全局性的信息。
Activiti的Context类（在org.activiti.engine.impl.context包下）保持如下三类信息：
图3：
Context类
CommandContext：
命令上下文，保持每个命令需要的必要资源，如持久化需要的session。
ProcessEngineConfigurationImpl：
流程引擎相关的配置信息。
它是整个引擎的全局配置信息，mailServerHost，DataSource等。
单例。
该实例在流程引擎创建时被实例化，其调用stack如下图：
图4：
ProcessEngineConfiguration的初始化
ExecutionContext：
刚看到这个类感觉有些奇怪，不明白其作用是什么。
看其代码持有ExecutionEntity这个实例。
而ExecutionEntity是Activiti中非常重要的一个类，//TODO
6.Activiti的持久化框架（组件）
Activiti使用ibatis作为ORMapping工具。
在此基础之上Activiti设计了自己的持久化框架，看一张图：
图5：
Activiti持久化框架
顶层接口是Session和SessionFactory，这都非常好理解了。
Session有两个实现类：
⏹DbSqlSession：
简单点说，DbSqlSession负责sql表达式的执行。
⏹AbstractManager:
简单点说，AbstractManager及其子类负责面向对象的持久化操作同理DbSqlSessionFactory与GenericManagerFactory的区别就很好理解了。
持久化框架也是在流程引擎建立时初始化的，具体见图4.
7.Event-Listener组件
Activiti允许客户端代码介入流程的执行。
为此提供了一个基础组件，看图：
图6：
用户代码介入流程的基础组件
用户可以介入的代码类型包括：
TaskListener，JavaDelegate，Expression，ExecutionListener。
ProcessEngineConfigurationImpl持有DelegateInterceptor的某个实例，这样就可以随时非常方便地调用handleInvocation
8.Cache组件
对Activiti的cache实现很感兴趣，但现在我了解到的情况（也许还没有了解清楚）其cache的实现还是很简单的，在DbSqlSession中有cache实现：
Java代码
26protectedListinsertedObjects=newArrayList（）;
27protectedMap>,Map>cachedObjects=newHashMap>,Map>（）;
28protectedListdeletedObjects=newArrayList（）;
29protectedListdeserializedObjects=newArrayList（）;
也就是说Activiti就是基于内存的List和Map来做缓存的。
具体怎么用的呢？
以DbSqlSession.selectOne方法为例：
Java代码
30publicObjectselectOne（Stringstatement,Objectparameter）{
31statement=dbSqlSessionFactory.mapStatement（statement）;
32Objectresult=sqlSession.selectOne（statement,parameter）;
33if（resultinstanceofPersistentObject）{
34PersistentObjectloadedObject=（PersistentObject）result;
35//缓存处理
36result=cacheFilter（loadedObject）;
37}
38returnresult;
39}
Java代码
40protectedPersistentObjectcacheFilter（PersistentObjectpersistentObject）{
41PersistentObjectcachedPersistentObject=cacheGet（persistentObject.getClass（）,persistentObject.getId（））;
42if（cachedPersistentObject!
=null）{
43//如果缓存中有就直接返回
44returncachedPersistentObject;
45}
46//否则，就先放入缓存
47cachePut（persistentObject,true）;
48returnpersistentObject;
49}
Java代码
50protectedCachedObjectcachePut（PersistentObjectpersistentObject,booleanstoreState）{
51MapclassCache=cachedObjects.get（persistentObject.getClass（））;
52if（classCache==null）{
53classCache=newHashMap（）;
54cachedObjects.put（persistentObject.getClass（）,classCache）;
55}
56//这里是关键：
一个CachedObject包含被缓存的对象本身：
persistentObject和缓存的状态：
storeState
57//Activiti正是根据storeState来判别缓存中的数据是否被更新是否与db保持一致的。
58CachedObjectcachedObject=newCachedObject（persistentObject,storeState）;
59classCache.put（persistentObject.getId（）,cachedObject）;
60returncachedObject;
61}
看了Activiti的缓存设计，我现在最大的疑问是Activiti貌似不支持cluster，因为其缓存设计是基于单机内存的，这个问题还需要进一步调查。
9.异步执行组件
Activiti可以异步执行job（具体例子可以看一下ProcessInstancestartProcessInstanceByKey（StringprocessDefinitionKey）;），下面简单分析一下其实现过程，还是先看图：
图7：
异步执行组件核心类
JobExecutor是异步执行组件的核心类，其包含三个主要属性：
⏹JobAcquisitionThreadjobAccquisitionThread:
执行任务的线程extendsjava.lang.Thread
⏹BlockingQueuethreadPoolQueue
⏹ThreadPoolExecutorthreadPoolExecutor:
线程池
方法ProcessEngines在引擎启动时调用JobExecutor.start，JobAcquisitionThread线程即开始工作，其run方法不断循环执行AcquiredJobs中的job，执行一次后线程等待一定时间直到超时或者JobExecutor.jobWasAdded方法因为有新任务而被调用。
这里发现有一处设计的不够好：
JobAcquisitionThread与JobExecutor之间的关系是如此紧密（你中有我，我中有你），那么可以把JobAcquisitionThread作为JobExecutor的内部类来实现，同时把ThreadPoolExecutorthreadPoolExecutor交给JobAcquisitionThread来管理，JobExecutor只负责接受任务以及启动、停止等更高级的工作，具体细节委托给JobAcquisitionThread，责任分解，便于维护，JobExecutor的代码也会看起来更清晰。
10.PVM
PVM（ProcessVirtalMachine）,流程虚拟机API暴露了流程虚拟机的POJO核心，流程虚拟机API描述了一个工作流流程必备的组件，这些组件包括：
⏹PvmProcessDefinition：
流程的定义，形象点说就是用户画的那个图。
静态含义。
⏹PvmProcessInstance：
流程实例，用户发起的某个PvmProcessDefinition的一个实例，动态含义。
⏹PvmActivity：
流程中的一个节点
⏹PvmTransition：
衔接各个节点之间的路径，形象点说就是图中各个节点之间的连接线。
⏹PvmEvent：
流程执行过程中触发的事件
以上这些组件很好地对一个流程进行了建模和抽象。
每个组件都有很清晰的角色和职责划分。
另外，有了这些API，我们可以通过编程的方式，用代码来“画”一个流程图并让他run起来，例如：
Java代码
1PvmProcessDefinitionprocessDefinition=newProcessDefinitionBuilder（）
2.createActivity（"a"）.initial（）.behavior（newWaitState（））
3.transition（"b"）.endActivity（）.createActivity（"b"）
4.behavior（newWaitState（））.transition（"c"）.endActivity（）
5.createActivity（"c"）.behavior（newWaitState（））.endActivity（）
6.buildProcessDefinition（）;
7PvmProcessInstanceprocessInstance=processDefinition
8.createProcessInstance（）;
9processInstance.start（）;
10PvmExecutionactivityInstance=processInstance.findExecution（"a"）;
11assertNotNull（activityInstance）;
12activityInstance.signal（null,null）;
13activityInstance=processInstance.findExecution（"b"）;
14assertNotNull（activityInstance）;
15activityInstance.signal（null,null）;
16activityInstance=processInstance.findExecution（"c"）;
17assertNotNull（activityInstance）;
以上代码都很简单，很好理解，只有一点需要说明一下，粗体红色背景的behavior方法，为一个PvmActivity增加ActivityBehavior，这是干什么呢？
ActivityBehavior是一个interface,其接口声明很简单：
Java代码
18/**
19*@authorTomBaeyens
20*/
21publicinterfaceActivityBehavior{
22
23voidexecute（ActivityExecutionexecution）throwsException;
24}
我的理解：
Activiti把完成一个PvmActivity的行为单独建模封装在ActivityBehavior中。
execute方法只有一个参数ActivityExecution，为啥这么设计？
为了更好地理解ActivityBehavior的作用，我们以TaskEplete方法为例,分析其执行过程，先看complete的代码：
Java代码
25publicvoidcomplete（）{
26fireEvent（TaskListener.EVENTNAME_COMPLETE）;
27
28Context
29.getCommandContext（）
30.getTaskManager（）
31.deleteTask（this,TaskEntity.DELETE_REASON_COMPLETED,false）;
32
33if（executionId!
=null）{
34getExecution（）.signal（null,null）;
35}
36}
代码很简单，也很好理解（可能出乎我们的意料，因为完成一个task，其实有很多事情要做的）：
1.fireEvent：
通知Listener，本任务完成了。
2.数据持久化相关的动作
3.getExecution（）.signal（null,null）：
发信号，这里面隐藏的东西就多了，总体来说，完成了当前任务流程怎么走，怎么生成新的任务都是在这里完成的。
进去看看：
Java代码
37publicvoidsignal（StringsignalName,ObjectsignalData）{
38ensureActivityInitialized（）;
39SignallableActivityBehavioractivityBehavior=（SignallableActivityBehavior）activity.getActivityBehavior（）;
40try{
41activityBehavior.signal（this,signalName,signalData）;
42}catch（RuntimeExceptione）{
43throwe;
44}catch（Exceptione）{
45thrownewPvmException（"couldn'tprocesssignal'"+signalName+"'onactivity'"+activity.getId（）+"':
"+e.getMessage（）,e）;
46}
47}
ExecutionEntity.signal方法核心工作就是把发信号的工作委托给PvmActivity的activityBehavior.这里的设计存在问题，很显然其触犯了一个代码的坏味道：
消息链。
它让ExceutionEntity没有必要地与SignallableActivityBehavior产生了耦合，更好的做法应该是PvmActivity提供signal方法，其内部调用ActivityBehavior完成发信号工作。
其实看看PvmActivity的接口声明，我不免也有疑问，本来属于PvmActivity的很重要的职责在其接口声明中都没有体现，why？
升级会员 