Activiti源码——子流程

一方面学习activiti工作流中子流程的概念、设计及具体实现，思考子流程的应用场景并探讨分析部分问题，另一方面对前一阶段activiti的学习做一个思考总结。

对子流程的学习及思考：

子流程可以简单的当作普通流程来看，当一个普通流程与另一个普通流程存在关联关系或者依赖关系时，那么这两个普通流程就可以互称为父子流程，一般情况下由父流程调用或触发子流程。
子流程作为一个独立的流程，它包含一系列紧密相关的业务活动环节，可以被多个不同的父流程调用，这种场景下子流程作为一种资源被复用了，可以大大减少重复的流程建模，这是它的一大优点。

那么思考一个问题：如果子流程是某一个父流程特有的业务，其它流程没有这样的业务场景，或者子流程的业务是一个机密，为防止泄密所以不希望这个子流程具备被其它流程复用的能力，该如何实现？
在这样的需求下，可以考虑将子流程设计成父流程内嵌的子流程，所谓内嵌就是子流程的定义不是独立的，而是被包含在某一个父流程定义的内部的，在部署的时候子流程不会独立部署，而是只会部署父流程，子流程只是父流程内部结构的一部分。这种内嵌子流程的设计类似于java中的内部类，但实质上是对子流程的访问权限进行了控制。所以从访问权限这个角度来看，子流程可以划分为可复用的调用子流程和父流程私有的内嵌子流程，他们解决的是不同场景下的问题。

另一个值得探讨的问题是：父子流程之间的通信
父子流程因为有了关联关系，所以一定可以互相通信，因为可以通信，父子流程的运行结果可以产生相互影响，这些影响是多种多样且复杂的，对应的就可以挖掘出多种多样且复杂的业务需求。比如父流程在触发子流程后是否可以继续流转？如果可以，是否需要符合某种条件（这个条件可以是特定的时间、特定的环节或者某个特定的业务参数表达式）？这些问题其实体现的是父子流程之间的同步异步特性及触发条件。再比如父流程在执行过程中触发几次子流程？是默认固定的次数还是需要根据业务在运行时动态的判断与决定？触发的每个子流程的状态对父流程的流转有什么样的影响？这些问题反应的是父子流程之间的数量关系。

对activiti的思考总结：

对于activiti的学习，起初从官方文档及api使用入手，后续结合《activiti权威指南》一书，深入源码学习了解其技术层面的设计实现，再进一步梳理其业务模型归纳其业务对象以及业务对象间的关系、行为，最后通过数据库表的设计分析思考并验证它能够支撑的业务需求、不能支撑的业务需求以及如何扩展来支撑activiti自身原本不支持的业务需求。技术框架层面，activiti有很多优秀的设计，比如它分离了运行时数据与历史数据以提高运行时的程序执行效率，提供了分布式环境下全局唯一ID的解决方案，运用了大量的设计模式使得代码可读性、可扩展性非常高等等；但是它的业务模型中的核心业务对象并不多，与流程流转相关的最关键的其实只有两个：执行实例、任务实例，其它的诸如变量、活动、表单等等承担的只是辅助流程流转的作用。对执行实例对象深入的理解后发现，执行实例包含了流程实例的内涵，因为最顶层的执行实例就是流程实例，同时执行实例对象还充当了一个运行上下文的角色。任务实例承担了具体的工作内容，比如任务实例可以承担业务表单填写工作，也可以承担脚本执行工作、服务调用工作、邮件发送工作等等。