揭秘jbpm流程引擎内核设计思想及构架.docx

167 浏览量 2022-10-13 16:22:52 上传评论收藏 318KB DOCX 举报

资源推荐

资源详情

资源评论

揭秘 jbpm 流程引擎内核设计思想及构架

------作者胡长城

前言

流程引擎内核仅是“满足 Process 基本运行”的最微小结构，而整个引擎则要复杂很多，包括“状态存储”、“事件处理”、“组织

适配”、“时间调度”、“消息服务”等等外围的服务性功能。引擎内核，仅包含最基本的对象和服务，以及用于解决流程运行问题的调

度机制和执行机制。

如果，你掌握了一个流程引擎的灵魂，你才有能力理解它的全部。否则，一个引擎对你来说，可能只是一个复杂的结构，丰富多

彩 API、令人眼花缭乱的“功能”和“服务”而已。

本身工作流这个领域就是一个很“狭窄”的领域，国内的厂商也不是很多，其中有部分实现技术并不弱。但可能涉于安全等因素，

并没有多少技术人员探讨“深度的工作流技术实现问题”。而广大的开发爱好者却还在花费大量的时间在摸索“如何理解工作流、如何

应用工作流”。所以在此之前，国内尚未有一篇技术文章探讨工作流引擎内核的实现，当然也没有探讨 jBpm 引擎内核的文章了。在

www.javaeye.com 技术站点和我的 blog（http://blog.csdn.net/james999）上有几篇专门探讨 jbpm 应用的文章，对于初步想了解如

何使用 jbpm 的读者来说，值得看看。

对于这方面的技术分享，开源是个不错的突破口。

本篇就是以 jBpm 为实例，来诠释工作流引擎的内核设计思路和结构。但是这仅仅是从 jBpm 的实现角度来辅助大家理解，因为工

作流引擎内核的设计、实现是有很多方式：这会因所选的模型、调度算法、推进机制、状态变迁机制、执行机制等多方面的不一样，

而会差别很大。比如基于 Activity Diagram 模型的 jBpm 和基于 FSM 模型的 OSWorkflow 引擎内核之间就有很大的差别。

相比较而言，jBpm 的模型比较复杂，而引擎内核实现的比较“精简”，非常便于大家“由浅入深的理解”。

2.1 概念的基础

本文的读者群主要是面向有一定工作流基本概念的开发人员。所以本文认为你已经具备了如下基本工作流知识：

（1）初步了解工作流系统结构。比如理解工作流引擎在工作流系统中所处的位置和作用

（2）对流程定义（Process Definition）和流程实例（Process Instance）相关对象有所了解。比如理解 Process Instance 代表什么，

工作项（WorkItem）代表什么。

2.2 环境的基础

在阅读本篇的时候，如果你已经搭建了一套 jbpm 的开发环境，那么将有助于你更容易理解本篇的很多内容，也便于实际体验代码。

从 www.jbpm.org 官方网站下载 jbpm-starters-kit 开发包，按照其参考手册，可以很容易在 eclipse 开发环境中建立项目，效果图类

似如下：

决一个过程运行问题，按秩序的从一个节点到另一个节点的执行”。——这就是引擎内核所关注的根本问题。

上面这句话，估计会引起很多人“拍砖”。在很多人看来，工作流之所以看起来很“难”，就是因为这些复杂多变的“业务性问题”

都统统绑在一个“引擎”上造成的。

其实，这是两个“维度”的问题，也就是“引擎的抽象”和“引擎的应用”这两个不同维度，不同层面的问题。但这绝不是两个

独立的问题，“引擎的抽象”的好与坏，直接影响到“引擎的应用”的可复杂度和可支持度，当然我们也不能否认，“引擎的应用”问

题也是一个很复杂的问题。但本文是站在“引擎的抽象”这个维度来阐述问题的。对于“引擎的应用”问题，可参考我的前作：2003

年 11 月份的《工作流模型分析》、2003 年 12 月份的《工作流授权控制模型》、2004 年 7 月份的《工作流系统中组织模型应用解决方

案》。

也就是说，本文不是指导大家如何去“使用 jbpm”，而是阐述“jbpm 的引擎的内核部分是如何构建的”。但本文的主旨不是告诉大

家“jBpm 是如何设计引擎内核的”，而是以 jBpm 为例，来介绍“引擎内核”。

4 擎内核所关注的四个主要问题

引擎内核所关注的是一个非常“抽象”层面的问题，而不同引擎关注的“一套完整的执行环境”。或者我们可以这么来说，引擎内

核的职责是非常“精简”的：确保流程按照既有的定义，从一个节点运行到另一个节点，并正确执行当前节点。

总的来说，引擎内核主要关注四个方面的问题：

