在我工作的一家大公司中，已经购买了一个非常（成本高昂）的ESB，其目的是通过重新使用传统基础设施将其与Web服务包装在一起，从而快速符合业务目标，也就是说不再需要编码。 ESB / BPM现在是否已经足够成熟，因为它已经超过10年了，还是仅仅是其他供应商的承诺？
答案 0 :(得分：5)
几乎可以肯定只是供应商的承诺。如果这成为贵公司的现实，那么他们将是第一个如此幸运的人！
这是十多年来一次又一次的销售工作（记得4GL？）。
大多数公司发现现实情况是：1）安装，整合ESB / BPM工具所需的工作量远远超过他们所认为的2），只有使用该工具才能进行最微不足道的改变 - 它仍然需要编码人员执行任何有意义的流程更改/添加，3）每当ESB / BPM工具供应商升级他们的工具时，升级并有资格获得支持是一项巨大的努力（查看任何这些工具的历史以及痛苦商店的经历多年来升级，特别是Webmethods和BEA / Oracle的产品，4）支持服务很昂贵，而且很少提供帮助（我知道已经支付了高级支持的公司已经提交了数十张门票，只有一个或两个在内部有人最终找到解决方案/解决问题之前，手机上的白痴解决了这个问题。
答案 1 :(得分：2)
您当然可以使用ESB / BPM来包装遗留基础架构，并促进向更现代化的目标架构迁移。实际上，这是在复杂的应用程序环境中采用ESB / SOA策略的最佳理由之一。
然而，这是一个完全谬误，这表示“不再需要编码”。毕竟，您需要编排一个可能复杂的Web服务序列，并详细了解遗留系统的状态和事务语义。另一个词是......编码。
P.S。现在对你来说可能为时已晚，但为了其他人的阅读，我不得不指出昂贵的专有ESB通常是浪费金钱。开源解决方案可以很好地完成您的需求（有时甚至更好！）。 JBoss和Mule立即浮现在脑海中。由于您无论如何都需要在内部完成大部分的艰苦工作，因此您可以花时间学习一个优秀的开源工具包，而不是将自己锁定在供应商的专有解决方案中。