开源ESB厂商MuleSoft在宣布其管理控制台发布时，声称支持使用自底而上的方法来实现SOA管理理念，在这之后，SOA社区中一个一直以来争论不休的话题：使用自顶向下还是自底向上的SOA方法，又引起了大家新一轮的争论。

　　在SearchSOA上，Rob Barry收集了一些关于自底向上和自顶向下两种方法的观点：

　　当增建SOA时，一个自底向上的治理方法会关注于将围绕一些可以快速组装的ESB个体的服务集成起来。这种方法由于需要过度的更新和随后的返工而遭遇批评。与此同时，与之相反的“自顶向下”的治理方法包括了周密的计划和严格的政策规范。但该方法也存在缺陷，因为它需要花太多时间才能产生结果。

　　文章汇集的观点认为：基本上，如果主要的目标在于集成，自底向上方法是一个不错的出发点。他们也认同自顶向下的方法需要更多业务的介入。至于到底是使用哪种策略，他们的结论是这取决于业务和IT的关系。

　　　Barry在ebizQ上的一篇博文点燃了导火索，引起了不多但却很有意思的回复。在其中一个回复中，Avi Rosenthal基于你正要构建的东西对两种方法进行了区分：

　　SOA是一种架构风格。构建架构是自顶向下而不是自底向上的。Web Service，有时错误的被定义为SOA，是技术性的。Web Services是自底向上构建的。自底向上地构建SOA是错误的方法，有时也被称为ABOS（一堆服务）。如果你自底向上的构建SOA，那么很有可能你最终会得到很多冗余的东西，而毫无架构可言。尽管如此，如果仅仅通过自顶向下构建SOA，其结果往往是得到不能构建在任何运行时产出物之上的感性架构，因此应该将SOA的一些工作放在自底向上的事情上。总而言之：最开始，SOA是自顶向下的方法，但实际使用中需要同时结合自顶向下和自底向上两种方法。

　　在对该问题的另一则回复中，Michael Poulin认为SOA以用户为中心的本质迫使了自顶向下的方法的使用：

　　如果从现在你已有的东西去构建服务——使用自底向上方法的话——最终很可能以你有什么而告终，而不是你的用户需要的。SOA是以用户为中心、业务为导向的架构。以用户的需求为出发点将使你不得不去使用自顶向下的方法。这始终都可以作为出发点。但是，接下来，你最好评估你自身的能力，比如，挖掘你的最底层的资源来审视用户的需求。

　　这样的争论已经不是什么新鲜事儿了。早在2005年，John Crupi就撰文称SOA是业务驱动的架构风格，正因如此只有自顶向下的方法才能获得成功：

　　自顶向下，意味着从问题，到架构，再到解决方案。它并不是指，从我们现有的东西着手，然后采用一些新技术对其进行包装，仅仅就因为我们可以使用这些技术。虽然自底向上的方法看起来是那么自然和简单，好像是治疗SOA失败的绝妙处方。

　　在那以前，还有其他一些诸如Bill de hÓra的博文那样反对“自顶向下或失败原则”的声音：

　　仅仅使用自顶向下方法的困难之处在于并不存在所谓的“顶”，现实中的SOA系统往往是分散式的——不存在架构杠杆支点或治理点，没有哪一个人有能力声称，“他可以十分钟之内做出决定或是下一个决定是有效力的，立刻就能付诸执行”。

　　这样的争论已经持续很多年了。到目前为止，看起来一些工具厂商已经选择了自顶向下的策略。