深入流程解析部分源码学习,分析其设计思想
activiti的流程定义内容的承载方式是xml格式的文件,在部署流程的过程中必然涉及对文件的解析工作,activiti采取了流模型的方式进行解析,相对比DOM模型的几种解析方式,流模型具有这样几个优点:每次操作时只会将需要的节点放入内存中,从头开始读取一段,处理一段,避免了解析大文件时内存占用高、遍历查找慢等性能问题,activiti从设计层面屏蔽了xml文件大小由用户决定带来的不可控的风险。
在流模型中,可再细分为推模型与拉模型,activiti采取的是拉模型(STAX),流程文档解析时,客户端可以定制自己感兴趣的节点主动从读取器中拉取,选择性的处理节点事件,对比推模型这种事件驱动机制(每发现一个节点就会触发相应事件,客户端需要编写监听触发事件的监听程序),拉模型的灵活性大大提高。
activiti流程文档中定义的元素需要遵循BPMN2.0规范,它将所有流程定义元素抽象为三大类要素:
事件:流程的创建、流转、结束都需要事件支持,可以通过事件机制为工作流系统增加辅助功能。
网关:网关就是用来辅助决定流程实例最终流转的目的地,可以用来并行执行节点、也可以作为分支、聚合条件使用,常用的网关类型有排他网关、并行网关、包容网关。
活动:有生命周期的节点都称为“活动”,例如任务节点、子流程、引用流程等。
activiti对流程文档的解析可以归纳概括为三层:
元素定义层:主要指流程定义文档中的元素,由开发人员结合自己的业务场景进行组装使用,流程文档定义完成后可以直接交由元素解析层解析
元素解析层:负责定位流程文档、初始化元素解析器、加载自定义元素解析器、查找元素解析器,最终将需要的元素及属性解析,并封装为引擎中一个个的实体对象
基础支撑层:如数据库连接管理事务管理等公用组件,为上层元素解析层提供基础服务支撑
activiti在解析代码设计上还尽可能的遵循了开闭原则,它为每个元素定义了一个对应的元素解析器,一个元素解析器只负责一个元素类型的解析,每个元素解析器之间相互独立运行,避免了修改时的相互级联的影响。在此基础之上,activiti对系统进行抽象提取,它在系统中定义了一个通用的模板方法,将不同的实现行为转移到具体的实现层中完成,这样在扩展类行为的时候只需要修改具体的实现层代码即可,更直观的看其实就是面向接口编程。