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

 HYPERLINK /blog/1338553 Activiti源码分析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代码?? ??public?T?T?execute(CommandT?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从角色上说只是一些协调者或者控制者，他不需要知道具体怎么做，他只是把任务交给了各个命令。直接的