2023年8月1日发(作者：)
.
1. Activiti的基础编程框架
Activiti基于Spring，ibatis等开源中间件作为软件平台，在此之上构建了非常清晰的开发框架。上图列出了Activiti的核心组件。
2. Activiti的核心设计模型
Facade外观模式：ProcessEngine啊，RepostoryService啊，都是外观接口。作为二次开发人员，可以把引擎内部看做黑盒，不关心内部的具体实现，直接调用这些暴露出来api接口完成对应的功能。
Command命令模式：所有api接口的功能，在引擎的实现类中，都封装成了Command命令，再交给统一的CommandExecutor执行。使用Command命令模式的好处时，所有功能都通过统一入口进入，所以可以统一管理，为后续的Interceptor拦截器模式的应用做好了准备。
Interceptor拦截器模式：流程引擎提供了多种拦截器，通过这些拦截器可以实现“准备上下文环境”，“事务控制”，“乐观锁自动重试”等功能。
Session 工程模式：这个很好理解，activiti中通过SessionFactory接口实现类去管理各种session的实现者。
. .
3. 主要类介绍：
ProcessEngine：流程引擎的抽象，对于开发者来说，它是我们使用Activiti的facade，通过它可以获得我们需要的一切服务。
XXService（TaskService,):Activiti按照流程的生命周期（定义，部署，运行）把不同阶段的服务封装在不同的Service中，用户可以非常清晰地使用特定阶段的接口。通过ProcessEngine能够获得这些Service实例。TaskService,RuntimeService,RepositoryService是非常重要的三个Service：
TaskService：流程运行过程中，与每个任务节点相关的接口，比如complete,delete,delegate等等
RepositoryService:流程定义和部署相关的存储服务。
RuntimeService：流程运行时相关服务，如startProcessInstanceByKey.
关于ProcessEngine和XXService的关系，可以看下面这张图：
CommandContextIntercepter(CommandExecutor):通过CommandExecutor启动CommandContextIntercepter责任链，Activiti使用命令模式作为基础开发模式，上面Service中定义的各个方法都对应相应的命令对象（xxCmd), Service把各种请求委托给. .
xxCmd，xxCmd来决定命令的接收者，接收者执行后返回结果。而CommandContextIntercepter顾名思义，它是一个拦截器，拦截所有命令，在命令执行前后执行一些公共性操作。比如CommandContextIntercepter的核心方法：
Java代码
1.
2.
3.
4.
5.
6.
7.
8.
9.
public
CommandContext context = CommandContext(command);
try {
//执行前保存上下文
mandContext(context);
cessEngineConfiguration(processEngineConfiguration);
return e(command);//执行命令
10. } catch (Exception e) {
11. ion(e);
12.
13. } finally {
14. try {
15. //关闭上下文，内部会flush session，把数据持久化到db等
16. ();
17. } finally {
18. //释放上下文
19. CommandContext();
20. ProcessEngineConfiguration();
21. }
22. }
23.
24. return null;
25. }
4. Activiti的上下文（Context）
上下文（Context）用来保存生命周期很长的、全局性的信息。Activiti的Context类（在t包下）保持如下三类信息：
. .
CommandContext：命令上下文，保持每个命令需要的必要资源，如持久化需要的session。
ProcessEngineConfigurationImpl：流程引擎相关的配置信息。它是整个引擎的全局配置信息，mailServerHost，DataSource等。单例。该实例在流程引擎创建时被实例化，其调用stack如下图：
（图4：ProcessEngineConfiguration的初始化）
ExecutionContext：刚看到这个类感觉有些奇怪，不明白其作用是什么。看其代码持有ExecutionEntity这个实例。而ExecutionEntity是Activiti中非常重要的一个类，//TODO
5. Activiti的持久化框架（组件）
Activiti使用ibatis作为ORMapping工具。在此基础之上Activiti设计了自己的持久化框架，看一张图：
. .
（图5：Activiti持久化框架）
顶层接口是Session和SessionFactory，这都非常好理解了。
Session有两个实现类：
DbSqlSession：简单点说，DbSqlSession负责sql表达式的执行。
AbstractManager:简单点说，AbstractManager及其子类负责面向对象的持久化操作
同理DbSqlSessionFactory与GenericManagerFactory的区别就很好理解了。
持久化框架也是在流程引擎建立时初始化的，具体见图4.
6. Event-Listener 组件
Activiti允许客户端代码介入流程的执行。为此提供了一个基础组件，看图：
（图6：用户代码介入流程的基础组件）
用户可以介入的代码类型包括：TaskListener，JavaDelegate，Expression，ExecutionListener。
ProcessEngineConfigurationImpl持有DelegateInterceptor的某个实例，这样就可以随时非常方便地调用handleInvocation
7. Cache 组件
对Activiti的cache实现很感兴趣，但现在我了解到的情况（也许还没有了解清楚）其cache的实现还是很简单的，在DbSqlSession中有cache实现：
Java代码
1. protected List
. .
2. protected Map
3. protected List
4. protected List
也就是说Activiti就是基于内存的List和Map来做缓存的。具体怎么用的呢？以One方法为例：
Java代码
1. public Object selectOne(String statement, Object parameter) {
2. statement = tement(statement);
3. Object result = One(statement, parameter);
4. if (result instanceof PersistentObject) {
5. PersistentObject loadedObject = (PersistentObject) result;
6. 缓存处理
7. result = cacheFilter(loadedObject);
8. }
9. return result;
10. }
Java代码
1. protected PersistentObject cacheFilter(PersistentObject persistentObject) {
2. PersistentObject cachedPersistentObject = cacheGet(ss(), ());
3. if (cachedPersistentObject!=null) {
4. //如果缓存中有就直接返回
5. return cachedPersistentObject;
6. }
7. //否则，就先放入缓存
8. cachePut(persistentObject, true);
9. return persistentObject;
10. }
Java代码
1. protected CachedObject cachePut(PersistentObject persistentObject, boolean storeState) {
. .
2. Map
3. if (classCache==null) {
4. classCache = new HashMap
5. (ss(), classCache);
6. }
7. //这里是关键：一个CachedObject包含被缓存的对象本身：persistentObject和缓存的状态：storeState
8. //Activiti正是根据storeState来判别缓存中的数据是否被更新是否与db保持一致的。
9. CachedObject cachedObject = new CachedObject(persistentObject, storeState);
10. ((), cachedObject);
11. return cachedObject;
12. }
看了Activiti的缓存设计，我现在最大的疑问是Activiti貌似不支持cluster，因为其缓存设计是基于单机内存的，这个问题还需要进一步调查。
8. 异步执行组件
Activiti可以异步执行job（具体例子可以看一下ProcessInstance
startProcessInstanceByKey(String processDefinitionKey);），下面简单分析一下其实现过程，还是先看图：
（图7：异步执行组件核心类）
JobExecutor是异步执行组件的核心类，其包含三个主要属性：
1）JobAcquisitionThread jobAccquisitionThread:执行任务的线程 extends
2)BlockingQueue
. .
3)ThreadPoolExecutor threadPoolExecutor:线程池
方法ProcessEngines在引擎启动时调用，JobAcquisitionThread 线程即开始工作，其run方法不断循环执行AcquiredJobs中的job，执行一次后线程等待一定时间直到超时或者Added方法因为有新任务而被调用。
这里发现有一处设计的不够好：JobAcquisitionThread 与JobExecutor之间的关系是如此紧密（你中有我，我中有你），那么可以把JobAcquisitionThread 作为JobExecutor的内部类来实现，同时把ThreadPoolExecutor threadPoolExecutor交给JobAcquisitionThread
来管理，JobExecutor只负责接受任务以及启动、停止等更高级的工作，具体细节委托给JobAcquisitionThread ，责任分解，便于维护，JobExecutor的代码也会看起来更清晰。
9. PVM
PVM:Process Virtal Machine,流程虚拟机API暴露了流程虚拟机的POJO核心，流程虚拟机API描述了一个工作流流程必备的组件，这些组件包括：
PvmProcessDefinition：流程的定义，形象点说就是用户画的那个图。静态含义。
PvmProcessInstance：流程实例，用户发起的某个PvmProcessDefinition的一个实例，动态含义。
PvmActivity：流程中的一个节点
PvmTransition：衔接各个节点之间的路径，形象点说就是图中各个节点之间的连接线。
PvmEvent：流程执行过程中触发的事件
以上这些组件很好地对一个流程进行了建模和抽象。每个组件都有很清晰的角色和职责划分。另外，有了这些API，我们可以通过编程的方式，用代码来“画”一个流程图并让他run起来，例如：
Java代码
1.
2.
3.
4.
5.
6.
7.
8.
9.
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();
();
10. PvmExecution activityInstance = ecution("a");
. .
11. assertNotNull(activityInstance);
12. (null, null);
13. activityInstance = ecution("b");
14. assertNotNull(activityInstance);
15. (null, null);
16. activityInstance = ecution("c");
17. assertNotNull(activityInstance);
以上代码都很简单，很好理解，只有一点需要说明一下，粗体红色背景的behavior方法，为一个PvmActivity增加ActivityBehavior，这是干什么呢？ActivityBehavior是一个interface,其接口声明很简单：
Java代码
1.
2.
3.
4.
5.
6.
7.
/**
* @author Tom Baeyens
*/
public interface ActivityBehavior {
void execute(ActivityExecution execution) throws Exception;
}
我的理解：Activiti把完成一个PvmActivity的行为单独建模封装在ActivityBehavior中。execute方法只有一个参数ActivityExecution，为啥这么设计？
为了更好地理解ActivityBehavior的作用，我们以te方法为例,分析其执行过程，先看complete的代码：
Java代码
1.
2.
3.
4.
5.
6.
7.
8.
9.
ublic void complete() {
fireEvent(AME_COMPLETE);
Context
.getCommandContext()
.getTaskManager()
.deleteTask(this, _REASON_COMPLETED, false);
if (executionId!=null) {
10. getExecution().signal(null, null);
11. }
12. }
. .
代码很简单，也很好理解（可能出乎我们的意料，因为完成一个task，其实有很多事情要做的）：
ent：通知Listener，本任务完成了。
2.数据持久化相关的动作
cution().signal(null, null)：发信号，这里面隐藏的东西就多了，总体来说，完成了当前任务流程怎么走，怎么生成新的任务都是在这里完成的。
进去看看：
Java代码
1.
2.
3.
4.
5.
6.
7.
8.
9.
public void signal(String signalName, Object signalData) {
ensureActivityInitialized();
SignallableActivityBehavior activityBehavior = (SignallableActivityBehavior) ivityBehavior();
try {
(this, signalName, signalData);
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
throw new PvmException("couldn't process signal '"+signalName+"' on activity '"+()+"': "+sage(), e);
10. }
11. }
方法核心工作就是把发信号的工作委托给PvmActivity的activityBehavior. 这里的设计存在问题，很显然其触犯了一个代码的坏味道：消息链。它让ExceutionEntity没有必要地与SignallableActivityBehavior 产生了耦合，更好的做法应该是PvmActivity提供signal方法，其内部调用ActivityBehavior完成发信号工作。
其实看看PvmActivity的接口声明，我不免也有疑问，本来属于PvmActivity的很重要的职责在其接口声明中都没有体现，why？？
1.
2.
3.
4.
5.
6.
7.
.
/**
* @author Tom Baeyens
*/
public interface PvmActivity extends PvmScope {
boolean isAsync();
.
8.
9.
PvmScope getParent();
10. List
11.
12. List
13.
14. PvmTransition findOutgoingTransition(String transitionId);
.
发布者：admin，转转请注明出处：http://www.yc00.com/news/1690874500a452281.html
评论列表（0条）