2009年伊始，Burton集团副总裁AnneThomasManes在Blog中声称“SOA已死”。他写到“SOA曾被认为是IT的大救星，现在却证明是一项极其失败的试验——至少对于大多数组织而言如此。SOA被认为能大规模降低成本和增加机动性。但除了极个别情况，SOA并未兑现它承诺的好处。在投资百万后，IT系统并未得到改善。许多组织的情况更糟：成本增加、项目延期，系统比以往更脆弱。手握钱袋的人们对此已感到厌倦。鉴于2009年的预算紧缩，许多组织消减了他们SOA项目的资金。”

　　此后，关于SOA生或死，能否拯救IT的讨论不绝于耳。然而，事实上，AnneThomasManes想表达的真实意图在传播的过程中不仅被忽略，而且被变形扭曲，连标题也遭断章取义——“SOA is Dead;LongLive Services”。

　　Anne Thomas Manes开宗明义的第一段如下：SOA met its demise on January 1,2009,when it was wiped out by the catastrophic impact of theeconomicrecession. SOA is survived by its offspring: mashups, BPM,SaaS,Cloud Computing, and all other architectural approaches thatdependon“services.”（2009年元旦，SOA遭遇死亡，经济衰退的灾难性影响彻底摧毁了它。SOA由其后代得以延续：mashups、BPM、SaaS、云计算及其他依赖“服务”的架构方法。）他在文章中指出，Peopleforgotwhat SOA stands for. They were too wrapped up in sillytechnologydebates (e.g., “what”s the best ESB?” or “WS-* vs.REST”), and theymissed the important stuff: architectureandservices.（人们忘记了SOA的目的，沉醉于愚蠢的技术争论。如“最好的ESB是什么？”或者“WS-*火拼REST”，却遗忘了重要的内容：架构和服务。

　　SOA专家劳虎（http://space.itpub.net/16186206/）在其博客中也谈到自己对ATM言论的看法，“这又是一个经过炒作后，整体信息中负面的部分被不等比地放大，再以讹传讹的经典教科书案例。作者AnneThomasManes（ATM）原标题中的第二句“”LongLiveServices”服务万岁”被拿掉，广大的群众只看到标题的第一句。”“如果服务真的万岁，那支撑它的架构怎么会死？真正死的只有缺乏businesscase、”为SOA而SOA”的项目。”

　　近日，Sun公司的AsheshBadani和JerryWaldorf再次撰文，从未来技术角度预测SOA的未来，那将是即将迎来的光明。

　　作为一个用户，相信你对网络客户端肯定很熟悉。通过HTTP和XML，你无需在自己的计算机上安装程序便可以使用外部的数据——你所要做的只是打开一个浏览器窗口，然后便能进行搜索，或者访问某个网站寻找你所想要的信息。

　　企业内部的数据与应用共享却比这复杂得多。企业SOA供应商添加了能够利用多种规范的高级工具和功能，从而使得小型项目更难利用这些功能。虽然软件是基于开放标准的，但只有了解相关的各种标准才能利用其中的数据。比如，一个部门经理想获取另一个部门的客户数据，但是发现数据寄存在一条专有的中间件总线上。这样，如果她想对其进行访问，就必须在她的服务器上安装同样的中间件并对员工进行培训才能进行软件管理。而且，她还要向供应商支付维护费用。

　　但是，在网络上就不存在这种障碍。你可以去谷歌地图这种网站，创建一个组合应用，然后通过Facebook发送给你的联系人。如果你需要数据，你可以直接通过开放的API访问到数据源并以合适的方式使用。企业也需要有这样的条件。网络服务开发人员必须在安全方面有限制的REST式架构和虽然安全性很高但部署也很繁琐的传统的网络服务标准之间作出抉择。而且在REST式界面中，即使只加一个登录功能，复杂性也会大大提高。

　　我们需要的——也是SOA的目标——是一个使用标准协议和简单的访问管理便可以直接访问数据的界面，以及为任务选择合适工具的能力，比如合适的网络服务或适时使用的REST方法。

　　轻量级的优势

　　因为各个部门并不是在做任何工作时都要使用全部的企业组件，所以可以大幅度地提高工作效率。比如，处于不同国家的某部门的一名雇员要访问另一部门的系统，他就可以使用HTTPGET（当然前提是他有这个权限）来读取XML文档中的数据。

　　而在开发人员方面，一则对组合应用与数据的需求越来越迫切，二则他们还要快速地实现这些新服务，因此IT部门很早以前就开始寻找新的方式了。比如，一个项目团队需要在两个月内开发五个新服务并进行测试和部署，他们可能会发现，由于企业平台的复杂性，这个任务几乎是无法准时完成的。如果他们能有一个包含了数据服务和验证管理的框架，那么他们就能节省大量的时间，并准时完成任务。

