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