本文的分析是在 jBPM 7.7、Camunda 7.17.0、Flowable 6.7.2 和 Activiti 7.3.10上进行的：
本文将概述工作流、BPM 以及 BPM 产品支持的一些行业标准符号。接下来，本文将介绍 BPM 替代方案以及何时应该使用其中一种，以及可扩展性注意事项。最后，深入探讨了四个开源 BPM 项目：jBPM、Camunda、Activiti 和 Flowable。本文将把这四个维度与这三个维度进行比较：
- 开源模型（即社区与企业）
- 能力集
- 社区活动
什么是工作流程？
工作流通常是一个含义过多的术语。根据其使用的上下文，它至少可以具有三种不同的含义。在基本层面上，工作流是业务流程的离散步骤的结构化流程。工作流程的一种形式是人工工作流程。例如，某人正在调查案件或将申请发送给另一个小组进行审查。工作流程的第二种形式是系统编排。可能存在需要以特定顺序调用一组API来完成仅涉及系统步骤的业务流程。第三种类型的工作流程涉及人工和系统编排的混合。通常，系统编排可能会遇到错误场景，或者可能需要审查某些内容以进行进一步研究。从这三个示例中，您可以看出了解工作流上下文的重要性，因为它可以具有不同的含义。
工作流的特征也可能具有不同的复杂程度。工作流程分为两类：简单的和复杂的。以下是每个的一些特征：
简单的工作流程
- 任务管理——考虑用户的待办事项列表
- 通知——通过电子邮件或短信提醒用户
- 状态管理——项目的状态，例如未开始、进行中或完成
- 单个组中的用户数量较少 - 没有跨团队或部门协调
复杂的工作流程：
（包括所有简单特征以及以下特征）
- 许多组/用户 -跨越许多部门或部门
- 多层次的工作流程——各种分支和路径
- 异常路径、回调——错误处理并根据条件返回到之前的步骤
- 案件管理——不可预测的临时调查类型活动；根据条件可以使用一个或多个工作流程
- 与规则集成- if/then 键入业务或政策决策的逻辑
- 与系统编排集成——人工工作流程和系统工作流程的结合
什么是 BPM 产品？
BPM 产品的核心是提供管理业务流程的模型的可视化建模和执行。它们通常提供与各种适配器的附加集成功能。类似的名称还有业务流程管理系统 (BPMS) 或智能业务流程管理系统 (iBPMS)。其他类别的产品可能只提供建模，但 BPM/BPMS/iBPMS 产品同时提供建模和执行。开源环境可能会令人困惑，因为有 20 多种产品提供不同级别的功能
行业标准符号
开源 BPM 产品支持的一个常见主题是对象建模组 (OMG) 实施的一些行业标准符号。共有三种行业标准符号：BPMN、CMMN 和 DMN。让我们更详细地了解每一个。
1、BPMN — 业务流程建模符号
BPMN 于 2004 年首次发布，为业务流程建模提供了行业标准。它很重要，因为它使 BPMN 视觉模型可移植，这意味着在一个应用程序中构建的 BPMN 图可以在另一个应用程序中使用（只要该工具没有在其上覆盖任何专有项目）。它还鼓励商业和技术合作。通常，您可以让熟悉 BPMN 的业务分析师创建一个业务流程，然后将其交给他们的技术合作伙伴以在 BPM 产品中实施。
2、DMN：决策建模符号
在业务流程中，您通常需要 if/then 逻辑来做出业务决策。这就是 DMN 派上用场的地方。它于 2015 年首次发布，为与 BPMN 兼容的业务规则和决策提供了行业标准符号。
3、CMMN — 案例管理建模符号
第三种类型的行业标准建模符号是 CMMN，它于 2014 年首次发布。案例管理通常与标准工作流程不同，因为它本质上是临时性和调查性的，而且是不可预测的。
何时使用 BPM 产品？
虽然 BPM 产品非常擅长以可视化方式解决多个工作流程问题，但您可能并不总是需要如此丰富的功能。在某些情况下，基于配置的轻量级解决方案可能更适合。以下是状态机的一些示例：
- AWS Step Functions（工作流工作室）。提供了一种在 AWS 中编排 lambda 函数的方法。还提供了可视化建模器（不支持 BPMN）
- X状态。基于 JSON 的状态机，可用于实现工作流程
- Conductor (Netflix)可用于面向微服务的系统编排
现在您可能想知道，我什么时候应该使用 BPM 产品？一般经验法则是，当在模型中可视化构建工作流比在代码或配置中更容易构建时，请使用 BPM 产品。用例通常属于两个维度：集成程度和业务流程的复杂性。需要高度集成和/或高复杂性的业务流程通常是 BPM 产品的最佳选择。
单体架构、微服务和可扩展性注意事项
使用 BPM 产品时需要注意的一个方面是确保您没有在其中构建整体应用程序。做到这一点很容易，因为产品通常提供开发应用程序所需的大量工具。此外，一些 BPM 产品本身就是整体部署。我们稍后将讨论这一点，因为许多开源 BPM 产品正在转向基于云原生微服务的部署模型。
一个关键的考虑因素是要有意识地了解您在 BPM 产品内部构建了哪些内容以及将哪些内容保留在 BPM 产品之外。我通常建议您仅将 BPM 产品用于其擅长的领域——工作流程。将其他所有内容保留在产品外部，并使用各种适配器来构建与工作流程的集成。
努力实现的一个关键目标是在使用 BPM 产品时构建微服务。实现此目的的一种方法是将流程分解为子流程，并将每个子流程部署为自己的微服务，以使其更具可扩展性。
另一个可扩展性考虑因素是评估 BPM 引擎的部署方法。通常有两种方法：进程内/嵌入模式或独立模式。这些方法各有利弊。
- 进程内/嵌入式模式
在进程内/嵌入模式下，BPM 引擎作为应用程序的一部分在同一 JVM 下运行。这种方法提供了高性能，因为应用程序和 BPM 引擎之间没有任何网络调用。然而，它在两者之间造成了紧密耦合。它还可能使扩展变得更加困难，因为要扩展 BPM 引擎，您还需要扩展应用程序。
- 独立模式
在独立模式下，BPM 引擎作为其自己的独立服务进行部署，应用程序通过 API 调用与其集成。这将 BPM 引擎与应用程序解耦，并允许每个引擎独立扩展。一个缺点是，由于应用程序和 BPM 引擎之间的网络 API 调用，它可能会提供较低的性能。
开源 BPM 比较
现在我们已经介绍了很多背景和上下文，让我们开始仔细研究一些开源 BPM 产品。首先，让我们看一下开源 BPM 的一些历史性里程碑，特别关注那些基于 jBPM 重写（即 Activiti）或 jBPM 分支（即 Camunda、Flowable）的里程碑
jBPM
jBPM 于 2003 年推出，是第一个推向市场的开源 BPM 产品。它是唯一的开源 BPM 产品大约七年时间，直到 2010 年 Activiti 推出。三年后的 2013 年，Camunda 从 Activiti 中分叉出来。然后在 2017 年，Flowable 通过从 Activiti 中分叉而诞生。当每个产品分叉时，架构的某些部分被重用，而其他部分则被完全重写。
从行业标准符号的角度来看，BPMN的第一个版本于2004年发布，七年后的2011年发布了2.0版本。CMMN于2014年发布，一年后的2015年发布了DMN。
在 DMN 发布后的接下来几年里，我们看到许多开源产品与 CMMN 一起构建了对 DMN 的支持。有趣的是，经过五年的社区反馈，Camunda 基于社区反馈认为 CMMN 过于复杂，决定取消对 CMMN 的支持。用户发现在 BPMN 中构建案例流比在 CMMN 中更容易。
2020 年，jBPM 启动了一个名为Kogito 的新项目，该项目将[url=https://drools.org/]Drools[/url]和jBPM的架构重构为云原生和基于微服务。2022 年，Camunda 发布了其产品 v8，该产品具有高度可扩展性并专注于流程编排。
从 2004 年到 2010 年左右，jBPM 一直是热门搜索查询之一，然后人们对 Activiti 的兴趣激增，并在 2016 年超过了 jBPM。2016 年晚些时候，Camunda 成为热门搜索查询，从那时起，人们对 Activiti 和 Flowable 的兴趣就最大了。即使 jBPM 的搜索查询量最低。
开源模型（即社区与企业）
这是需要理解的最重要的方面之一，因为每个开源 BPM 产品都有不同的开源模型。这通常会令人困惑，但您需要清楚社区和企业中可用的内容，以便确保解决方案能够解决问题。
- jBPM 拥有最简单、最开放的模型。社区版中的一切都在企业版中。企业版基于最新社区版本的多个分支，以确保其稳定版本（相对于实验性功能）。您使用企业版获得的增量是来自红帽的支持。
- Camunda 的模型略有不同，他们的引擎（即 Zeebe）是可用的，他们的 Modeler 是开源的，而提供操作功能的其他模块不是开源的，但可以在 QA 中免费使用。可用源的细微差别与开源非常接近，区别在于您不能使用它来托管提供给其他人的商业解决方案（例如，认为 SaaS 提供商）
- Activiti 具有与 jBPM 和 Camunda 不同的开源模型。他们提供了所有功能的基本部分，但要获得更高级的功能，您必须购买企业版本。Flowable 也遵循与 Activiti 类似的开源模型。
能力集
现在让我们来看看这四种产品各自的高级功能集，重点关注以下领域：
- 规则引擎
- 建模和执行环境
- 部署方式
- 仪表板
- 案例管理
- 云原生/无服务器/容器
- 云托管服务产品
规则引擎：
- jBPM 是唯一提供内置业务规则管理系统（称为 Drools）的开源 BPM 产品。
- Camunda、Flowable 和 Activiti 都支持利用决策表的 DMN 表示法，
- 但是 Drools 具有更多功能，包括使用增强版Rete 算法的前向和后向链接推理引擎。这使得 Drools 能够自动找出要执行的规则以及执行顺序。
建模与执行环境：
- jBPM 提供了一个基于 Web 的建模器，它是称为 Business Central 的整体 UI 的一部分。在 Business Central 中，您可以部署、管理和跟踪工作流程
- Camunda 提供桌面建模器和 Web 建模器（仅通过 SaaS 产品提供） 称为任务列表、操作和优化的操作模块仅在企业中可用（但可以在 QA 环境中免费使用）
- Activiti 提供了一个基于 Web 的建模器以及一个 Eclipse 插件作为社区版本的一部分，而企业版本则添加了流程分析、定制业务应用程序、移动、DMN 设计器、流程应用程序设计器、管理、分析和集成。
- Flowable 提供了基于 Web 的建模器和 eclipse 插件，并在社区版本中提供了各种操作模块的各种核心功能，包括任务、管理和身份管理。
部署方式
jBPM、Activti 和 Flowable 都支持进程内/嵌入模式以及独立模式。Camunda 仅支持独立模式。这是一个有意的决定，因为他们发现进程内/嵌入模式给他们的社区带来了可扩展性挑战，因此从 Camunda v8 开始采用了仅独立模式。
仪表板
jBPM 是唯一在其社区版本中提供仪表板功能的产品。其他三个在其企业版中提供仪表板，特别是 Camunda Optimize、Flowable Work 和 Activiti Process Analytics。
Case管理CMMN
jBPM 和 Flowable 提供对 CMMN 的支持，而 Camunda 和 Activiti 则不支持。之前我们讨论了 Camunda 根据社区反馈有意决定取消对 CMMN 的支持。
云原生/无服务器/容器
- 如前所述，jBPM 大力投资 Kogito 项目，该项目是迁移到云原生微服务部署的下一代 jBPM 和 Drools 项目。它还包括对反应式消息传递 (Kafka) 和无服务器工作流程利用 (knative) 的支持。该计划是继续提供传统的 jBPM 和 Drools 项目以及下一代 (Kogito) 项目，以允许用户在项目之间进行选择。
- Camunda 8 被誉为流程协调器和高度可扩展的。它们提供对 Kubernetes 和 Helm 图表的支持。
- Activiti 以其与 Spring Boot 的轻松集成而闻名，并且还支持 Kubernetes。
- Flowable 最近做了几个示例，展示了他们的引擎如何以无服务器 方式运行，例如在 AWS Lambda 中运行引擎。
云托管服务产品
自 2016 年以来最大的变化之一是，我们现在看到开源 BPM 产品作为云中的托管服务产品提供。Camunda 提供 SaaS 产品，而 Alfresco Activiti 提供称为 Alfresco Cloud 的 PaaS 产品。这两个都是企业选项，让您无需自行管理任何基础设施。
社区活动
如果您要使用开源产品，您希望使用具有活跃社区的产品。这使您能够依赖社区的支持和增强，而不是独自完成这一切。
发现 Camunda 和 Flowable 似乎是最活跃的项目，其次是 jBPM（过去三年的活动水平保持一致），然后 Activiti 在过去两年相对安静，提交量突然激增。
Activiti 提交的安静可能是 Flowable 分叉的结果（以前的 Activiti 贡献者现在专注于提交 Flowable）
结论
我们在本文中讨论了几个关键的开源 BPM 主题，并提供了四个常见项目的比较。最终由您决定哪一种最适合您的需求和用例。