jbpm
定义
jbpm 是一套灵活的业务流程管理套件，以纯 Java 实现、轻量且完全开源，采用 Apache 许可证 2.0 发布，可用于建模、执行和监控业务流程的整个生命周期[1]。其名称含义为 Java Business Process Model，由红帽赞助，是 JBoss 社区的一部分，与 Drools、OptaPlanner 同属 KIE 项目群[3]。
该套件关注的是“可执行流程”，也就是细节足够充分、能被流程引擎直接运行的定义；它把业务人员理解的领域概念与开发者的代码衔接起来[1]。官方文档强调它是一组嵌入到服务中的 Java 库而非独立的服务器程序[2]。
原理
jbpm 以图形化的流程描述作为输入。一个流程由若干任务组成，任务之间以顺序流连接，整体表示一条执行路径；流程图同时充当非技术用户与开发人员沟通的共同基础[3]。流程定义每被运行一次，就产生一个流程实例，引擎负责创建流程实例、持久化状态，并在运行中推进各节点[3]。
流程中的活动分为两类：一类自动完成，例如发送邮件或调用外部服务；另一类充当等待状态，例如需要人工处理的任务，或等待外部系统返回结果[3]。引擎的核心是纯 Java 编写、可扩展的工作流引擎，可在任意 Java 环境中作为库嵌入应用，也可作为服务部署运行[2]。它对 BPMN 2.0 的覆盖较完整，包括各类网关、中间捕获与抛出事件、边界事件、错误、信号、消息、定时器、子流程、多实例活动以及补偿与事务等构件[2]。
在引擎之上，持久化与事务以可插拔方式提供，早期版本默认基于 JPA 与 JTA[1]。需要人工参与时，由独立的人工任务服务按 WS-HumanTask 兼容的生命周期管理任务的领取、开始、完成、委派与升级，并支持按组、按角色分配[2]。流程中的业务规则任务可以直接调入 Druuls 规则集或 DMN 决策，从而在同一服务内完成流程与规则的联合求值[2]。
发展历程
该项目由 Tom Baeyens 于 2002 年 3 月发起，2003 年 12 月发布 1.0 版本[4]。2004 年 10 月 18 日发布 2.0 版本，并于同日加入 JBoss 组织，成为 JBoss 中间件平台的一部分，名称随后改为 JBoss jBPM[4]。此后 jBPM 3 于 2005 年、jBPM 4 于 2009 年相继发布[4]。
早期版本使用自有的流程定义语言 jPDL，并在 jBPM 4 中引入流程虚拟机(PVM)，作为承载多种流程语言的通用执行内核；约在 2009 年 8 月，项目开始在 PVM 之上并行构建原生 BPMN 2.0 实现[5]。2010 年至 2011 年间，jBPM 项目与 Druuls 规则引擎下的工作流子项目 Druuls Flow 合并，合并产物 jBPM 5.0.0.Final 于 2011 年 1 月 31 日发布，转而以 BPMN 2.0 作为原生表示法，不再以 jPDL 为主[5]。
jBPM 5 完全放弃了 jBPM 4 的基础代码，代码来自 Druuls Flow，也因此招致部分旧用户的不满；离开 JBoss 的 Tom Baeyens 加入 Alfresco 后，基于 jBPM 4 推出了竞品 Activiti。jBPM 6.0 于 2013 年 11 月 20 日发布，带来 KIE API、Business Central 以及流程与规则的统一平台；jBPM 7.0 于 2017 年 5 月 26 日发布，加入案例管理并重新设计了 Business Central[5]。7.x 系列于 2022 年起逐步收尾，7.74.1.Final 在 2023 年 7 月作为该独立产品线的最后一个维护版本发布，社区重心转向云原生运行时 Kogito[5]。
应用
jbpm 主要用于构建业务应用。它可以作为独立服务运行，也可以嵌入到自定义服务之中，对使用何种框架不作强制要求，已用于传统 JEE 部署、Spring Boot 等打包方式以及独立的 Java 程序[3]。除 BPMN 2.0 流程外，它还提供案例管理、DMN 决策管理、DRL 业务规则与求解优化等能力，把业务逻辑外化为可复用的资产[3]。
在实际使用中，配套工具覆盖流程的整个生命周期：基于网页与基于集成开发环境的建模器用于图形化绘制流程，Business Central 工作台承担编写、部署与监控，KIE Server 则以 REST 等远程接口对外暴露执行能力，使应用能够以编程方式启动流程和完成任务[5]。此外还提供流程实例管理控制台、任务列表与报表，并通过历史日志支持查询、监控与分析[1]。由于面向的是需要流程与系统集成的复杂业务场景，这类工具常被用于跨系统、跨部门的流程集中管理。
对于步骤无法事先确定的场景，jBPM 7 及以上版本提供案例管理支持，允许在运行时动态增加任务或流程，使案例随进展演化，而不必拘泥于预先排定的固定路径[6]。
局限
jBPM 对 CMMN 的支持是有选择的。7.8 版本引入的 CMMN 1.1 原生执行只覆盖任务、阶段、里程碑、案例文件项、哨兵等主要构件，并非完整实现规范；任务的 required、repeat、manual activation 等属性尚不支持，任务级哨兵也只限于进入条件[6]。项目方同时说明，不提供也不计划提供 CMMN 的建模能力，仅关注该类模型的执行，并仍建议以 BPMN 2.0 搭配案例管理特性设计复杂案例[6]。
引擎的持久化默认依赖 JPA，流程状态存储与关系型数据库和事务管理器绑定较紧，选型时需考虑与既有技术栈的配合[1]。在从 jPDL 转向 BPMN 2.0 的过程中，4 版本引入的 PVM 被放弃，早期流程定义的升级路径因此中断，旧版本用户并非都能平滑迁移。
社区版本的路线也出现过明显收缩：独立发布的 7.x 系列在 2023 年 7 月发布最后一个维护版本后不再延续，后续能力由云原生的 Kogito 承接，这使仍使用传统部署方式的项目需要另作规划[5]。此外，官方文档对自身定位的表述是“一组 Java 库”而非服务器，若需要独立的流程管理平台，还需另行组装控制台、数据索引等配套组件[2]。
参见
参考资料
- WhatIsjBPM-section [引用日期2026-10-29]
- What is jBPM? | Apache KIE (incubating) [引用日期2026-10-29]
- jBPM [引用日期2026-10-29]
- 流程引擎之jBPM简介 [引用日期2026-10-29]
- jBPM [引用日期2026-10-29]
- jbpm-7-8-native-execution-of-bpmn2-dmn-1-1-and-cmmn-1-1 [引用日期2026-10-29]