我们的业务正在计划构建一个拥有大约 2000 名左右用户的相当大的业务应用程序。
系统中的许多对象都需要一系列稍微复杂的批准、通知等。
由于种种原因，我们公司决定拒绝正式使用BPMN或BPEL。我正在寻找的是一个工作流引擎，我可以将这些对象传递给它，作为促进、跟踪和管理这些对象状态的一种手段。我们正在使用 EJB 3.1 和 WebSphere AS 来实现这个项目。
我对工作流引擎的理解是否正确？一切似乎都与 BPMN 或 BPEL 相关……我只是在这里遗漏了一些关于为什么大多数解决方案似乎都实现 BPMN 或 BPEL 的东西吗？一些建议会很棒！
工作流引擎通常在企业架构中发挥积极作用。它们执行声明性流程模型，该模型基本上是由节点组成的有向图，节点代表活动或任务，边代表这些边之间的控制流。这样的边缘可以用条件注释以允许表达条件分支/合并。周围有几种建模语言，如 YAWL、XPDL、jPDL、BPEL 和 BPMN 2.0，它们位于这些抽象概念和一些语法、视觉和功能糖之上，但只有后者是官方的行业标准。这对于避免供应商锁定、使模型可互换（至少在一定程度上）、可由专家和不同工具支持非常重要。在运行时，流程实例是基于流程模型创建的，并根据模型定义的控制流执行。因此，引擎会主动从一个活动导航到下一个活动，从而“协调”您的业务逻辑。BPMN 2.0 和BPEL 的主要区别在于BPEL 与Web 服务紧密耦合，即活动调用的业务功能应该被呈现为Web 服务。因此，如果您想编排 WS-* 服务，它仍然是最佳选择，因为 BPMN 2.0 缺乏对具体服务实现的明确定义和标准化的绑定。无论如何，我强烈建议使用其中一种标准化语言，因为它们在行业中被广泛接受，并且受到各种供应商和开源社区的良好支持。因此，引擎会主动从一个活动导航到下一个活动，从而“协调”您的业务逻辑。BPMN 2.0 和BPEL 的主要区别在于BPEL 与Web 服务紧密耦合，即活动调用的业务功能应该被呈现为Web 服务。因此，如果您想编排 WS-* 服务，它仍然是最佳选择，因为 BPMN 2.0 缺乏对具体服务实现的明确定义和标准化的绑定。无论如何，我强烈建议使用其中一种标准化语言，因为它们在行业中被广泛接受，并且受到各种供应商和开源社区的良好支持。因此，引擎会主动从一个活动导航到下一个活动，从而“协调”您的业务逻辑。BPMN 2.0 和BPEL 的主要区别在于BPEL 与Web 服务紧密耦合，即活动调用的业务功能应该被呈现为Web 服务。因此，如果您想编排 WS-* 服务，它仍然是最佳选择，因为 BPMN 2.0 缺乏对具体服务实现的明确定义和标准化的绑定。无论如何，我强烈建议使用其中一种标准化语言，因为它们在行业中被广泛接受，并且受到各种供应商和开源社区的良好支持。0 和BPEL 是BPEL 与Web 服务紧密耦合，即被活动调用的业务功能应该被呈现为Web 服务。因此，如果您想编排 WS-* 服务，它仍然是最佳选择，因为 BPMN 2.0 缺乏对具体服务实现的明确定义和标准化的绑定。无论如何，我强烈建议使用其中一种标准化语言，因为它们在行业中被广泛接受，并且受到各种供应商和开源社区的良好支持。0 和BPEL 是BPEL 与Web 服务紧密耦合，即被活动调用的业务功能应该被呈现为Web 服务。因此，如果您想编排 WS-* 服务，它仍然是最佳选择，因为 BPMN 2.0 缺乏对具体服务实现的明确定义和标准化的绑定。无论如何，我强烈建议使用其中一种标准化语言，因为它们在行业中被广泛接受，并且受到各种供应商和开源社区的良好支持。
我试图更详细地解释这一点，因为我不完全确定您所说的“促进、跟踪和管理这些对象的状态”是什么意思。这听起来有点像您对被动监视对象的状态更改而不是使用工作流引擎主动控制状态更改更感兴趣。如果这个假设是正确的，那么也许抽象状态机会更好地满足您的需求。
看看 jBPM5，它提供了一个非常灵活的核心，允许您在它之上构建自己的领域特定语言。目前提供的语言是 BPMN2，但您可以轻松添加自己的语言。干杯
我们正在构建一个产品，该产品具有 BPMN 2.0 的迁移路径，但在内部不使用 BPMN。我们相信清单比流程图更容易在实时工作流程中使用。然而，仍然有规则/触发器/条件等等 - 所以它是一个有效地将流程建模为“类固醇清单”的工具：