首席信息官（CIO）和系统架构师们为了在企业里部署复杂的服务导向架构（SOA），有时候真可谓是殚精竭虑不遗余力，但到头来等待他们的仍是一股深深的挫折感。“只要你建好了，自然就会有人用，”这种自上而下的SOA部署策略往往是以失败而告终，并且有时还失败得相当惨烈。企业投入巨资好不容易把SOA部署妥当了，但员工们却对它不感冒，因此业务流程与IT部门的接轨也就无法实现了。至于部署之前那些诱人的投资回报率，那更是想都不用去想。
大多数失败的部署都告诉我们这样一个教训：简为佳。越来越多的公司发现，根植于底层运作的网络导向架构（WOA）虽然能见度较低，但却是通往顺利部署SOA的一个更好途径。与SOA类似，WOA也是对系统设计的一种架构，只不过它是以资源为导向，而非以服务为导向。这两者之间有何区别呢？SOA设计的核心单元是一种能够满足独特业务功能的重复使用型服务，而资源导向型服务则专注于数据，并且存在较大的局限性。
SOA和WOA所作用的抽象层面也有所不同。前者是一种系统层面的架构模式，致力于实施可被多种应用程序消化的新业务功能；而后者则是一种接口层面的架构模式，专注于各种服务功能以何种方式提供给应用程序。然而，不管是通过SOA还是WOA交付的功能，其治理方式、服务质量和安全性能都具有同等的重要性。
虽然有些权威人士声称，只有初创企业和以网络为中心的公司才会支持WOA，但国际商业机器公司（IBM）的WebSphere产品部首席技术官（CTO）杰里•丘沃莫（Jerry Cuomo）却通过Project Zero向世人宣告，他也是WOA的拥护者。Project Zero是IBM的一个以WOA为基础的框架，目前正处于测试阶段，预计将于今年晚些时候作为产品发布。丘沃莫借帮助自己12岁的儿子做功课的例子，生动地描述了WOA的神奇魅力：
“我的儿子决定，要把他的作业做成一个网站。经过一番简单的培训之后，我成功地教会了他如何使用谷歌公司（Google，下称谷歌）和电子港湾公司（eBay，下称电子港湾）的服务，他甚至还可以在所谓的作业中放置一些横幅广告，这让他感到非常有趣。谷歌和电子港湾的网络应用编程接口（API）支持简单的REST URL，利用这些服务他可以轻松地剪切和粘贴所需的代码，将自己的网站连接到谷歌和电子港湾强大的SOA上。而更令他兴奋地是，几个月后，他竟然从作业中的广告上获得了5美元的收入。这对于孩子做功课是一个多么大的动力啊！”MindTouch公司的创始人之一、CTO史蒂夫•比约格（Steve Bjorg）也是WOA的铁杆拥护者。MindTouch公司主要致力于研究如何将开源Wiki协作及内容管理平台与IT治理结合在一起。该公司于2007年推出的产品Deki Wiki目前已被包括联邦快递公司（FedEx）、富士通公司（Fujitsu）、甘尼特公司（Gannett）、微软公司（Microsoft，下称微软）、西门子公司（Siemens）以及美国军方在内的多家大型企业和组织所采用。“通过走网络导向服务与表象化状态转移（Representational State Transfer，REST）相结合的路线，扩展应用程序的要求大大降低了，” 比约格说，“那些带有复杂WSDL文档和SOA注册的简单对象访问协议（SOAP）处理栈不存在了。现在人们可以利用任何计算机语言轻而易举地开发出Deki Wik的应用扩展。”
有些公司担心WOA不能完全替代SOA，但事实上，它们是两种互为补充的架构风格。在某些情况下，只要WOA就能满足企业的需要。而在其他情况下，你可能需要升级扩展到SOA层面。但有一点可以肯定的是，如果没有做好准备，千万不要鲁莽地部署SOA。
SOA似乎有一个奇妙之处：用多种语言编写的运行在多种平台上的应用程序，在SOA下看起来就好像是用一种语言写成的运行在同一平台上的程序一样，难怪它对于企业用户有这么大的吸引力了。分布式计算往往被认为是编程的理想境界。一些软件行业的巨头，如IBM、微软和太阳公司（Sun）等，都在这一问题上进行了20多年的研究，并且各自取得了不同程度的成功。截至目前为止，SOA是业界为解决分布式计算问题而做出的最新、也是最伟大的一种尝试。不过，那些基于Corba、DCOM和Java/RMI标准的方法在此前遇到过的难题，如今仿佛也同样困绕着SOA。
对于SOA号称能带来的投资回报率，一些IT专家也表示了怀疑。2007年，《信息周刊》对278位IT专业人士进行过一次调查，结果32％的受访者表示，在部署完SOA后，该项目达到的效果要低于期望值；58％的受访者认为，SOA给他们的IT环境引入了更多的复杂性；另外，还有30％的人说，SOA的项目成本超过了预算。只有10％的受访者觉得SOA的效果超出了预期的目标。
核子研究公司（Nucleus Research）2007年8月份发布的一份报告证实了《信息周刊》的调研结果。该报告指出，在106家公司中，只有37％表示在SOA技术和编程上的投资实现了预期的投资回报。今年早些时候，伯顿集团（Burton Group）分析师安妮•曼妮丝（Anne Manes）就SOA目前的商业价值表达了类似的否定意见，她说：“到目前为止，在我所采访的所有公司中，能称之为成功部署了SOA的公司只有一家。”
那么，怎样才能顺利部署SOA呢？让我们来看看从WOA出发来部署SOA会为我们带来何种惊喜。SOA与Web服务
很多人都将SOA和Web服务混为一谈。事实上，SOA是关于设计方面的，而Web服务则是一套支持分布式计算的具体技术机制。Web服务让开发人员能够轻松地创建基于服务的系统，但前提条件是开发人员使用的是SOA的设计准则。在此准则之下，各种功能被打包成模块化的、可共享的分布式服务，它们可被多个应用程序重复使用。如果开发人员做不到这一点，那最终得到的只是一些受限的非集成应用程序。
2000年，IBM 和微软推出了第一代的Web服务中间件框架，也就是所谓的Web Services Framework（以下简称WSF）。WSF基于一个非常小的规范集合，其中包括SOAP、Web服务描述语言（Web Services Description Language，WSDL）以及通用描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）。一开始，开发人员对于这个Web中间件框架的简洁性赞誉有加，但随着时间的推移，WSF在经过多次完善和检审之后，目前必须支持的规范数量已经增加到了50多个。
为了应对WS-*标准的复杂性和流动性，一小部分颇具影响力的企业架构师已开始支持返璞归真的WOA架构方法，在HTTP协议之上使用古老而简单的XML。这种方法是基于万维网（World Wide Web）和REST背后的架构，它要比WS-*标准简单得多，不过却没有它们灵活。
对于某些领域，如安全性和可靠邮件传输，WS-*有一套标准的信息格式和定义参数，而WOA方法则意味着业务功能有时是被硬编码到组织的基础设施中。为了弥补这方面的缺陷，WOA的支持者提出了一套基于REST原则的最佳实践，如使用统一接口访问所有的应用程序资源。最看好这套方式的倡导者自称是“REST一族”，他们甚至声称REST是几乎哪儿都能用得上的“万金油”。
关于WOA和SOA的争论是没有完全必要的。很明显，REST和WS-*风格的SOA都有属于自己的一片领地，所以IT部门应该将重点放在架构问题上，而不是抓住部署细节不放。亚马逊的案例
开发人员对基于REST的轻量级Web服务表现出了极大的热情，这从各种各样的网络投票结果就可看出。2003年，亚马逊网站（Amazon）首先在网上进行了公开测试，比较亚马逊网络服务（Amazon Web Services）的两个接口——SOAP 和 REST的受欢迎程度。最终85％以上的开发人员都选择了REST/ WOA接口，亚马逊Web服务主管杰夫•巴尔（Jeff Barr）说。
“REST很容易演示——只需把一个网址加载到浏览器上即可，”巴尔说，“结果是显而易见的。人们看到操作过程如此简单，当然会为它投上一票。”
从那时起，亚马逊的策略就发生了变化，它开始为开发人员提供极大的自由，无论他们是在公司的防火墙内部还是外部，几乎都可以不受限制地访问其产品数据库。如此一来，亚马逊网络服务当然就像野火一般烧遍了业界。今年1月份，亚马逊的首席执行官（CEO）杰夫•贝索斯（Jeff Bezos）表示，如今亚马逊网络服务消耗的带宽比亚马逊全球所有零售网站的总和还要多。
亚马逊的Web服务平台还可激发开发者及合作零售商的创造热情，它最近发布的几款产品就是明证，如简单存储服务（Simple Storage Service，S3）和Mechanical Turk。S3是一种在线存储服务，新兴公司和企业客户可以用它来进行Web托管及备份；Mechanical Turk则可通过网络帮助大型企业协调内部的各个工作单元。
现在，成千上万的独立网站都整合有亚马逊的产品数据和编程工具，由亚马逊前程序员艾伦•泰勒（Alan Taylor）创建的Amazon Light就是其中之一。其他使用了亚马逊网络服务的新兴网站典型还包括WeoGeo和TuneCore。前者的业务是销售定制地图和航空图像，而后者则主要从事独立音乐的上传业务，它把这些音乐转发给iTunes、 亚马逊 MP3以及其他一些数码零售商，从中收取一定的费用。你只需每年支付一笔为数不多的维护费用，就可以使用这些服务。
除了利用到REST设计理念外，以上提到的TuneCore和WeoGeo两家网站都是用Ruby on Rails（RoR）框架来开发的。该框架与Java语言的Restlet和Python语言的Django一样，都整合了基于REST的多种模式和功能。这些框架让开发者在整合网络资源时，能更轻松地进行基本的数据库操作。举例来说，最新版的RoR框架在HTML工具等各个较低层面上都添加了REST技术，使得解析URL、XML和JavaScript对象符号（JavaScript Object Notation，JSON）变得更加简单了。JSON是一种颇受网站和新兴企业追捧的轻量级数据交换格式，但在大型公司中尚未获得普及。作为XML的轻量级替代者，JSON无需繁冗的标记语言，就能将数据存储到磁盘上，或是通过网络传输数据。
RoR框架的这些能力为它赢得了众多支持者。开发人员尤其喜欢RoR，因为它可以对本地或企业数据库模式进行分析，并能自动生成处理网上数据的多种方法。对于创建遵循REST应用程序架构的WOA服务来说，RoR框架是一个很好的选择，不过，在开发基于SOAP和WS-*标准的Web服务上，它的作用就比较有限了。双R组合
人们一贯认为WOA应用程序只适用于简单的数据库操作，对于企业级的性能改善却无能为力。这似乎正是利用RoR框架创建的社交网站Twitter目前所面临的主要难题。今年早些时候，在美国旧金山召开的苹果展览会上（Macworld Expo），苹果公司（Apple）的首席执行官史蒂夫•乔布斯（Steve Jobs）在主题演讲中使用Twitter网站的服务时，屡次遇到故障。这一事件让终端用户对该网站的信心大减，他们都对Twitter的现状和未来都表示了担忧。许多专家都建议，Twitter网站应该停止将RoR用作Web框架，转而利用Java或PHP重新开发一个框架。
虽然反对者众，但有一人仍然力挺RoR，劝告Twitter不要放弃原有框架，他就是Java和RoR专家布鲁斯•塔特（Bruce Tate）。塔特认为，REST应用程序能够随着RoR进行调整，并且效果还不错。“开发人员不应当在系统的规模上纠缠，”他说，“他们应该把精力集中在生产力上。”
虽然塔特承认，RoR可能永远无法像Java那样升级调整，但他仍坚持这一框架会很快走向成熟。“新的虚拟机将为此提供极大的动力，”塔特说，“我的看法是，解决问题应当对症下药。如果你在生产力方面没有问题，那么就没必要使用RoR。如果你所面临的问题与技术不相关，那也就不需要寻找技术性的解决方案。但是，假如提高生产力是你的重要目标，或者你正在创建受数据库支持、具备SOA特征的Web应用程序，那RoR和REST的组合就能给你帮上大忙。”
REST与SOAP之争
致力于IT和业务转型的全球服务商Keane公司的企业架构师艾德•里昂斯（Ed Lyons）表示，如果亚马逊、谷歌和雅虎都从SOAP转向了REST，那么其他公司就应该考虑考虑随后跟进了。
“我对大型企业客户说，他们的需求不可能比资产超过300亿美元的亚马逊等互联网公司还大，”里昂斯指出，“就大多数时候而言，人们根本用不到像SOAP WS-*规范这么复杂的东西。简单的标准虽然不能涵盖一切，但它的用途也很广泛，其效果也会更好。”
当被问及开展业务转型的最好方式是WOA还是SOA时，里昂斯指出这并不是一个非此即彼的问题。WOA/REST可以说是一种自下而上部署SOA的方法，而基于WSDL的SOA则是一种自上而下的SOA构建法，如果你一开始只是想试试水，并不想一个猛子扎入SOA的洪流中，那么采用WOA/REST的方式来部署SOA应当是最值得推荐的办法。
Mozilla公司的创始人之一迈克•谢弗尔（Mike Shaver）向我们介绍了为什么Mozilla会走WOA路线，并采用MindTouch公司的Deki Wiki来作为开发者社区的未来平台。“Mozilla拥有大量与开发工作有关的信息，其中既包括传统文件和示例代码，又有测试套件和漏洞跟踪数据，还涉及到许多活跃的讨论论坛和RSS流，”他坦言说，“与我们曾考虑过的其他wiki系统相比，Deki Wiki给我们的感觉是特别适合作为Web应用程序的平台，利用它可以比较轻松地创建新的扩展或集成点。”
IT业界此前一直存在一种说法：WOA非常适合简单的专案开发，但如果企业用户想拥有安全可靠、易于管理的服务，还是需要使用全面的Web服务SOAP堆栈。现在，新一代XML硬件设备的最新进展已经向这种论断提出了有力的反驳。Cast Iron Systems、IBM DataPower以及Sonoa Systems等一系列产品可为XML的安全、加速和传输提供保障，并能使企业客户及其合作伙伴各自偏好的WOA、SOA、Web 2.0及SaaS实现共同运作。现有的SOA可以利用资源端点进行扩展，而新建的WOA则可利用以服务为导向的端点进行扩展。在多数情况下，混合系统可能会更有意义。
设计为本
正如我们一开始所说的那样，SOA的本质并非技术，而是设计。各种类型的分布式计算技术，包括HTTP/REST、SOAP、Corba、DCOM、RMI、Jini、Fax以及Telex等，都能用于部署以服务为导向的系统。但是，相对简单的REST也许会是搭建SOA架构的最佳方法，因为它强调了在端点与座机之间建立通信的重要性，而对接收机和发射机的大小、形状和组成并不在意。让端点能够开口“说话”与确保通话的清晰度和保密性，这两者的战略意义孰轻孰重，IT部门必须有个决断。不过，两者之间并不互相排斥，这只是一个优先顺序和资源分配问题。
最后，还有件事情也同样重要：如果你选择了轻量级的自下向上WOA架构法，那就无须在网络的“装饰细节”上耗费太多时间，因为它们也许迟早会被淘汰。这也就引出了设计与部署的根本区别所在：在网络时代，随着时间的推移，部署的系统本身总有一天会被束之高阁，但优秀的设计方法却是永不过时的。
