hzpengqb - 2008-2-17 9:03:00
如果在您周围，面向服务架构(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 真正强大之处：它让服务消费程序的开发人员以一种处于概念层次的方式来与服务提供应用程序打交道。由此导致的程序员生产力提升大大减少了将新的基于应用程序的产品推向市场的时间。
紧密耦合也有存在的道理
在 SOA 环境中，应用程序组件被描述为 “松散耦合的(loosely coupled)”。松散耦合是指使用另一个组件提供服务的一个组件对前者的依赖性不强：它是语言独立的、平台独立的事务。
然而，这不是说 SOA 在结构上有缺陷。这些松散耦合的应用程序组件之间的交互是由契约来定义的，一个严密的契约就是一个好的契约。在 SOA 上下文中，契约是一个应用程序服务的消费者与提供者之间的契约：“你给我发送一条包含所需格式的客户号码的消息，我为你提供与那个客户号码相关的以下各项信息 ...”
当然，这种契约不同于您在买房子时签的那种契约。它必须以一种不同应用程序系统都能理解的语言来表达。在 SOA 中，这种通用语言就是 XML。
服务!从这里获得您的 Web 服务!
在 SOA 环境中，服务是用一种特定格式的 XML 来描述的，这种特定格式的 XML 就是 Web 服务描述语言(Web Services Description Language)，简称 WSDL(发音为 WIZ-duhl)。在参考资料部分列出的 W3C 网页上，可以学到关于 WSDL 的详尽知识。这里我只给出一个概述。
WSDL 通过 XML 模式的方式描述与一个服务相关的契约：它接受什么数据类型，它返回什么，等等。这个模式包含在一个称做 XML 模式定义的文档中(后缀为 “.xsd” 的一个文件)。契约的 WSDL 描述实际上可能指向一些 .xsd 文件;其中一个 .xsd 文件可能描述一个对象(例如一个 customer)，其他一些 .xsd 文件可能描述与服务有关的一些操作(例如 GetCustomer 或 GetCustomerResponse)。契约描述还可以包括绑定，绑定与调用服务的格式有关。SOAP 就是这样一种格式，不过它与我们在沐浴时用的肥皂可没什么关系。
SOAP 是简单对象访问协议(Simple Object Access Protocol)的缩写。同样，W3C 上的热心人已经提供了一个网页，上面有大量关于这方面的信息，在此我就不多费口舌了。我的一个同事把 SOAP 比作一种 XML 方言。虽然对 Web 服务的 SOAP 调用通常要借助 HTTP，但是 SOAP 并不是一定要使用这种特定的通信协议。例如，如果要按照异步的、消息驱动的模式来开发应用程序，那么我们可能选择使用消息队列，而不是 HTTP。
我在这一节中安排了 “Web 服务” 这个术语，这可能导致您认为我正要谈到像您公司通过 Internet 公开给外面世界的那种服务。然而实际上，虽然服务是可以那样使用，但是更稳妥的说法是，大多数 Web 服务是部署在企业的 intranet 中。不要以为 Web 服务的使用就等于 SOA 的实现。企业架构设计师喜欢这样来形容应用程序系统的特征：程序之间以及程序与数据库表之间存在各种类型的点对点连接，就像一个 “毛团”。您可以通过 Web 服务实现所有这些连接，但是这样无法得到一个 SOA — 您只不过是有了一个 CPU 效率更低的毛团。
什么是代理?
您可能已经听到某个开发人员在讨论 SOA 时提到了代理。我比较喜欢我们一个企业架构师给这个术语下的定义：“代理是一块非常低调的代码，它只调用一个服务。” 她还将代理称作 “业务管道(business-to-plumbing)” 接口。前面提到，SOA 的主要优势是它让程序员可以在概念层次上与信息处理服务打交道。每个 Web 服务都有一个 HTTP 地址与之相关联，在使用服务之前，必须打开到该服务的一个连接。在此基础上，Web 服务消费程序的开发人员很可能更愿意面对一个对象，而不是一个 XML 模式。打开连接，将 XML 模式映射到一个对象，等等之类的 “脏活” 是由代理来执行的。
服务消费程序和代理是紧密耦合的。服务的 WSDL 描述可能发生变化，这时我们可以只修改代理 — 而不必修改服务消费程序。而且，如果 WSDL 根据服务的一个新功能作出了调整，而服务消费程序不需要那样的服务，那么甚至连代理都不需要修改。
我喜欢把代理比作我的侄子，他知道他家附近有一家骑自行车就能找到的书店。我知道那家书店有一本有用的书，我也知道这本书的价格。于是我告诉我侄子这本书的书名和作者，再给他买书的钱，然后让他去帮我把那本书买回来。他是如何去那家书店的?当他到了那家书店时，他如何找到那本书?他如何把那本书带回来?这些我统统不知道，我也不关心这些 — 我甚至不知道这家书店在哪儿。我只是想要这本书，我让我侄子去处理把这本书带回给我这中间的细节。(顺便说一句，之前我曾经把代理比作 “一块非常低调的代码”，这种比喻现在可以退役了。我有好几个侄子，他们都是很聪明的家伙。)
敏捷性与质量共存
即使应用程序架构是单块式的，也可以将基于应用程序的新产品快速地推向市场。然而困难之处在于这样做的同时还要将服务质量维持在客户期望的水平。组件之间紧密耦合的应用程序往往很脆弱，您很难做到改变其中一部分而不破坏其他部分。由于 SOA 具有高度抽象的特点，它让服务消费程序的开发人员不必关心底层系统和数据结构，对服务提供端的改变不会影响服务消费程序。您可以改变数据库模式，改变程序的语言，改变服务器平台 — 这都不会改变服务消费程序中的东西。
SOA 还通过数据自治提高了质量。原子级服务被组合成服务 “节点”，每个服务组都有自己的一组数据库表(如果应用程序使用一个数据库 — 注意，“属于” 不同服务节点的表只能是逻辑上分开的，它们实际上还是在一个物理数据库中。)规则如下：如果要访问属于服务组 ABC 的一个表中的数据，那么只能通过服务组 ABC 中的某个服务来访问它。有了这种方法，当数据库模式发生变化时，需要修改的程序就会少一些。
不是零和游戏
传统思想认为，一个企业不能同时在成本效益、质量和敏捷性这三个方面都取得很好的成绩。人们会说，您可以动作很快，并且以很低的成本提供服务，但是不能妄想在质量方面也取得领先地位;或者，您可以快速推向市场，同时有较高的质量，但是又离不开高成本。然而，SOA 就有这个潜力来打破传统：
成本效益。是的，SOA 可以增加服务器利用率，但是它还为将不同的应用程序服务平台与数据服务平台有效地组合起来交付服务提供了便利，这使得企业可以真正使用正确(价格适宜)的工具来做正确的事情。在此基础上，服务器硬件和软件的购买成本只是与企业应用程序相关的花费的一部分。另外还有代码维护和升级成本，作为 SOA 一个关键方面的技术抽象确实有积极的影响。
质量。正如我前面提到的那样，SOA 使应用程序没那么脆弱。更多的代码将远离由于新服务开发和新服务器技术的部署而导致的变化，所以当您的企业响应客户需求的时候，很少出现服务遭到破坏的问题。
敏捷性。前面提到，转向 SOA 的过程背后发生的范例变迁(真烦人 — 又提到这个词)更多地与敏捷性有关，而与其他事情关系不大。如今企业的转换步伐(我不在乎您谈的是大型企业还是小型企业，私有企业还是公有企业，金融业、制造业、运输业还是其他行业的企业)在几年前看来只能用令人晕眩来形容。这是一场赛跑，在这场赛跑中，落后的企业就会跟不上潮流。SOA 可以提高企业的适应性，让企业能够走在其他企业的前面，为其他企业树立标杆。
如果把您的 IT 企业比作一个三条腿的凳子。那么您肯定希望所有这三条腿 — 成本效益、质量和敏捷性 — 都够强壮，对不对?SOA 可以帮助让这个设想变成现实。您已经知道了关于 SOA 的一些概念和术语，并了解到它不断发展的潜力。那么，现在就与您的应用程序架构师同事一道，开始构建吧!