如果在您周围，面向服务架构(SOA)是一个热门话题，就像我所在的公司那样，那么您可能会觉得自己很像那些一年级学生。我也有过这种感觉，直到有一天我跟公司的同事们坐在一起，他们是应用程序架构方面的专家，那一次我问了很多问题，也得到了一些很好的回答。本文我将谈到我从他们那里学到的一些东西。虽然我不会是最后一个说这话的人，但我还是要抢先告诉您：SOA 真好。

　　范例的变迁

　　写下这样的标题并不有趣。我实在不喜欢 “范例(paradigm)” 这个词。早在 20 世纪 90 年代中期，当一些顾问和经理总是将这个词挂在嘴边的时候，我就开始讨厌这个词。(我并没有恶意 — 我也是一个经理，而我一些最要好的朋友就是顾问。)然而，在这里我想不出更好的术语。SOA 确实代表着一次范例的变迁 — 应用程序开发在哲学框架上的一次变更。

　　这次大的变迁与敏捷性(agility)有着千丝万缕的联系。不久以前，应用程序的设计，尤其是企业级应用程序的设计，主要关心的一点就是 CPU 效率。大型服务器价格不菲，人们总是致力于开发能用最少的处理能力做最多事情的应用程序。

　　然而，主要由于以下两大趋势，情况又发生的变化：

　　就每单位处理能力所花的钱而言，服务器硬件变得越来越廉价。

　　企业面临着越来越大的压力，他们需要在非常短的时间内交付新的应用程序特性和功能。

　　SOA 的特征是应用程序基本方面(例如数据库模式、操作系统、服务器平台和编程语言)的抽象，因此编写服务消费程序的开发人员不必知道这些细节。SOA 还将应用程序的主要组件分布到不同的逻辑服务节点中，这些逻辑服务节点使用标准接口相互通信。这些服务可以在短时间内以搭积木的方式组合起来，提供新的功能。SOA 的这些特征通常(至少在某种程度上)增加了驱动一个应用程序所需的处理能力。然而，新的应用程序功能如果不能及时地满足企业或客户的需求，即使它在 CPU 效率方面得到了彻底的优化，也毫无价值。

　　言归正传

　　在进行 SOA 设计时，首先要对企业的业务有一个全面的理解，所以利用业务人员的知识是至关重要的。在理想情况下，企业架构师与业务专家合作，找出与企业需求相吻合，并且将通过一个应用程序提供的服务。应用程序开发的服务定义阶段不可小看。要确定应用程序将提供的服务的粒度并非易事。我有一个公司的同事，他是应用程序架构方面的专家，他就经常抱怨一些应用程序提供的服务的粒度过细。“我想要的是水，” 他抱怨道，“可是这个应用程序竟然要我请求两个氢原子和一个氧原子。”

　　那么，您要的是粗粒度的服务，对吗?也不一定。如果走这条路线，那么在通过组合服务创建新产品方面，又会丧失一定的灵活性。这是一个平衡的问题。实际上，最终得出的也许是粗粒度服务和细粒度服务的混合体，粗粒度服务公开给消费者，而细粒度服务则在应用程序更低级的代码中实现。在这个上下文中，“公开” 与应用程序服务被调用的方式相关，而 “消费者” 指的是使用那些服务的其他应用程序。在作更多的解释之前，我来回顾一下以往的一些应用程序架构。

　　紧密耦合，万事大吉

　　在 20 世纪 90 年代早期，当我在做应用程序设计评审顾问工作时，典型的企业级应用程序差不多是将所有东西放在一个 “盒子” 里 — DBMS、业务逻辑和表示逻辑都运行在一个服务器上。应用程序往往是单块式的，也就是说，应用程序的各种组件通常都是非常紧密地耦合在一起。正如我前面提到的那样，CPU 效率拥有非常高的优先级，而这种单块式的应用程序通常可以获得最好的 MIPS。

　　终于，一种更新的架构登场了，这就是客户机/服务器架构。用这种模式开发的应用程序可以让组件在不同的服务器上运行。这种方法通常有利于可伸缩性，因为应用程序的业务层和用户界面层所处理的工作负载可以分散到多个服务器上。(通常来讲，要得到一个得分最高的数据库服务器，需要不少得分最高的业务层服务器。)然而，客户机/服务器架构对于企业的敏捷性贡献不大。客户机/服务器连接在本质上大都是专有的，客户端程序员通常必须知道关于他的程序所访问的服务器的很多东西。

　　客户机/服务器架构之后，我们有了 SOA。想一想，如果您有一个订购应用程序和一个客户管理应用程序，那将会是怎样的情景。订购应用程序需要关于一个客户的信息(姓名、地址、电话号码等)，这些信息可能构成我们所谓的 customer “对象”。客户管理应用程序可以提供这样的信息。在 SOA 环境中，订购应用程序不需要知道关于客户管理应用程序的任何信息 — 包括用于编写这个应用程序的语言，它所在的系统，甚至包括 customer 数据库的模式(如果确实有一个 customer 数据库的话)。订购应用程序只需要知道 customer 对象是什么，以及如何得到那个对象。这就是 SOA 真正强大之处：它让服务消费程序的开发人员以一种处于概念层次的方式来与服务提供应用程序打交道。由此导致的程序员生产力提升大大减少了将新的基于应用程序的产品推向市场的时间。

[1] [2] [3] 下一页