将 SOA 经验应用于 Web 2.0 实现

两位 IBM 杰出工程师，Kyle Brown 和 Rachel Reinitz，在这篇新文章的开头对现有 Web 2.0 方式进行了快速讨论：

新的技术忽如一夜春风来，突然间我们过去所做过的所有技术都过时了并将被淘汰。乍一看，新的 Web 2.0 技术也将步此后尘。这些技术的硬派支持者将会告诉你,，你需要把所有的 SOAP 服务都扔掉了；使用 SOAP 和 WSDL 来构建不仅会使得你的项目时间变得更长，它们更不会带来任何益处……尽管 REST 简化了对某些类型服务的构建——特别是那些对外、面向 Internet 或 Ajax 客户端的服务，但仍然还有许多服务会通过应用 SOAP，WSDL，以及 WS-* 规范而获益。另外，取决于你所拥有的 SOAP 服务的类型，你可以通过将你的服务转化为 REST 服务来拥抱 Web 2.0；特别对于面向数据的服务更是如此。

他们还描述了几个主要的企业级 SOA 的经验教训可以如何被运用于 REST 实现。

支持新兴业务模型是 SOA 的主要卖点之一，通常是通过提升企业业务流程的灵活性来达到，以此帮助企业进入新的市场或领域。同样的，Web 2.0 技术提供了新兴的接触客户和业务伙伴，与之沟通以及进行协作的方式：

Web 2.0 的概念可通过几种方式被用来驱动新型的业务模型。业务可构筑社区，允许用户成为关键数据的生产者，围绕用户构筑生态系统，寻求与用户沟通的新途径，并支持将信息“混搭”成新的形式或视图……这当然是一种简化，但如果你只将 Web 2.0 看作是关注于富 UI，Atom feed 以及 RESTful 服务的“炫”技术的话，你就错失了 Web2.0 是如何被用于带来根本性业务变革的。

联系业务。一个成功 SOA 实现的一个主要先决条件就是，通过简明扼要的将实现所需投资和投资回报 (ROI) 两者联系起来，实现业务－IT 的对齐。

……对于可能的业务价值你需要越具体越好，最好是，对 Web 2.0 的采用提供预计的投资回报……业务方未必会像开发者那样为新技术而感到兴奋。因此，为了促使 Web 2.0 起航，你需要能够以他们的方式 (就像你对开发者所做的那样) 来联系业务方。

从一个坚实的方法论基础来驱动采纳。另一个关键的 SOA 成功基石是从 SOA 方法论基础而来的实践，过程以及规则。作者引用了面向对象建模与构架 (SOMA) 和组件业务建模 (CBM) ，将其作为让业务用户参与进来并帮助他们理解业务与 IT 对齐的手段。为了达成这一目的，Web 2.0 将需要一个由现有 SOA 和面向对象设计方法演化而来的坚实的方法论基础：

……需要有一种方法来发现 Web 2.0 应用目标的群体，以及找出他们通讯风格的方法……同时还需要定义利用这些群体来帮助你评估服务，从而得到业务价值的方法。同样地，需要更改或扩展 SOMA 服务发现机制，以及服务“石蕊测试”来找出那些适合于应用集成的服务与适合于支持富 Internet 应用的服务之间的区别。

明确愿景，建立路线图，贯彻计划。成功的另一个先决条件是拥有一个整体的愿景并朝着这个愿景执行计划：

如果你只关注于 Web 2.0 的愿景和路线图 (包括实现基础设施和框架项目) 而缺少“真正”项目 (深入生产并交付业务价值)，那你就冒着实现出一个无法满足项目需求的基础设施和过程的风险，也使得项目团队更难遵守路线图 / 架构 / 框架。如果你启动一个单独的 Web 2.0 项目而缺少一个愿景和路线图，缺少一个通用框架，你冒的风险是交付更少的价值，重复劳动，在项目中未能对代码进行重用，并且无法构建通用的基础设施和过程……早期项目不必大到要交付价值，但通常应当是能为从新的技术和业务模型获取经验而提供机会。

不要忽视治理。已经有足够多的文章强调 SOA 治理的重要性：

我们从以前运用 Web 2.0 原则构建的应用中所看出的是，Web 2.0 的治理将会更富有挑战，因为 Web 2.0 采纳的关键方面在于社区内自由的通讯，协作，以及信息共享。由于我们暴露了 RESTful 和 Atom 服务，问题变成了：我们如何控制却不限制对于这些服务的使用和用户资产的开发？如果构建一个社区的社会性方面受限于一个太过于限制的治理流程，那这一社区将不会兴旺。然后，我们太容易看到在线社区由于不够或不当的治理而受损害了；太容易被“废品”所掩埋而不能够彰现出那些真正存在的有价值的内容。

对于企业级 SOA，简单而言，有影响力的 Web 2.0 实现是将企业整体作为目标。结果，由成功的以及失败的SOA 实现所得出的经验都可以被应用到许多Web 2.0 项目。

查看英文原文： Applying SOA Lessons to Web 2.0 Implementations