【IT168 分析评论】

    一直以来，人们就有建立SOA和Web 2.0之间关系的想法。但是，Dion Hinchcliffe 写道：

    ……这两种文化通常无法象它们应该的那样交叉授粉，尽管可能有的特别机会。

    从架构的观点来看，一些人刚刚开始寻找两者匹配的方式。在这篇文章中Ganesh Prasad（大型金融机构的资深架构师），Rajat Taneja和Rhys Frederick（两个都是咨询师）通过定义SOFEA（service-oriented front-end architecture，面向服务前端架构）细化了他们关于如何关联SOA和Web 2.0的分析。
    过去的几个月中，Mashup框架开始成为沟通两者的桥梁，一些来自如IBM或WSO2这样公司的新产品主要关注于关联Web 2.0用户体验和RESTful或Web服务的消费。
    二月初，Apache Tuscany项目通过促进服务和Web 2.0用户界面装配打开了结合SOA和Web 2.0的新途径。
    通过开发Atom发布协议（它暴露RESTful服务来管理一组资源），企业联合组织领域的相关问题已经被解决到了一定的程度。但是一些人注意到了在企业中更加广泛利用的限制。
    有人会说，我们只是刚刚开始集成SOA，Web 2.0的其它方面，例如协作（wiki、标签、博客）、搜索、广告或文件共享，依旧有许多值得探索。

    Optaros，一家总部位于Boston在欧洲有办事处的咨询公司，实际上已经做了深入探索，并开发了一套关注于尽量利用开源软件交付Web 2.0 + SOA解决方案的实践。
    InfoQ采访了Optaros的Marc Osofsky和Dave Gynn以进一步了解细节。

    InfoQ: 你们如何看待Web 2.0在企业中的应用？
    Dave: 我们称之为“下一代互联网”。尽可能扩展Web 2.0。社会方面，读/写，富用户界面，更多的网络感知组件（不仅仅是单块应用）。
    过去，一个页面通常来自单个应用。现在，我们注意到用户交互实际并非是一个来自不同服务器的页面。人们对一些更简单的接口感兴趣：REST接口，一些人期望将来与之交互。Ajax驱使你思考给页面提供数据的方式。以及JSON用做格式化。
    Marc: 在交付层面，Web 2.0技术的关键是使用户体验和架构都达到最优。客户通常无法完全清晰地说出它的需求。这些技术能快速搭建原型，这使得用户能对之反应并给出新的想法。这的确非常有效，以致我们能够创建一个固定时间、固定价格的业务模型。
    Web 2.0和SOA之间存在有极大的协同效应。我们留意了其它单独使用SOA或Web 2.0的系统集成商，系统花的时间要更长一些。

    InfoQ: 在企业中开源和更通用的组件重用的影响是什么？
    Dave: 4年前，Optaros的创始人就意识到OSS将力量由ISV转移到了使用者的身上。这种转移将会改变咨询公司的机会环境，并要求一个新的交付模型。
    我们的目标是将项目预算集中在那些对客户来说真正造成差异的地方。一般来说，项目的80%可以使用低成本商用组件交付，而20%是特定于这个用户的。
    开源引入了一个新的重用模型。在任何一家公司，应用通常使用一次。这意味着，在公司内真的很难创建一个围绕一些代码的社区。
    在Optaros，我们重用整个解决方案，SOA中间件组件如Mule，内容管理系统使用Drupal，Sugar CRM。

    InfoQ: 关于你们的解决方案和组件选择的方法，你们能给我们一些细节吗？
    Dave: 今天，你们仍在试图重用一个整体解决方案，而不是服务个体。服务仍然难以找到，尽管越来越多的应用开始提供好的服务接口。    例如，我们还没有谈论内容管理服务；我们仍在着眼于实现内容管理解决方案。
    我们的方法论由产品和组件评估开始。在此，我们采用了全新的方法；我们寻找那些试图解决同样问题的人们，并识别他们正在使用的解决方案和组件，而不是评估一个标准矩阵。
    例如，我们有一个客户是一家大学。他们雇用我们帮助他们实现一个内容管理系统，我们比较了他们和另外一个客户的需求，这把我们引向了Sakai。
    Marc: 在Wonderbox [他们完成的一个零售项目，结合了商店前端、CRM和后端集成]项目中，我们采用了一种对许多零售店都普遍的方法。我们使用装配、动态脚本语言和Web 2.0（RIA、Ajax和Streaming）完全地“重建平台”。我们在内核部署了一个请求代理，放置了一个他们基础设施的包装器，并开始迁移他们的后端服务。我们全部使用开源组件：OS Commerce，Sugar CRM管理BOM并跟踪使用和付费。我们使用Mule ESB将所有服务连接起来。

    InfoQ: 使用开源SOA基础设施你们有什么心得？
    Dave: 以我们的经验，你可以从让你的中间件保持厂商中立过程中受益，如你可以得到对标准更好的支持。也使你对厂商的依赖更少：如果你将你的基础设施连接到了一个厂商协议，那么你就背离了SOA的观点。当然，从成本的角度来说，你还会有所收获，因为开源组件是免费的或是成本非常低廉。
    随着时间推移，开源组件倾向于集成任何东西，而一家特殊的厂商并非总会这么做。
    开源软件的关键优势是在项目的前期阶段。当人们做一些概念验证时，他们会使用一个开源组件作为替代物，之后在同一地方他们可能会购买产品。但是客户通常最终会保留这个开源组件，这一点对于ESB特别适用。
    人们使用服务来获得他们的应用不同部分的好处的一个好的案例是SwissCom Hospitality，一家酒店的无线提供商。基于PhP的前端。开发和修改前端，但是他们期望后端服务使用Java，使用第三方服务（代理，数据缓存）。我们使用了Web服务在PhP和Tomcat容器之间穿梭。
    Marc: 像Symphony或Python这样的脚本语言伸缩非常有效。我们开始留意使用这些技术的高流量网站。对我们来说，关键是它们能够与用户体验设计者一起快速的搭建原型。我们可以在几周内展示功能完全的站点。SOA代理和容器也非常成熟，这儿我们没有看到太多的问题。依我们看来整个SOA方法正展示企业级的强度。
    我们认为缺失的东西更多的是功能组件。例如，可以管理全部商店前端价格和产品信息的“商人桌面”。这常常是一个自定义组件。从SaaS观点来看，我们所看到的这一缺失领域是订单管理检验过程（checkout process）的核心。有些解决方案提供这一组件，但是它与表现层紧密地耦合在一起。
    在WonderBox案例中，我们在不到半年的时间内设计和实现了一个新平台。提高交付你的体验的速度是关键，因为在零售业，你有6到9个月时间来改变任何东西。对于假期季节，系统必须保持稳定。

    InfoQ: 你们能告诉我们你们开发的方法论和使用的工具吗？
    Dave: 我们的方法论结合了敏捷方法和固定范围。你必须关注重用和装配组件，远离自定义组件。在非常早期，我们关注识别我们可以得到的解决绝大多数问题的组件。我们尽量最小化我们书写的代码。
    当某些我们的开发包含着并非单个客户的特定差异，即具有一定的普遍价值，我们常常试图将其回馈给开源项目。例如，在ActiveMQ还没有一强大的死信处理能力的时候我们正在使用它。我们为ActiveMQ写了一个死信处理，并将这个使我们客户受益的特性提交回了这个项目：当下一个发布出来的时候，他们就不必经历一次大的升级，并且随着时间推移他们受益于错误修复和性能优化。对于客户和开源项目，这确实是一个双赢的情形。
    我们试图尽可能的使用开源工具，因为要移交给客户。