, 杰出工程师, IBM

我们以前都听说过：一项新的技术推出了，然后突然之间，所有使用较旧的技术完成的东西都变得过时，将会消失。乍看之下，新的 Web 2.0 技术似乎也遵循这种模式。这些技术的中坚分子将告诉您需要放弃所有 SOAP 服务；不仅使用 SOAP 和 WSDL 进行构建会延迟项目进行时间，而且还不能带来任何好处。事实当然并不是这么简单。

虽然通过 REST 可以更为简单地构建一些服务，尤其是面向 Internet 或 Ajax 客户端的服务，但是仍然有大量服务能通过应用 SOAP、WSDL 和 WS-* 规范受益。另外，根据您所拥有的 SOAP 服务类型，您可以通过将服务转换为 REST 服务来采用 Web 2.0；这一点尤其适合面向数据的服务。不过，把这个问题放在一边，即使您决定对服务采用 REST，也最好看看我们通过构建企业 SOA 系统得到的一些经验教训，了解如何在构建基于 REST 的服务时加以应用。我们从几个重大的领域吸取了一些非常惨痛的教训，这对与您而言无疑是幸运的。我们在这里与您分享这些经验教训，旨在帮助您避免类似的难题，成功实现 Web 2.0。

CEO（以及 CIO）的首要目标是进行创新和开拓新市场。SOA 的一个关键卖点是，能够通过将服务作为构建块提高业务流程的灵活性，从而实现新业务模型和创新。SOA 通过与业务流程管理（Business Process Management，BPM）结合，能够为企业提供最大的价值。BPM 的一个常见目标是开拓新市场或地区，加速新产品或服务的推出。与此类似，通过 Web 2.0，您可以采用之前不可能的方式触及客户及合作伙伴、与之沟通和进行协作。

Web 2.0 概念可以通过多种方式驱动新业务模型。企业可以构建社区，使用户成为关键数据的源头，围绕用户构建生态系统，寻找与用户沟通的新方式以及支持将信息“混装”为新表单或视图。eBay、Amazon.com、Flickr 和 Twitter 等企业就是核心价值和业务模型来自用户生成的数据的企业。这当然是简化的说法，但是如果将 Web 2.0 仅视为以丰富型 UI、Atom Feed 和基于 REST 的服务为重点的一项很眩的技术，那么就可能会忽视 Web 2.0 如何用于实现基本业务变更。

SOA 的一个重要成功要素是，它在两个级别同时取得了成功；它既能与业务部门成功沟通，也能与 IT 部门产生共鸣。为了实现上面所讨论的 Web 2.0 的更高级的价值，企业必须明白 Web 2.0 所扮演的转型角色以及实现所需的投资。通常，为了采用新技术，IT 需要通过将技术与业务价值结合获得企业的支持。BPM 和 SOA 之间的联系强调了业务和 IT 间需要保持一致性。最简单的方法是，首先解释 BPM 的好处，然后说明 BPM 为什么最好在 SOA 上实现。通过这样，就可以说明二者之间的补充关系。

这个成功的部分原因是，IBM 能够很好地整理出我们实现 SOA 优势的方式，并使用业务和 IT 部门都能理解的语言进行表述。这里，我们使用一些常见场景（如一系列关于电子商务模式的红皮书中的 IBM SOA Foundation 场景）来帮助以业务人员能够理解的方式说明价值。

这方面要吸取的关键经验教训是，您需要尽可能具体地说明业务价值，最好能提供采用 Web 2.0 的预计投资回报（Return On Investment，ROI）。让我们面对现实：业务社区不一定会像开发人员一样对新技术的出现表现出很大的热情。因此，为了采用 Web 2.0，您需要使用业务人员熟悉的语言与业务社区进行沟通（就像与开发人员沟通时一样）。一个示例启动场景是，使用 Web 2.0 为业务或产品构建一个社区，并以此驱动价值，如提高客户服务和品牌忠诚度。在表述这些价值方面，我们都需要更为成熟（这方面的书籍越来越多，可以提供帮助；请参见），而且我们都需要在不过度提及所使用的详细技术的前提下解释 Web 2.0。这是我们在 SOA 方面相当成功的一个方面，与能够在不涉及细节的情况下介绍 Web 2.0 的业务好处一样重要。

IBM SOA 方法即面向服务的建模和体系结构（SOMA 和 RUP-SOMA）。SOA 的另一个关键成功因素是作为 IBM SOA 方法基础的各种实践、过程和规则，及这个方法与业务建模技术的紧密联系。IBM Business Consulting 开发了组件业务建模（Component Business Modeling，CBM）并将其作为 SOMA 的关键输入。CBM 和其他业务建模方法会让业务用户参与进来，帮助他们了解业务和 IT 的一致性。SOMA 强调在服务指定和实现的全过程中与业务的一致性。SOMA 和 RUP-SOMA 并不是最初使用 Web 服务时从 IBM Rational® Unified Process (RUP) 的使用情况一下子就完全形成的，它的开发和细化经历了多年时间，而且将继续进行评估和修订。

