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]  view plain  copy

1. public   T execute(Command  command) {    
2.     CommandContext context = commandContextFactory.createCommandContext(command);    
4. try {    
5. //执行前保存上下文  
6.       Context.setCommandContext(context);    
7.       Context.setProcessEngineConfiguration(processEngineConfiguration);    
8. return next.execute(command);//执行命令  
10.     } catch (Exception e) {    
11.       context.exception(e);    
13.     } finally {    
14. try {    
15. //关闭上下文，内部会flush session，把数据持久化到db等  
16.         context.close();    
17.       } finally {    
18. //释放上下文  
19.         Context.removeCommandContext();    
20.         Context.removeProcessEngineConfiguration();    
21.       }    
22.     }    
24. returnnull;    
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]  view plain  copy

 

1. protected List  insertedObjects =  new ArrayList ();    
2. protected Map , Map <string, cachedobject>> cachedObjects =  new HashMap , Map <string,cachedobject>>();    
3. protected List  deletedObjects =  new ArrayList ();    
4. protected List  deserializedObjects =  new ArrayList ();    

 也就是说Activiti就是基于内存的List和Map来作缓存的。具体怎么用的呢？以DbSqlSession.selectOne方法为例：

 

[java]  view plain  copy

1. public Object selectOne(String statement, Object parameter) {    
2.   statement = dbSqlSessionFactory.mapStatement(statement);    
3.   Object result = sqlSession.selectOne(statement, parameter);    
4. if (result instanceof PersistentObject) {    
5.     PersistentObject loadedObject = (PersistentObject) result;    
6. 缓存处理    
7.     result = cacheFilter(loadedObject);    
8.   }    
9. return result;    
10. }    

 

 

[java]  view plain  copy

 

1. protected PersistentObject cacheFilter(PersistentObject persistentObject) {    
2.     PersistentObject cachedPersistentObject = cacheGet(persistentObject.getClass(), persistentObject.getId());    
3. if (cachedPersistentObject!=null) {    
4. //若是缓存中有就直接返回  
5. return cachedPersistentObject;    
6.     }    
7. //不然，就先放入缓存  
8.     cachePut(persistentObject, true);    
9. return persistentObject;    
10.   }    

 

 

 

[java]  view plain  copy

1. protected CachedObject cachePut(PersistentObject persistentObject, boolean storeState) {    
2.   Map <string, cachedobject> classCache = cachedObjects.get(persistentObject.getClass());    
3. if (classCache==null) {    
4.     classCache = new HashMap <string, cachedobject>();    
5.     cachedObjects.put(persistentObject.getClass(), classCache);    
6.   }    
7. //这里是关键：一个CachedObject包含被缓存的对象自己：persistentObject和缓存的状态：storeState  
8. //Activiti正是根据storeState来判别缓存中的数据是否被更新是否与db保持一致的。  
9.   CachedObject cachedObject = new CachedObject(persistentObject, storeState);    
10.   classCache.put(persistentObject.getId(), cachedObject);    
11. return cachedObject;    
12. }    

 

看了Activiti的缓存设计，我如今最大的疑问是Activiti貌似不支持cluster，由于其缓存设计是基于单机内存的，这个问题还须要进一步调查。

 

9.异步执行组件

Activiti能够异步执行job（具体例子能够看一下ProcessInstance startProcessInstanceByKey(String processDefinitionKey);），下面简单分析一下其实现过程，仍是先看图：

（图7：异步执行组件核心类）

JobExecutor是异步执行组件的核心类，其包含三个主要属性：

1）JobAcquisitionThread jobAccquisitionThread:执行任务的线程 extends java.lang.Thread

2)BlockingQueue threadPoolQueue

3)ThreadPoolExecutor threadPoolExecutor:线程池

 

方法ProcessEngines在引擎启动时调用JobExecutor.start，JobAcquisitionThread 线程即开始工做，其run方法不断循环执行AcquiredJobs中的job，执行一次后线程等待必定时间直到超时或者JobExecutor.jobWasAdded方法由于有新任务而被调用。

 

这里发现有一处设计的不够好：JobAcquisitionThread 与JobExecutor之间的关系是如此紧密（你中有我，我中有你），那么能够把JobAcquisitionThread 做为JobExecutor的内部类来实现，同时把ThreadPoolExecutor threadPoolExecutor交给JobAcquisitionThread 来管理，JobExecutor只负责接受任务以及启动、中止等更高级的工做，具体细节委托给JobAcquisitionThread ，责任分解，便于维护，JobExecutor的代码也会看起来更清晰。

 

 

10.PVM

PVM:Process Virtal Machine,流程虚拟机API暴露了流程虚拟机的POJO核心，流程虚拟机API描述了一个工做流流程必备的组件，这些组件包括：

PvmProcessDefinition：流程的定义，形象点说就是用户画的那个图。静态含义。

