关于Tesla工作流引擎和服务编排引擎的技术选型
工作流引擎和服务编排引擎是 Tesla 1.2 时代就有的组件，生产上也运行了两年多了，时间有点久远，只能简单的说明一下它们的选型过程。
关于工作流的选型
市面上比较广泛使用的是jBPM和Activiti，其它的产品很小众就不考虑了，jBPM我们也调研过，当时已经被jBoss收购，整合了很多jBoss的产品在里面，同时API感觉也比较复杂，整体上感觉比较重，当时jBMP的创始人因为对产品的发展方向与公司产生分歧也离开了jBoss创立了Activiti。
Activiti项目是由jBMP的创始人Tom Baeyens离开jBoss这后创立，完全从jBPM 4源码建立起来，有良好的群众基础；
Activiti社区非常活跃，每三个月会发布一个Release版本；
Activiti流程设计遵循BPMN 2.0标准；
Activiti提供基于eclipse plugin的流程设计器、基于Web的流程设计器、流程管理控制台（监控、管理）；
Activiti基于Spring、myBatis，每个模块都提供接口和扩展机制、具有良好的扩展性，与Tesla的技术栈统一可以进行无缝整合；
Activiti具有良好的性能和稳定性，参见性能测试报告:Tesla Confluencen主页->用户指南->性能测试报告
关于服务编排流程引擎的选型
调研过Activiti、ODE、Mule、Camel等产品，还调研过一些国外的商业产品，收费很贵，也不是我们自研的目的，忽略。
Mule、Camel等产品是面象集成的ESB，有非常灵活而简单配置的协议转换和发布功能，分阶段事件驱动的架构（SEDA）有良好的吞吐量，也有较简单的流程编排功能，缺乏分布式事务处理支持，同时产品本生很重；
ODE，遵循WS-BPEL，看起来是当时最符合后新核心时代SOA架构对流程编排的需求的产品了，但也缺乏分布式事务处理支持；
Activiti，遵循BPMN2.0，有compensation的定义，可用于分布式事务的补偿定义，但Activiti是工作流引擎，每一个步骤须要记大量的数据库操作，性能能达不到要求（作为服务编排流程引擎性能不达标并不意味着作为工作流引擎性能就不达标）。
另外ServiceMix当是我们并没有调研，网上有篇文章说是要被Camel代替了。
综上所述，市面上并没有一个开源的能够很好得支持分布式事务的服务编排框架。当时Tesla已经引入Dubbo并扩展了行内绝大部分的服务协议，协议转换不是我们的强需求。服务编排也不应该管协议转换的事。本着单一职责、轻量、自主掌控的原则，所以决定自己写一个服务编排流程引擎。
流程引擎核心的机制其实是就是状态机，所以我们参考了Activiti的核心PVM（流程虚拟机）。流程虚拟机抽象了流程流转所需的最基本的概念：“流程定义”、“流程实例”、“活动”、“迁移”，然后抽象了一个活动迁移到另一个活动的运行框架和行为扩展机制。而流程具体做什么事则是在“活动”或者“迁移”上扩展“行为”即可。
所以Tesla的服务编排框架是两层，PVM（流程虚拟机）、 遵循BPMN2.0规范的“行为”集。