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

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从角色上说只是一些协调者或者控制者，他不需要知道具体怎么做，他只是把任务交给了各个命令。直接的好处是臃肿的、万能的大类没有了。而这往往是我们平时开发中最深恶痛绝的地方。??4.核心业务对象（Task，ProcessInstance，Exe