自顶向下还是自底向上—SOA 之争战火重燃

  • William Martinez Pomares
  • 吴宇

2010 年 7 月 21 日

话题:SOA架构

开源 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 系统往往是分散式的——不存在架构杠杆支点或治理点,没有哪一个人有能力声称,“他可以十分钟之内做出决定或是下一个决定是有效力的,立刻就能付诸执行”。

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


查看英文原文:The Top-Down vs Bottom-Up SOA Debate Revisited

SOA架构