activiti源码与流程活动自动与手工触发执行例子

《activiti源码与流程活动自动与手工触发执行例子》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、Activiti源码分析Activiti的基础编程框架Activiti基于Spring，ibatis等开源中间件作为软件平台，在此之上构建了非常清晰的开发框架。上图列出了Activiti的核心组件。1.ProcessEngine：流程引擎的抽象，对于开发者来说，它是我们使用Activiti的facade，通过它可以获得我们需要的一切服务。2.XXService（TaskService,RuntimeService,RepositoryService...):Activiti按照流程的生命周期（定义，部署，运行）把不同阶段的服务封装在不同的Service中，用户可以非常清晰

2、地使用特定阶段的接口。通过ProcessEngine能够获得这些Service实例。TaskService,RuntimeService,RepositoryService是非常重要的三个Service：TaskService：流程运行过程中，与每个任务节点相关的接口，比如complete,delete,delegate等等RepositoryService:流程定义和部署相关的存储服务。RuntimeService：流程运行时相关服务，如startProcessInstanceByKey. 关于ProcessEngine和XXService的关系，可以看下面这张图：  

3、3.CommandContextIntercepter(CommandExecutor):Activiti使用命令模式作为基础开发模式，上面Service中定义的各个方法都对应相应的命令对象（xxCmd),Service把各种请求委托给xxCmd，xxCmd来决定命令的接收者，接收者执行后返回结果。而CommandContextIntercepter顾名思义，它是一个拦截器，拦截所有命令，在命令执行前后执行一些公共性操作。比如CommandContextIntercepter的核心方法： Java代码  1.  public  T execute(Command

4、> command) {  2.    CommandContext context = commandContextFactory.createCommandContext(command);  1.  2.    try {  3.//执行前保存上下文  4.      Context.setCommandContext(context);  5.      Context.setProcessEngineConfiguration(processEngineConfiguration);  6.      return next.execute(command);/

5、/执行命令  7.        8.    } catch (Exception e) {  9.      context.exception(e);  10.        11.    } finally {  12.      try {  13.//关闭上下文，内部会flush session，把数据持久化到db等  14.        context.close();  15.      } finally {  16.//释放上下文  17.        Context.removeCommandContext();  18.        Conte

6、xt.removeProcessEngineConfiguration();  19.      }  20.    }  21.      22.    return null;  23.  }   关于命令模式的细节说明，网上有很多资料，这里不展开。我只是想说一下我看到Activiti的这种设计之后的两点感受：1）一个产品或者一个项目，从技术上必须有一个明确的、唯一的开发模型或者叫开发样式（真不知道怎么说恰当），我们常说希望一个团队的所有人写出的代码都有统一的风格，都像是一个人写出来的，很理想化，但做到很难，往往我们都是通过“规范”去约束大家这样做，而规范毕竟是程序之

7、外的东西，主观性很强，不遵守规范的情况屡屡发生。而如果架构师给出了明确的开发模型，并使用一些基础组件加以强化，把程序员要走的路规定清楚，那你想不遵守规范都会很难，因为那意味着你写的东西没发工作。就像Activiti做的这样，明确以Command作为基本开发模型，辅之以Event-Listener，这样编程风格的整体性得到了保证。2）使用命令模式的好处，我这里体会最深的就是职责分离，解耦。有了Command，各个Service从角色上说只是一些协调者或者控制者，他不需要知道具体怎么做，他只是把任务交给了各个命令。直接的好处是臃肿