（1）流程定义问题：不是说如何图形化的定义流程，而是如何用一套定义对象，来诠释所定义的流程。

（2）流程调度问题：提供什么的机制，可以确保流程能够处理复杂的“流程图结构”，诸如串行、并行、分支、聚合等等，并在这复

杂结构中确保流程从一个节点运行到另一个节点。

（3）流程执行问题：当流程运行到某个节点的时候，需要一套机制来解决：是否执行此节点，并如何执行此节点的问题，并维持节点

状态生命周期。

（4）流程实例对象：需要一整套流程实例对象来描述流程实例运行的状态和结果。

4.1 模型与定义对象

工作流引擎本身就是一种“base on model”的组件，流程实例的执行都是依赖于所定义的“流程定义”，而工作流引擎则是提供

了这样一种环境，来维持流程实例的运行。

所以引擎内核，必须提供一套定义对象来描述“流程定义”，并且这些定义对象必须反映出一种“模型”。

比如 jBpm 的定义对象，是与其所基于的 Activity Diagram 模型相对应的。

4.2 调度机制与算法

引擎内核的另一个重要功能，就是保证流程实例准确的从一个节点运行到另一个节点，而这则需要依赖于一套调度机制。

引擎的调度机制有很多种实现方法，有的甚至是与“所依赖的模型有关”。但普遍来讲，很多引擎都受到 Petri Net 的影响，而采

用 token 来调度。

jBpm 本身就吸纳的 token 这套机制，当然，与 Petri Net 的调度机制还是有所区别。我们将在下面的章节详细介绍。

4.3 执行机制与状态

经过引擎的调度，实例运行到某个节点了，此时必须必须提供一套机制，来判断当前节点是否可执行，如果可执行，那么需要提

供一套 runtime envrioment 来执行节点——这就是引擎的执行机制。

复杂的流程引擎会依赖于“流程实例状态”或“活动实例状态”的约束和变迁来进行处理。之所有有时候我们会把一个流程引擎

也叫做“状态机”，很大程度上也是这个原因。

4.4 实例对象与执行环境

每个一个流程实例，必须维护一套属于自己的“运行环境和数据”，而这则是实例对象的责任了。基本上实例对象会包含如下信息：

（1）与流程实例的状态或控制信息

（2）与活动实例的状态或控制信息。如果某些引擎不支持活动实例，那么必然会有某些其他实例信息，可以当前节点的状或控制信息。

（3）一些临时的“执行”信息，便于引擎针对某种情况进行处 jbpm，“精简”的开源流程引擎.

好的开源工作流引擎不多，jbpm 和 osworkflow 算是其中两个有特色而且比较容易实际应用的。目前一些国内的中小型流程应用

项目，就是在 jbpm 或 osworkflow 的基础上扩展实现。jBpm 采用了 Activity Diagram 的模型，而 osworkflow 则是 FSM 的模型。

当然，这仅仅是 jbpm3 之后的事情。自从被 Jboss 收购之后，jbpm 对早先的 2.0 构架进行了重组，整个结构完全本着“微内核”

的思想进行设计。

现在这里从技术角度来分析 jbpm3 的优点，简单罗列几个大家都容易看见的：

（1）jbpm 的模型是采用 UML Activity Diagram 的语义，所以便于开发人员理解流程。

（2）jbpm 提供了可扩展的 Event-Action 机制，来辅助活动的扩展处理。

（3）jbpm 提供了灵活的条件表达式机制，来辅助条件解析、脚本计算的处理。

（4）jbpm 提供了可扩展的 Task 及分配机制，来满足复杂人工活动的处理。

（5）借助 hibernate 的 ORM 的优势，jbpm 能够很容易支持多种数据库。

当然，还有一些优点，是很多开发人员并不太注意的，比如：

（1）jbpm 的 Node 机制非常灵活，开发人员可以很容易定制“业务化语义的节点”，并满足运行时候处理的需要。

有很多灵活的优点，当然也少不了存在一些“局限”。

（1）很显然，只能有一个 start-state。

（2）jbpm 依靠 Token 来调度和计算，在同一个时刻中，一个 ProcessInstance 只允许一个 Token 对象只存在一个 Node 中（分支当然

用 Child Token 对象处理）。所以本质上就不支持“multi-instance”模式。

（3）jbpm 作为一款开源的工作流引擎，其更多的是关注“如何辅助你更容易的让流程运行完成”，但是并不记录“流程运行的历史和

轨迹”。这一点可能是东西方文化的差异性所在，因为国内的流程应用，比较关注“运行轨迹”。

至于其他的一些局限，比如不支持“回退”、“跳转”等操作，这也是因为东西方文化的差异所在。西方人认为“往回流转的情况

