Activiti源码——文档解析

深入流程解析部分源码学习，分析其设计思想

activiti的流程定义内容的承载方式是xml格式的文件，在部署流程的过程中必然涉及对文件的解析工作，activiti采取了流模型的方式进行解析，相对比DOM模型的几种解析方式，流模型具有这样几个优点:每次操作时只会将需要的节点放入内存中，从头开始读取一段，处理一段，避免了解析大文件时内存占用高、遍历查找慢等性能问题，activiti从设计层面屏蔽了xml文件大小由用户决定带来的不可控的风险。
在流模型中，可再细分为推模型与拉模型，activiti采取的是拉模型（STAX），流程文档解析时，客户端可以定制自己感兴趣的节点主动从读取器中拉取，选择性的处理节点事件，对比推模型这种事件驱动机制（每发现一个节点就会触发相应事件，客户端需要编写监听触发事件的监听程序），拉模型的灵活性大大提高。

activiti流程文档中定义的元素需要遵循BPMN2.0规范，它将所有流程定义元素抽象为三大类要素：
事件：流程的创建、流转、结束都需要事件支持，可以通过事件机制为工作流系统增加辅助功能。
网关：网关就是用来辅助决定流程实例最终流转的目的地，可以用来并行执行节点、也可以作为分支、聚合条件使用，常用的网关类型有排他网关、并行网关、包容网关。
活动：有生命周期的节点都称为“活动”，例如任务节点、子流程、引用流程等。

activiti对流程文档的解析可以归纳概括为三层：
元素定义层：主要指流程定义文档中的元素，由开发人员结合自己的业务场景进行组装使用，流程文档定义完成后可以直接交由元素解析层解析
元素解析层：负责定位流程文档、初始化元素解析器、加载自定义元素解析器、查找元素解析器，最终将需要的元素及属性解析，并封装为引擎中一个个的实体对象
基础支撑层：如数据库连接管理事务管理等公用组件，为上层元素解析层提供基础服务支撑

activiti在解析代码设计上还尽可能的遵循了开闭原则，它为每个元素定义了一个对应的元素解析器，一个元素解析器只负责一个元素类型的解析，每个元素解析器之间相互独立运行，避免了修改时的相互级联的影响。在此基础之上，activiti对系统进行抽象提取，它在系统中定义了一个通用的模板方法，将不同的实现行为转移到具体的实现层中完成，这样在扩展类行为的时候只需要修改具体的实现层代码即可，更直观的看其实就是面向接口编程。