【IT168 专稿】

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

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

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

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

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

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

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

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

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

    轻量级的优势

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

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

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