为了成功，需要对现有 SOA 和面向对象的设计方法进行发展，为 Web 2.0 形成稳固的方法基础。例如，始终需要确定 Web 2.0 应用程序的目标，另外还要寻找确定其沟通方式的方法。正如前面提到的，对于通过利用这些社区帮助评估服务实现的业务价值，还需要另外的定义这些价值的方法。与此类似，应该对 SOMA 服务标识机制和服务着色测试 (services litmus test) 进行修改或扩展，以标识适合于应用程序集成和适合于支持富 Internet 应用程序的服务之间的区别。

为了让您了解必须如何以不同的方式考虑基于 REST 的服务，让我们看个例子，即与企业 SOA 服务相比时，可以从哪些不同的角度考虑基于 REST 的服务。首先，公开内部服务可能不是触及大众的最好方法，外部服务可能需要代表企业独特的视角。假定您将企业 SOA 扩展到一家全球航运企业的 Web 上。在这种情况下，关于如何构建服务有两个不同的重点。假定您从业务流程建模着手，将其作为在标识服务时应用 SOMA 方法的一部分。如果像这样建模企业的流程，则建模的重点（内部重点）就是优化资源来尽可能提高盈利率。也就是说，您在像这样建模时，可能会问：

• 您的飞机和卡车的满载率如何？
• 如何最大限度减少燃油成本？
• 将 X 个包裹从 A 点送到 B 点的最便宜方法是什么？

但从使用网站的人员（或希望在 Mashup 中使用您的网站发布的基于 REST 的服务的人员）的角度看待企业时，建模工作必须采用不同的焦点。也就是说，以外部客户为重点时，要问的问题可能就变成了：

• 我的包裹在哪里，什么时候将送到？
• 从这里将包裹送到托莱多将要花多少钱？

假定您最初从第一个角度进行建模，然后想要从第二个角度添加基于 REST 的服务，那么您要认识到需要进行更多的建模和设计工作。不过这是 SOMA 和 RUP-SOMA 这类方法的好处所在：它们是迭代性的，可以在认识到需求时纳入此类变更，而不用像要把圆形的销子插入方形孔中那样做无用功。

图 1 显示了我们使用过的最有用的关系图之一，用于说明采用 SOA 需要什么。这是跨业务和 IT 的 SOA 远景需求的图形表示形式。您评估目前的状况，建立从现状到远景的路线图，并实现以循序渐进的方式执行路线图的项目。这个方法不仅适用于 SOA 采用，也同样适用于 Web 2.0 采用。

有两点至关重要：1) 确定远景，2) 执行项目。如果仅仅关注 Web 2.0 的远景和路线图（包括实现基础结构和框架项目），而没有“真正”的项目（用于生产，产生业务价值），那么就很可能得到一个不满足项目需求的基础结构和过程，使项目团队更难遵循路线图/体系结构/框架。如果启动个体 Web 2.0 项目时没有远景和路线图，也没有公共基础结构，那么就有可能减少所提供的价值，再次面临之前已有的教训，不能跨项目重用代码，无法构建公共基础结构和过程（如安全性）。早期项目并不需要为了提供价值而做得太大，但总能够提供机会帮助获得新技术和业务模型的使用经验。

我们在帮助客户采用 SOA 的过程中发现相对较晚的一件事是，非常需要 SOA 治理。IT 治理有时候是个很微妙的问题；有时候这方面更多是提得多做得少。SOA 治理是对 IT 治理进行扩展的过程，以处理 SOA 所提供的特定语义和业务元素，是构建 SOA 使其能够发展、维护和扩展的关键。另外，SOA 治理应该扩展到 IT 治理之外，以将业务负责人包括进来。

我们所看到的是，因为随着使用 SOA 原则构建的体系结构的发展和成熟，SOA 基础结构和服务开发及部署流程的管理和控制会变得极为重要。IBM Rational Asset Manager、IBM WebSphere® Service Registry and Repository 和 IBM Tivoli® Policy Manager for SOA Security 之类的工具可用于帮助配备可靠的治理流程。

我们从使用 Web 2.0 原则构建的早期应用程序可以看到，Web 2.0 的治理将更具挑战性，因为 Web 2.0 采用的关键是自由沟通、社区协作和信息共享。在公开基于 REST 的服务和 Atom 服务时，问题就变成了：如何控制但又不限制用户对这些服务的使用以及对资产的开发？如果构建社区的社交方面受到太过严格的治理过程的限制，则社区将不会繁荣。不过，在线社区受到治理不足或不当的影响的情况我们见得太多了，很容易被埋在“垃圾堆”里，不能够将现有的宝贵内容突显出来。

Web 2.0 的治理可以看作管理公园。作为好的公园管理员，您希望在自己的控制范围内鼓励多样化，但不能超过规定的限度。为了确保基于 REST 的服务的生命长且能带来利润，在任何情况下，规划治理并确保您的基于 REST 的服务通过某种治理流程得到控制都非常重要。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-610848/，如需转载，请注明出处，否则将追究法律责任。