PvmProcessInstance：流程实例，用户发起的某个PvmProcessDefinition的一个实例，动态含义。

PvmActivity：流程中的一个节点

PvmTransition：衔接各个节点之间的路径，形象点说就是图中各个节点之间的链接线。

PvmEvent：流程执行过程当中触发的事件

 

以上这些组件很好地对一个流程进行了建模和抽象。每一个组件都有很清晰的角色和职责划分。另外，有了这些API，咱们能够经过编程的方式，用代码来“画”一个流程图并让他run起来，例如：

 

[java]  view plain  copy

 

1. PvmProcessDefinition processDefinition = new ProcessDefinitionBuilder()    
2.         .createActivity("a").initial(). "background-color: #ff0000;" >behavior( new  WaitState())    
3.         .transition("b").endActivity().createActivity("b")    
4.         .behavior(new WaitState()).transition("c").endActivity()    
5.         .createActivity("c").behavior(new WaitState()).endActivity()    
6.         .buildProcessDefinition();    
7. PvmProcessInstance processInstance = processDefinition    
8.         .createProcessInstance();    
9. processInstance.start();    
10. PvmExecution activityInstance = processInstance.findExecution("a");    
11. assertNotNull(activityInstance);    
12. activityInstance.signal(null, null);    
13. activityInstance = processInstance.findExecution("b");    
14. assertNotNull(activityInstance);    
15. activityInstance.signal(null, null);    
16. activityInstance = processInstance.findExecution("c");    
17. assertNotNull(activityInstance);    

以上代码都很简单，很好理解，只有一点须要说明一下，粗体红色背景的behavior方法，为一个PvmActivity增长ActivityBehavior，这是干什么呢？ActivityBehavior是一个interface,其接口声明很简单：

 

[java]  view plain  copy

1. /** 
2.  * @author Tom Baeyens 
3.  */
4. publicinterface ActivityBehavior {    
6. void execute(ActivityExecution execution) throws Exception;    
7. }    

 

个人理解：Activiti把完成一个PvmActivity的行为单独建模封装在ActivityBehavior中。execute方法只有一个参数ActivityExecution，为啥这么设计？

 

 

为了更好地理解ActivityBehavior的做用，咱们以TaskEntity.complete方法为例,分析其执行过程，先看complete的代码：

 

[java]  view plain  copy

 

1. publicvoid complete() {    
2.   fireEvent(TaskListener.EVENTNAME_COMPLETE);    
4.   Context    
5.     .getCommandContext()    
6.     .getTaskManager()    
7.     .deleteTask(this, TaskEntity.DELETE_REASON_COMPLETED, false);    
9. if (executionId!=null) {    
10.     getExecution().signal(null, null);    
11.   }    
12. }    

代码很简单，也很好理解（可能出乎咱们的意料，由于完成一个task，其实有不少事情要作的）：

1.fireEvent：通知Listener，本任务完成了。

2.数据持久化相关的动做

3.getExecution().signal(null, null)：发信号，这里面隐藏的东西就多了，整体来讲，完成了当前任务流程怎么走，怎么生成新的任务都是在这里完成的。

进去看看：

 

[java]  view plain  copy

1. publicvoid signal(String signalName, Object signalData) {    
2.   ensureActivityInitialized();    
3.   SignallableActivityBehavior activityBehavior = (SignallableActivityBehavior) activity.getActivityBehavior();    
4. try {    
5.     activityBehavior.signal(this, signalName, signalData);    
6.   } catch (RuntimeException e) {    
7. throw e;    
8.   } catch (Exception e) {    
9. thrownew PvmException("couldn't process signal '"+signalName+"' on activity '"+activity.getId()+"': "+e.getMessage(), e);    
10.   }    
11. }  "background-color: rgb(250, 250, 250); font-size: 1em; font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', Consolas, 'Courier New', monospace; ">   

ExecutionEntity.signal方法核心工做就是把发信号的工做委托给PvmActivity的activityBehavior. 这里的设计存在问题，很显然其触犯了一个代码的坏味道：消息链。它让ExceutionEntity没有必要地与SignallableActivityBehavior 产生了耦合，更好的作法应该是PvmActivity提供signal方法，其内部调用ActivityBehavior完成发信号工做。

 

其实看看PvmActivity的接口声明，我难免也有疑问，原本属于PvmActivity的很重要的职责在其接口声明中都没有体现，why？？

 

[java]  view plain  copy

 

1. /** 
2.  * @author Tom Baeyens 
3.  */
4. publicinterface PvmActivity extends PvmScope {    
6. boolean isAsync();    
8.   PvmScope getParent();    
10.   List  getIncomingTransitions();    
12.   List  getOutgoingTransitions();    
14.   PvmTransition findOutgoingTransition(String transitionId);    
15. }    

把思路拉回来，咱们继续看activityBehavior.signal方法内部的具体实现。