肯定也是一种业务规则所定义，那么肯定可以通过分支或条件来解决”，而东方则把“回退作为一个人性化管理和处理的潜在特点”。

所以诸如此类的一些“特定需求”，估计只能通过扩展 jbpm 来实现了，甚至有时候，简单的扩展是无法解决问题的——正如上一节所

说的那样，“引擎的抽象”会影响“引擎的应用”的复杂度支持。

但是，当你试图修改 jbpm 代码的时候，你会顾虑 jbpm 的 LGPL 协议吗？（很多国内企业从来不考虑这个协议问题，寒）。

6 JBpm 流程模型与定义对象

6.1 首先解决如何形式化描述一个流程的问题

这里说的“定义流程”并不是说 jbpm3 中那个基于 eclipse plugin 的图形化建模工具。而是如何去解决“形式化的描述一个流程”

的问题。

形式化的描述流程并不是一个简单的问题，从上世纪七十开始，人们就在探索用各种各样多的模型来描绘流程：Petri Net,

FSM, EPC, Activity Diagram, 以及近来的 XPDL MetaModel 等等，延伸到如今的 BPEL,BPMN,BPMD 等等。

jBpm 采用了 Activity Diagram 的模型语义：其将用 Start State、State、Action State（Task Node）、End State、Fork、

Join、Decision、Merge、Process State 这几个“元素”的组合来描述任何一个流程。其中 Action State 是 Activity Diagram 中的

标准语义，在 jBpm 为了便于大家理解和使用，jBpm 采用了 TaskNode 这个语义。

在 WfMC 的 Workflow Reference Model 中，对流程引擎的功能描述，其中就包含一项：解析流程定义。如果想满足这这功能，前

提条件就必须有最基本的两个：

（1）有一套形式化的描述语言（通常为 xml 格式）。利用这个描述语言可以描述一个流程的定义。比如 WfMC 所提出的 XPDL 这个描述

语言。当然，jBpm 也有自己的一套，名为 jPDL，也是一个 xml 格式的。

（2）有一套对象集可以反映流程的定义模型和结果，一般叫做定义对象。流程引擎就需要把“xml 格式的流程定义”解析为一套对象，

而这套对象的结构则反映了流程的结构。

我们暂且不去探讨 jPDL 那个形式化的 xml 语言，而把重心放在 jBpm 那套定义对象中。因为这个定义对象是属于 Engine Kernel

的一部分。

6.2 抽象的节点（Node）和转移（Transition）

面向对象的继承性、多态性可以让我们从最抽象的部分来描述对象。那么这套定义对象也需要从最基础的“抽象”说起。

process 的本质就是“节点”和“有向弧”，当然你也可以说是 Node 和 Link，或者 Node 和 Transition，或者 Activity 和 Transition

等等之类的。jBpm 采用的是 Node 和 Transition 来表示“节点”和“有向弧”。

于是乎，在 jbpm 中你可以看到这样的结构关系：

剩余25页未读，继续阅读

评论收藏

内容反馈

猫一样的女子245

粉丝: 93
资源: 2万+

揭秘jbpm流程引擎内核设计思想及构架.docx

揭秘jbpm流程引擎内核设计思想及构架.doc

揭秘jbpm流程引擎内核设计思想及构架

揭秘jbpm引擎内核设计思想及构架.pdf

揭秘jbpm流程引擎内核.pdf

JBPM流程引擎设计 工作流资料

JBPM工作流引擎内核设计思想及构架笔记分享

JBPM相关文档大全

jbpm学习笔记.docx

JBPM3总结.docx

jbpm5 持久化及流转流程剖析.docx

JBPM与Spring集成开发指导书.docx

jBPM5 用户手册-中文版.docx

JBPM与Spring集成开发指南.docx

2023.10.21 雷蛇+鼠标宏+PUBG+绝地求生 步枪通用

115转存助手ui优化版3.9.1网友魔改-转存提取全修复-user

恩山新版中兴Telnet工具体验版-20230830.rar

基于华为eNSP的校园网设计和仿真模拟.zip

蓝牙驱动，解决win11下的设备管理器蓝牙报错提示为：Generic Bluetooth Adapter驱动感叹号解

大漠插件3.1233全套

csgo鼠标宏，lua格式

Chrome浏览器 v109.0.5414.75稳定版 64位 离线安装包

高逼格PPT模板20套.rar

OpenGD77刷机材料

yolov5的模型yolov5s.pt

notion-2.2.0-app.asar

【通信原理课程设计】基于MATLAB/Simulink的2ASK数字带通传输系统建模与仿真

最新资源

JBPM流程引擎设计工作流资料

2023.10.21 雷蛇+鼠标宏+PUBG+绝地求生步枪通用

Chrome浏览器 v109.0.5414.75稳定版 64位离线安装包