我们有一个应用程序使用 BPM 来管理长时间运行的流程。 我们不想再使用这个产品，我们正在考虑将它转移到 ESB（即 Mule）。
我对此的看法是，复杂且长时间运行的进程不属于 ESB。此外，它还需要管理我认为 ESB 不应该做的状态。 ESB 旨在处理大量、短期、实时类型的消息？我这样说对吗？
是否有人同意/不同意这一点，最好的解决方案是什么？ 例如，是否应该将 BPM 代码重写为 Java 应用程序，并在其背后使用数据库来管理状态并使用 Mule 中的石英来处理周期性任务以替换 BPM 应用程序中使用的计时器？
我很想听到尽可能多的意见。 非常感谢。
【问题讨论】：
标签： mule esb business-process-management
我猜在你的情况下，如果满足 3 个特征，你可以迁移到 ESB：
您可以使用 ESB 跨系统移动消息。如果您需要捕获和跟踪状态，您可能希望使用数据库来保持同步。您还可以通过 JMS 等队列系统强制执行某种级别的事务支持。
您可能需要很好地了解如何移动东西。一个好主意是用薄层覆盖 BPM，然后在不影响用户体验的情况下替换它。
我希望这会有所帮助。披露：我是 BPM 公司 Intalio 的首席架构师。
【讨论】：
我想我在这里聚会有点晚了:)，但我会写信给那些来这里寻找答案的人......
这就是 Ross Mason 对 ESB BPM 讨论的看法。
Mule 3 通过 Flow 提供强大的编排功能，即 非常适合目标是最大化的短期交易 吞吐量和可扩展性。对于其他用例，例如长时间运行 交易，Mule 支持商业和开源 BPM 产品（如 jBPM、Activiti、BonitaSoft BPM 等）。
所以是的，ESB 和 BPM 是互补的解决方案，而不是相互替代。
总之，我猜你的观察是正确的。
【讨论】：