如果你向Dave Linthicum询问企业服务总线的命运，他可能会给你几个选项。事实上，在如何适应新型的SOA—云范式上一直存在争论。

　　软件架构师Ganesh Prasad认为Dave并没有看到ESB 的作用有多大。Ganesh Prasad是一位Java和开源的狂热爱好者。他甚至提出了下一个十年中转移到ESB方法的有趣名词，这个新的名词叫做“企业服务云”。

　　ESC的到来尚需时间，但是我们真正谈论的比ESB多的东西在哪里呢？Ganesh表示ESB遵循星形模型，它更符合二十世纪九十年代的EAI的初衷。在2010年，我们应该开始实践SOA，而非EAI。Ganesh说：“这意味着追随一种联合的方法，非EAI中间件的方法，而且，不管我们是探讨SOAP还是REST，它都是联合的。”

　　另一方面，ESB受到中间件方法发的牵制，这使得维护起来很昂贵：

　　“ESB是失败的唯一指向和性能瓶颈所在。传统‘解决方案’通过提供冗余和高可用性来增强ESB，但是费用昂贵，不可避免地延期交付。正确的解决方案应该废除ESB，接受固有的联合的SOAP（或者REST）的模型。2010年，云风行一时，我们应该意识到SOAP和REST内提供了服务云。”

　　Ganesh的评论很有意思，尽管关于ESC或者“服务云”会是什么样的，如何进行管理和治理，是否代表了下一代的ESB，或者说完全不同，我们需要更多详细的内容。归根结底，SOA是关于业务转换的，通过把应用或者系统分解成灵活的组件服务，并映射到千变万化的流程中。Ganesh提到的ESC应该是一种私有的或者内部的云，并且基于SOA原则创建。

　　但是ESB在一些标准上，更倾向于云集成。多年以来，关于ESB是否是面向服务架构合理的一部分并不缺少争论，所以我们不妨开始探讨ESB是否会成为云的合适的一部分。

　　有件事情似乎确信无疑，即你最好保留私有云，因为存在外部ESB架构问题。

　　Rob Barry提供就新型的趋势提供了一些见解。他提到一些早期的ESB实例已经作为云引擎开始部署，并举例说明存在大量竖井的医疗保健设置中，ESB是如何进行数据共享的。

　　基于云端的ESB的最大挑战是什么呢？主要是在防火墙外部访问ESB的安全性问题。这意味着“开发经理需要对基础设施团队施加压力，来允许具体的连接到具体的机器，这也制造了很多维护点，久而久之这些维护点很难追踪，” 咨询师Steven Nagy建议到。