`
jiangwenfeng762
  • 浏览: 288227 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

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的核心方法:

 

  public <T> T execute(Command<T> command) {
    CommandContext context = commandContextFactory.createCommandContext(command);

    try {
//执行前保存上下文
      Context.setCommandContext(context);
      Context.setProcessEngineConfiguration(processEngineConfiguration);
      return next.execute(command);//执行命令
      
    } catch (Exception e) {
      context.exception(e);
      
    } finally {
      try {
//关闭上下文,内部会flush session,把数据持久化到db等
        context.close();
      } finally {
//释放上下文
        Context.removeCommandContext();
        Context.removeProcessEngineConfiguration();
      }
    }
    
    return null;
  }
 

关于命令模式的细节说明,网上有很多资料,这里不展开。我只是想说一下我看到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实现:

 

  protected List<PersistentObject> insertedObjects = new ArrayList<PersistentObject>();
  protected Map<Class<?>, Map<String, CachedObject>> cachedObjects = new HashMap<Class<?>, Map<String,CachedObject>>();
  protected List<DeleteOperation> deletedObjects = new ArrayList<DeleteOperation>();
  protected List<DeserializedObject> deserializedObjects = new ArrayList<DeserializedObject>();

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

 

  public Object selectOne(String statement, Object parameter) {
    statement = dbSqlSessionFactory.mapStatement(statement);
    Object result = sqlSession.selectOne(statement, parameter);
    if (result instanceof PersistentObject) {
      PersistentObject loadedObject = (PersistentObject) result;
//缓存处理
      result = cacheFilter(loadedObject);
    }
    return result;
  }

 

 

  protected PersistentObject cacheFilter(PersistentObject persistentObject) {
    PersistentObject cachedPersistentObject = cacheGet(persistentObject.getClass(), persistentObject.getId());
    if (cachedPersistentObject!=null) {
//如果缓存中有就直接返回
      return cachedPersistentObject;
    }
//否则,就先放入缓存
    cachePut(persistentObject, true);
    return persistentObject;
  }

 

 

 

  protected CachedObject cachePut(PersistentObject persistentObject, boolean storeState) {
    Map<String, CachedObject> classCache = cachedObjects.get(persistentObject.getClass());
    if (classCache==null) {
      classCache = new HashMap<String, CachedObject>();
      cachedObjects.put(persistentObject.getClass(), classCache);
    }
    //这里是关键:一个CachedObject包含被缓存的对象本身:persistentObject和缓存的状态:storeState
    //Activiti正是根据storeState来判别缓存中的数据是否被更新是否与db保持一致的。
    CachedObject cachedObject = new CachedObject(persistentObject, storeState);
    classCache.put(persistentObject.getId(), cachedObject);
    return cachedObject;
  }

 

看了Activiti的缓存设计,我现在最大的疑问是Activiti貌似不支持cluster,因为其缓存设计是基于单机内存的,这个问题还需要进一步调查。

 

9.异步执行组件

Activiti可以异步执行job(具体例子可以看一下ProcessInstance startProcessInstanceByKey(String processDefinitionKey);),下面简单分析一下其实现过程,还是先看图:

(图7:异步执行组件核心类)

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

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

2)BlockingQueue<Runnable> 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起来,例如:

		PvmProcessDefinition processDefinition = new ProcessDefinitionBuilder()
				.createActivity("a").initial().behavior(new WaitState())
				.transition("b").endActivity().createActivity("b")
				.behavior(new WaitState()).transition("c").endActivity()
				.createActivity("c").behavior(new WaitState()).endActivity()
				.buildProcessDefinition();
		PvmProcessInstance processInstance = processDefinition
				.createProcessInstance();
		processInstance.start();
		PvmExecution activityInstance = processInstance.findExecution("a");
		assertNotNull(activityInstance);
		activityInstance.signal(null, null);
		activityInstance = processInstance.findExecution("b");
		assertNotNull(activityInstance);
		activityInstance.signal(null, null);
		activityInstance = processInstance.findExecution("c");
		assertNotNull(activityInstance);
 

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

/**
 * @author Tom Baeyens
 */
public interface ActivityBehavior {

  void execute(ActivityExecution execution) throws Exception;
}

 

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

 

 

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

  public void complete() {
    fireEvent(TaskListener.EVENTNAME_COMPLETE);

    Context
      .getCommandContext()
      .getTaskManager()
      .deleteTask(this, TaskEntity.DELETE_REASON_COMPLETED, false);
    
    if (executionId!=null) {
      getExecution().signal(null, null);
    }
  }
 

代码很简单,也很好理解(可能出乎我们的意料,因为完成一个task,其实有很多事情要做的):

1.fireEvent:通知Listener,本任务完成了。

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

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

进去看看:

  public void signal(String signalName, Object signalData) {
    ensureActivityInitialized();
    SignallableActivityBehavior activityBehavior = (SignallableActivityBehavior) activity.getActivityBehavior();
    try {
      activityBehavior.signal(this, signalName, signalData);
    } catch (RuntimeException e) {
      throw e;
    } catch (Exception e) {
      throw new PvmException("couldn't process signal '"+signalName+"' on activity '"+activity.getId()+"': "+e.getMessage(), e);
    }
  }
 

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

 

其实看看PvmActivity的接口声明,我不免也有疑问,本来属于PvmActivity的很重要的职责在其接口声明中都没有体现,why??

/**
 * @author Tom Baeyens
 */
public interface PvmActivity extends PvmScope {
  
  boolean isAsync();

  PvmScope getParent();

  List<PvmTransition> getIncomingTransitions();

  List<PvmTransition> getOutgoingTransitions();
  
  PvmTransition findOutgoingTransition(String transitionId);
}
 

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

//待续

  • 大小: 72.3 KB
  • 大小: 19.7 KB
  • 大小: 23.1 KB
  • 大小: 41.3 KB
  • 大小: 49.1 KB
  • 大小: 37.4 KB
  • 大小: 31 KB
  • 大小: 30.9 KB
分享到:
评论
10 楼 dengfj 2018-06-05  
      session = sessionFactory.openSession();调用DbSqlSessionFactory的openSession()。
这里是new一个对象,所以每次的DbSqlSession中缓存都是临时的
  public Session openSession() {
    return new DbSqlSession(this);
  }

XiaoFan012 写道
关于所谓的缓存,我理解它实际只是在一个session内部的小缓存,到CommandInvoker把Command执行完毕后,CommandContextInterceptor里面关闭session,执行session.flush(),从而把缓存对象进行入库落地操作,至此小缓存工作结束。

另外,文章真的很不错,赞!!

9 楼 xewsk 2017-12-16  
CommandContextIntercepter Interceptor单词拼错了
8 楼 XiaoFan012 2016-10-28  
关于所谓的缓存,我理解它实际只是在一个session内部的小缓存,到CommandInvoker把Command执行完毕后,CommandContextInterceptor里面关闭session,执行session.flush(),从而把缓存对象进行入库落地操作,至此小缓存工作结束。

另外,文章真的很不错,赞!!
7 楼 zhangyunyue 2015-03-12  
很不错的文章,期待有新的东西,刚接触,看你这文章收益颇多!
6 楼 iamzhongyong 2014-04-08  
文章不错。。。
5 楼 crackajack_zg 2013-10-11  
最近看complete 方法 ,代码调试了很多次一直不明白 今天看了这文章,有点点明白了。
4 楼 shanjing 2013-03-20  
我刚开始研究,希望能得到你指点一二
3 楼 shanjing 2013-03-20  
不错,哥儿们
2 楼 redtail 2013-01-11  
刚好也在研究这东西呢,正好搜到这篇文章,写的很好啊 期待完善
1 楼 dananren428 2012-06-06  
哥们,分析的挺不错

相关推荐

    Activiti 源码分析

    Activiti 源码分析,流程文件部署主要涉及到 3 个表,分别是:ACT_GE_BYTEARRAY、ACT_RE_DEPLOYMENT、 ACT_RE_PROCDEF。主要完成“部署包”--&gt;“流程定义文件”--&gt;“所有包内文件”的解析部署关系 流程定义的部署...

    activiti 源码分析

    总之,Activiti 源码分析涉及到流程实例的执行模型、流程部署的数据库交互、查询机制以及数据库操作的管理。理解这些核心概念对于深入学习和定制 Activiti 是至关重要的。通过源码阅读,我们可以更好地掌握 Activiti...

    activiti源码分析

    activiti源码分析

    activiti6.0.0源码,下载自github

    ** Activiti 6.0.0 源码分析:** 1. **引擎模块(Engine)**:这是核心组件,负责解析流程定义、启动流程实例、执行任务等。源码中,可以看到`org.activiti.engine`包下的实现。 2. **存储模块(Repository)**:...

    activiti源码+用户手册.zip

    源码分析可以帮助我们深入理解Activiti的工作原理,包括任务调度、流程实例的创建与管理、活动的执行、信号与事件的处理等。通过查看源码,我们可以学习如何自定义行为、扩展Activiti的功能,以及如何进行性能优化。...

    Activiti7.0源码官方完整版

    Activiti 的核心功能包括流程定义、执行、监控和分析,支持动态流程变更,同时提供了用户友好的工作流模型。 Activiti7.0 版本作为其最新的稳定版本,引入了诸多改进和新特性。例如: 1. **模块化设计**:Activiti...

    activiti权威指南

    关于原因,包括:Activiti源码分析过于复杂,书中追求全面而有深度;真实的企业级应用使用场景过于复杂以及不通用,抽取通用的代码以及降低读者的理解度;真实案例可能导致侵权,导致审查不通过;本书原定14章节,...

    activiti5.22.0源码

    这个源码包是Activiti 5.22.0版本,是该框架的一个稳定版本,提供了完整的流程定义、执行、监控和集成能力。下面我们将深入探讨Activiti的核心特性、工作原理以及如何在Java项目中应用。 一、Activiti概述 ...

    Activiti6.0.0最新源码

    Activiti6最大的变化点就是对代码进行了重构,该版本修复以往的Bug并不多,但内部实现相对来说变化比较大。其突出的变化如下所示: 新增两款新引擎,Form引擎和DMN引擎(动态引擎)。其中DMN引擎允许开发人员创建...

    Activiti源码

    源码分析通常涉及以下几个方面: 1. **项目结构**:通过`pom.xml`文件,我们可以了解到项目的Maven构建配置,包括依赖关系、模块划分等。Activiti可能被划分为多个子模块,每个模块负责特定的功能或组件。 2. **...

    activiti源码

    源码分析是理解其工作原理、进行定制开发或优化性能的关键。以下是对Activiti源码的详细解读。 1. **Activiti概述** Activiti 是基于Java的BPMN 2.0规范实现,提供了图形化的流程设计工具和丰富的API,使得业务...

    Activiti-7.0.45源码

    6. **工作流持久化**:Activiti使用数据库来持久化流程实例和任务状态,源码中的`HistoryService`展示了如何记录流程的历史信息,便于审计和分析。 7. **动态流程与API设计**:Activiti 7提供了丰富的RESTful API,...

    Activiti 5.22.0 源码,添加源码文件,可查看怎样实现

    Activiti 是一个开源的工作流引擎,它主要用于自动化业务流程,特别是在企业级应用中。这个5.22.0版本的源码提供了深入了解...此外,源码分析也有助于解决实际开发中遇到的问题,提升对流程引擎底层运作的洞察力。

    springboot集成activiti项目Demo源码分享

    通过阅读和分析这些代码,读者可以更直观地理解SpringBoot与Activiti的集成过程,以及如何在实际项目中应用Activiti来实现业务流程自动化。 总的来说,SpringBoot集成Activiti不仅简化了开发流程,而且提高了流程...

    activiti实战及示例源码

    9. **监控与优化**:介绍Activiti提供的监控工具和API,如历史数据查询,用于分析流程性能和瓶颈,进行流程优化。 10. **源代码实践**:附带的源代码可以帮助读者更好地理解和应用书中介绍的概念,这些代码涵盖了...

    activiti源码-最新-中文注释

    这个"activiti源码-最新-中文注释"的压缩包提供了Activiti的源代码,并且有中文注释,这对于理解和学习Activiti的内部工作原理非常有帮助。 首先,让我们深入了解Activiti的基本概念。Activiti 是基于模型驱动的,...

    Activiti Designer5.15.0源码

    理解Drools的原理和如何与Activiti交互也是分析源码的一部分。 9. **版本控制**:在"Activiti-Designer-master"这个目录名中,我们可以推测源码可能来自于Git仓库的master分支,这涉及到Git版本控制系统的知识。 ...

    Activiti工作流之流程实例、任务的执行

    **Activiti源码分析** 了解Activiti的工作原理,深入源码是必不可少的。Activiti的核心组件包括流程引擎(Engine)、流程定义(Deployment)、流程实例(ProcessInstance)和任务(Task)。源码阅读可以帮助开发者更...

Global site tag (gtag.js) - Google Analytics