jBPM 与项目的适用性探讨

jBPM 与项目的适用性探讨

转载请保留作者信息：
作者：88250
Blog：http:/blog.csdn.net/DL88250
MSN & Gmail & QQ：DL88250@gmail.com

这次讨论一下 jBPM（为简洁起见，如无特殊说明，jBPM 专指 jBPM 3） 在 BeyondTrack 项目中的的适用性问题，由此也引申了一些关于工作流引擎选用上的问题....

 

一. 当初选择 jBPM 的原因

• 由于 BeyondTrack 项目比较特殊，需要一个很灵活的工作流引擎作底层支撑，让用户可以在运行时部署、修改、定制流程、活动及其任务。jBPM 提供的 variables 机制加上强大的 Hibernate ORM 正好满足项目需要。
• jBPM 是个开源（LGPL）的工作流引擎，业界口碑好。开源，意味着可以从它的代码中学习到很多知识，在必要的时候还可以修改其代码完成以满足应用开发需要。
  
  

二. 现在抛弃 jBPM 的原因

• jBPM 的 API 设计不是很合理，把底层实现暴露了出来，最典型的例子就是关于 Token 的设计。Token 是 jBPM 中最为重要的概念之一，但其也是 jBPM 最重要的底层 APIs 之一。把这个概念暴露给用户只会加大用户开发的复杂度，当用户的业务逻辑复杂度较高时，使用 Token 来控制流程的执行其开发代价是不菲的。我认为，最根本的原因就是 jBPM 设计时没有足够考虑到接口抽象层次的同一性。
• jBPM 的性能也是很重要的一个问题。这个也是一个设计上的问题，jBPM 在很多类的设计上存在‘重复’的问题，这导致了映射出了数据库表字段有冗余，要在对象模型中获取某些对象时底层数据库访问过多。数据量一旦上来了，问题显而易见。
• jBPM 是个开源产品。当初选择它，是因为它开源；现在抛弃它，也是同一个原因。并不是因为 License 问题，而是因为开源产品变动可能很大。设计变动、项目活跃度变动，等等因素。前不久，jBPM 4 alpha1 刚刚发布。jBPM 4 已经完全重写了，原先的模型完全抛弃了，带来的是 PVM（流程虚拟机），以及一系列新的服务 APIs。从带的 examples 上看，jBPM 4 的设计已经很不错了，但是，BeyondTrack 是否真的需要 PVM，甚至是否需要一个基本的工作流引擎？

 

三. 选用工作流引擎前“必须”的考虑

1. 项目应用是典型的“工作流”形式的吗？

    所谓的典型的“工作流”形式的应用一般包括了如下特征：需要控制业务流程执行；需要管理业务流程任务的分派；存在并发任务、流程间跳转、锁定 / 恢复等。这个具体可以参考《工作流参考模式》。

2. 项目开发的复杂度

    这里通常有两种情况：

    a. 项目规模较大，领域对象关系复杂，要实现的基本的、大部分的业务流程就很复杂

    b. 项目规模较小，领域对象关系简单，基本的、大部分的业务流程比较简单，但少部分业务逻辑复杂度较高

    我认为，情况 b 是典型的可以考虑使用现成工作流引擎的情况。选择工作流引擎不像选择应用框架，因为应用往往只是简单地、单向地去依赖框架，而应用与工作流引擎之间的依赖是密切的、双向的，而且是很复杂的。即使工作流引擎提供了设计优秀的扩展机制与用户接口，其开发复杂度也是不能忽视的，最大的问题是项目应用中的领域对象与工作流引擎领域对象之间的转换。追根寻底，这个矛盾是业务流程逻辑与其逻辑计算所需要的精确控制很难做到分离。所以，情况 b 我认为基于工作流引擎去做可以比较顺利地完成。

3. 项目应用的灵活程度

    更确切地说是应用中用户自定制的灵活度。这个问题其实是最根本的问题。其实，在任何项目中，应用灵活度与开发复杂度是永恒对立的。要提供最够的灵活度，其开发复杂度不是一般。最大的难点是应用需要的灵活度所带来的开发复杂度与所选择的工作流引擎提供的扩展机制间的选择与权衡。

四. BeyondTrack 在“工作流”实现上的调整

1. “工作流”应该修正为“软件过程”

    BeyondTrack 的目标是一个以项目管理为核心，提供团队协作的平台 。所以，从软件过程的角度来定义这部分内容更为合适也更为专业。这里可以参考 ISO/IEC 12207（Software Life Cycle Processes） 来定义这部分在整个项目中的位置，并且以后要不断进行调整。

2. 具体实施方案

    BeyondTrack 前期一直使用的是 jBPM，其分为了底层数据结构、定义模型与执行模型三个大的逻辑部分。而 BT（BeyondTrack） 也一直都是设计了定义模型与执行模型，然后保持 BT 与 jBPM 定义模型与执行模型间的同步。现决定将执行部分与底层数据结构在项目中实现，在项目中实现一个 Process Engine，基于 Petri nets 理论。在标准化进程中的 ISO/IEC 15090（Software and System Engineering —
High-level Petri nets）可以提供一些参考（这个规范好像停工了- -!）。