　　由于上市时间已经成为应用设施项目成功与否的最关键标准，未来的SOA需要以更短的时间完成更多的应用设施——并且不能提高多余的复杂性。

　　元数据的重要

　　元数据发现也是这个轻量级架构的关键组成部分之一。许多SOA平台已经发展成了包含大量服务定义的存储库——服务定义放在注册库里，与实现分离。从网络的经验我们可以知道轻量级目录的优势。比如谷歌和雅虎可以让我们搜索所有的资源信息，而无需先将这些信息整合到一起。我们先搜索信息，然后才被指向到信息源的最新版本。服务注册也可以使用这种结构。我们可以部署一个轻量级的服务地址目录，并让这个地址指向实际部署的服务。

　　当然元数据仍然很重要。我们需要改变的只是换成轻量级的方式。服务的元数据（服务能提交什么数据以及可以使用什么数据）要和服务部署在同一位置，以免导致数据不同步。像WSDL、WADL等轻量级规范可以与元数据绑在一起。这样，所有这些地址放在了一个可以进行搜索的轻量级目录中，从而实现了适度的集中化，也不会拖慢发展速度。不过，这一领域还要做不少工作来提高轻量级的标准，进而满足REST资源中元数据封装的要求。

　　云计算的应用

　　不难预测，越来越多的网络服务将是面向云的。这样企业开发人员就需要一个可以创建安全的网络服务并通过因特网或云进行访问的框架。一个可以被外部团体访问的轻量级的服务需要基于外部身份验证的访问控制机制。这正是需要把验证架构扩展到全局范围的的地方。有些WS协议就是为了解决这个问题的。然而，要在REST编程模式中应用简化的外部身份验证模型还需要另外做一些工作。新的验证结构还要保证REST资源的编程用途。

　　企业也可以选择开发并保管一些具有内部优势的应用，而把其它任务关键性较小的应用寄放到外部云中。而这两部分也需要能够互相沟通。比如，某公司可能会需要让Salesforce.com能够使用寄放在内部Oracle或SAP应用中的客户信息。面向REST资源的统一的安全性编程模型可以为开发人员提供一致的资源访问方式–不管资源来自什么地方（企业内部或外部）。这正是轻量级的安全模型发挥作用的地方。

　　当前所有SaaS接口几乎都使用非标准的资源访问方式，使得原本简单的组合应用即可解决的问题变得更加复杂。把来自不同资源的数据组合到一起是一件简单的事，但是要把对不同资源的所有不同的验证方式组合到一起却不简单。

　　验证管理是关键

　　如果开发人员要创建能为不断扩大的人群提供数据存取的网络服务，那么验证管理是关键。当用户提供访问网络服务的验证信息时，就必须有验证这个服务是系统一部分的措施，以保证用户的请求合法——就像用信用卡购物一样。如果你只能在信用卡发行单位的ATM机器上使用自己的卡，那么这就是个重量级的模型、非分布式的安全性模型。但是信用卡发行单位不会这么做，他们允许你在任何地方使用并向商店保证你的信用。

　　与此类似，网络服务如果使用这种分布式模型也可以允许开发人员得到更多的好处，让他们把重点放到服务上而不是安全信息的验证上。如果不把验证管理的功能嵌入到产品里，那么网络服务就得以轻量级的标准与验证管理软件对话，而这正可以让开发人员专注于服务产品的开发。

　　更好的移动性

　　最后，由于各种显示设备——桌面、笔记本、移动设备和机顶盒——对网络服务的需求不断增长，开发人员也需要一个能够满足所有这些需求的足够简单的应用基础设施。这里的重点是对数据的快速访问和更智能的对数据库表的多次快速读取。企业应用以”多功能”为重点将成为过去，适用于多种显示设备——特别是移动设备——的轻量级Web-Scale应用将越来越受到关注。

　　比如，iPhone或黑莓可能成为下一代网络发布平台，或者提供可以发布特定目标的广告或信息的情景智能。但要创建这样的服务，开发人员必须能够轻松地利用数据服务和验证管理功能，而可以同时满足这两点的轻量级的框架正是理想之选。

　　更简单的框架

　　要使企业能够交付更多的、安全的网络服务，并迅速而方便地利用企业中的数据，就需要一个更简单化的、面向小型项目的SOA框架。

　　Web-Scale将成为企业的新目标。随着轻量级标准的发展，我们相信企业开发人员很快就能够拥有一个既可以帮助他们极大地提高开发速度又能简化网络服务的设计和部署工作的更简单的平台。