这是一篇反对使用ESB作为集中式Hub方式的文章，作者认为一个统一的昂贵的ESB是没有必要的。下面是大意翻译：
ESB激怒我并不是技术本身，而是他们所使用的方法，主要是因为每个一个架构师和他的导师似乎都认为不能没有它，在每一个系统图中间都有一个笨重的大矩形。它并不总是被称为ESB，有时称为“业务流程”或“集成中心”或供应商的产品名称。
首先我们看一下集中式ESB的坏处以及如何以合适方式使用。
图中显示所有的服务通过一个ESB来联系，服务并不知道彼此，中央ESB复杂后需要一个团队来支持它，实际上一个组织中每个服务都是时刻在改变他们的暴露或流程，这样为了防止每个人都会黑了ESB，所有的请求改变为从直接发往ESB到发给ESB团队。
那么ESB的团队就开始拼命忙碌，会被认为是英雄一样帮助大家一起交流，帮助每个服务团队调用获得他们组织的其余需要的东西。不久，他们得到新功能的请求，但是他们不知道如何更改服务，哪些服务应该处理这个功能是一个有点棘手的工作，，这样他们就会将业务逻辑一点点滑到ESB中。这持续了数年，直到大家都明白，ESB包含了大多数的业务逻辑，服务已经差不多成了数据库的CRUD层。
该图是使用ESB技术合适的方式，当然，它再也不是一个真正的ESB，因为它不是整个企业级别，已经不是为整个企业的一个总线，每个服务都会使用ESB技术以保证他们的接口文档，他们可以用它来同时维护一个服务范围内多个版本的接口。服务团队拥有完全的自主权决定在他们的服务会发生什么。在许多情况下，他们并不需要昂贵的软件来做到这一点，他们可以简单地用所选择的编程语言编写它，或使用一个简单的库来实现类类似调解，路由，位置，安全性等，一旦每个服务都有这个能力，那么对于中央的ESB团队要求完全没有了。于该组织一直理智为每个团队分配服务那，鼓励团队与对方直接沟通获得新的功能。面对面的人对人的交流方式也提高了他们对企业软件资产的整体理解。
假设有一个服务方法：
MoneyValue getPriceOfGold()
这在现有功能需求下工作得很好，如果需求变化了，要增加另外一个金属银的价格，聪明的架构师会创建一个新的方法：
MoneyValue getPriceOfMetal(Metal metal)
老的方法getPriceOfGold 因为已经有几个消费者，在这个方法的内部我们转向调用新的方法getPriceOfMetal，这样每个人都不会影响，过一段时间，要求老方法的所有消费者都升级到新的方法调用即可。
这样你并不需要一个中央集中的ESB来完成，你无需在服务外边加入任何东西，只是在服务内部加入一些协调逻辑即可。
还有一种观点，ESB能够允许我们编排服务，编排器是是一种业务逻辑，应该属于服务内部。
有人认为：
服务还有定位服务的功能，器是每个服务都应该有定位其他服务的功能，尅使用DNS，Bonjour也是一种常用的解决方案，UDDI其实没有什么需求。
ESB能够实现路由吗？
一个服务订阅另外一个服务的事件，DNS能够发现Broker，大部分消息Broker提供消息路由。
ESB能够监视我的服务？
你的服务自己应该提供监视自己的功能，比如可以通过syslog JMX和SNMP或windows Events来监视，一些开源Nagios, OpenNMS 都可以做这些事情，你并不需要ESB来完成。
ESB会提供额外的安全吗？
不，他们其实已经被终端移除了安全，开发给你使用，无论你是有意或无意都会造成攻击。