Java ESB/BPM除了包装Web服务外，还能完全摆脱编码吗？

在我工作的一家大公司中，已经购买了一个非常（昂贵的）ESB，其目的是通过恢复用Web服务包装它们的遗留基础设施，使其能够快速与业务目标保持一致，也就是说，不需要更多的编码。ESB/BPM现在真的足够成熟吗？因为它已经有10多年的历史了，还是仅仅是其他供应商的承诺？

几乎可以肯定，它只是供应商的承诺。如果这成为你公司的现实，他们将是第一个如此幸运的人

十几年来，同样的销售工作一次又一次地在做（还记得4GLs吗？）

---

大多数公司发现，现实情况是：1）安装和集成ESB/BPM工具所花费的精力远远超过了他们的预期；2）工具只能进行最微不足道的更改—仍然需要编码人员来执行任何有意义的流程更改/添加；3）每当ESB/BPM工具供应商升级其工具时，升级和获得支持需要付出巨大的努力（查看这些工具的历史以及这些年来商店升级的经历，特别是Webmethods和BEA/Oracle的产品），4）支持服务价格昂贵，很少提供帮助（我知道一些公司支付了高级支持费用，他们提交了几十张罚单，但只有一两张在内部人员最终找到解决方案/自行解决之前通过电话得到了白痴的解决。

您当然可以使用ESB/BPM来包装遗留基础架构，并促进向更复杂的基础架构的迁移事实上，这是在复杂的应用程序环境中采用ESB/SOA策略的最佳理由之一

然而，说这意味着“不再需要编码”是完全错误的。毕竟，您需要编制一个潜在复杂的web服务序列，并详细了解遗留系统的状态和事务语义。换言之，就是……编码

---

p、 现在对你来说可能太晚了，但为了让其他人阅读本文，我觉得有必要指出，昂贵的专业ESB往往是浪费金钱。你需要的东西可以做得很好（有时甚至更好！）通过开源解决方案。我立刻想到了这一点。既然您需要在内部完成大部分艰苦的工作，那么您最好花时间学习一个优秀的开源工具包，而不是将自己锁定在供应商的专有解决方案中。

是的，太晚了，这是选择的两个ESB领导者之一；）我对上一个答案投了更高的票。如果你使用Mule，你可能会想了解该公司不愿意付款，因为它只能说，如果没有这个，成本会更高：）