观点与展望，第 4 部分: 如果刚刚开始采用 SOA，最好将哪些软件作为服务实现？

领测软件测试网

IBM 专家将提供各自的个人观点，以推动 IT 体系结构实践方面的发展，从而帮助您更好地担当架构师这一职责。

引言：将 SOA 理论付诸实践

注意：有关观点与展望 专栏的全面的信息，请参阅以前的部分：

• “第 1 部分：选择 SOA 的原因和时机”
• “第 2 部分：如何将业务需求转转换为 IT 要求？”
• “第 3 部分：什么是最有价值的 IT体系结构技能，如何学习？”

您可能已经认识到面向服务的体系结构（Service-Oriented Architecture，SOA）适合您的 IT 系统——或者您尚未认识到这一点。但为了讨论方便，让我们假定您已经决定开始设计和实现您自己的 SOA 系统了。您将问自己的第一个问题是“我该从哪里开始？”

IBM 等企业提出的 SOA 方法定义了四个采用 SOA 的阶段，其中第一个阶段是：

• 实现各个 Web 服务

您需要创建各个基于软件的服务——任务或任务集，以软件组件的形式编写，可通过发布和可发现接口在网络上为其他应用程序提供服务。这些服务可以是从头创建的基于软件的任务，也可以是需要从现有非 SOA 应用程序转换为服务的任务。（我建议您阅读关于面向服务的体系结构的采用的所有四个层次部分，以确保按照正确的方向进行相关工作。）

理论上很简单，是吧？您所需要做的就是编写包含这些服务的组件，或直接根据已定义的 SOA 接口将现有大型应用程序“组件化”。您可能会想：“说起来容易，做起来难。”正如我在 Rational® 软件组的一位同事说的，“从理论上说，理论和实践是完全相同的，但在实践中，它们却并不相同。”

SOA 采用的第一个层次虽然很简单，但您仍然可能会询问与以下类似的问题：

• 就实践而言，我如何知道怎么开始实施 SOA？
• 我如何知道哪些可作为一个好的服务？
• 是否可以使用已经编写的代码，或者，我是否需要完全重新编码？
• 应该如何处理现有代码，以将其变成服务？

为了帮助您回答这些重要的 SOA 采用方面的问题，我们邀请我们的 IBM 体系结构专家组回答以下问题：

如果我刚刚开始采用 SOA，哪些类型的软件特征是作为服务实现的最佳候选对象，开始实现过程的第一步是什么？

和以往一样，专家们给出了很多意见和建议，我们希望他们的这些观点和看法能帮助您将 SOA 理论付诸实践。如果您有其他问题或对本主题有任何看法，请告知我们，可以通过 pdreyfus@us.ibm.com 给我发送电子邮件，或在IT 体系结构讨论论坛发表您的问题或看法。我们将尽力为您提供帮助。

Paul Dreyfus
developerWorks SOA and Web services
pdreyfus@us.ibm.com

另，developerWorks SOA 专区 (www.ibm.com/developerworks/cn/webservices) 提供了关于此主题和 SOA 采用过程中的其他主题的详细指南。除了参考我们专家组的意见外，还请参阅 SOA 新手入门 和 SOA 技术文档库。

回页首

面向服务的建模和架构

确定在 SOA 中公开哪些服务的过程称为服务标识。可从 developerWorks 文章“基于服务的建模和架构”了解关于此过程的更多信息（该过程包含三个相互补充的技术，均在这篇文章中进行了说明）。

首先，您需要清楚而全面地定义转换的范围：最首要的问题是，为什么要启用服务？定义了这个范围后，将应用目标服务建模、流程分解和现有资产分析，以获得候选服务组合。这些经过归类的候选服务集属于您的服务模型的一部分。

在您工作的下一个阶段，将确定和设计每个服务。需要进行服务公开决策：在数量相当多的服务中，我要实际公开哪些服务？以一系列选择标准为“石蕊试纸”，对最初候选的所有服务执行一个“PH值测试”，就可以得到这个问题的答案。这包括基于各种标准（如其与业务需求的一致性）测试服务的“良好度”或相称度。

这将筛选出一个列表，其中包含应该开始进行设计且在 SOMA 的规范化阶段发生的服务。在此步骤期间，将详细指定服务的很多详细特征，以供实现过程中使用。

实现是在 SOMA 过程的实现阶段完成的，在此阶段，将通过一组体系结构和来源确定决策对服务进行准备、来源确定或实现。该过程的这个部分的成功是类似于以下所示的声明：

• 我将使用此包来实现提供此服务的组件。
• 我将从头构建此服务。
• 我将对这两个遗留事务进行包装。
• 我将使用这些事务实现第三个服务或它的一些操作。

回页首

插入点

一个标识服务（无论是纯 Web 服务还是其他更一般的服务类型）的反模式是，了解现有系统，并使用已经获得的主要接口对服务进行包装。

之所以认为这个做法非常不好的原因是，这些接口——用于表示系统的错误边界——通常可能很糟糕，是经过多年使用而逐渐从原始状态发展而来的，其表现具有偶然性，行为并不是最开始就确定的。这也是技术第一的解决方案的一个例子。

标识良好服务的一个更好的模式涉及到定义简洁的抽象。根据您的系统提出一些基本的使用场景。将重点放在交叉点上（即多个方案的成功均依赖于一个较小的软件集的位置）。在这些交叉位置之间的巨大间隙中，您将找到使用服务的位置，其相关粒度可由这些方案本身的特性确定。不过，是否将这些服务包装为纯 Web 服务还是别的什么，这需要进行进一步决策。

回页首

各种入口点

SOA 策略不应是大规模替换现有 IT 环境；相反，这应该是一个循序渐进、不断发展的过程。因为各个企业通常具有复杂的操作环境，因此不可能进行完全替换。因此，整个路线图应体现为一个迭代重复的过程。

根据我参与多个客户的相关工作的经验，并没有用于构建 SOA 解决方案的“万能”完美方法。不过，存在各种入口点，可用于帮助采用 SOA。可以将这些入口点大致归类为以下数个类别：

初始采用。这通常适合那些希望进入这个领域但又担心有风险的用户。体系结构方面的工作通常限制在一个临时环境中，相关的活动包括从概念验证到早期的试验性部署等活动。初期工作体现出业务和技术价值后，会在更大范围内开始采用 SOA。

业务线采用。具有技术眼光的进步的业务线（line-of-business，LOB）执行人员可能会认识到 SOA 的价值。在这个过程中，将首先标识一组业务流程和功能的灵活性要求，定义具有关键成功因素和结果指标的解决方案概要，最后实现解决方案体系结构。有时候会使用服务建模和分析技术来对服务标识、规范化和实现步骤进行正式化。IBM 咨询师喜欢使用 SOMA 方法来进行此过程。

企业采用。这是开明的 CIO 决定开始以增量方式逐步对整个企业的应用程序进行转换时的情况。通常会涉及到业务分析和建模，以便创建一个区分了优先级的企业组件图。为了获得这个组件图，IBM 顾问通常使用组件业务建模（Component Business Modeling，CBM）方法。该图中每个需要进行重构的业务组件都会使用服务建模技术（如 SOMA）进行分解，从而最终实现可重用的、价值驱动的服务：

企业采用的是开明的 CIO 决定开始以增量方式逐步对整个企业的应用程序进行转换时的情况。

我与人合著的《SOA Compass, Business Value, Planning, and Enterprise Roadmap》一书可帮助您了解 SOA 采用过程中的各个基本组成部分——工具、技术和方法。“SOA Project Planning Aspects”（WebSphere® Journal，2006 年 1 月）对该书的内容进行了简要介绍。

回页首

将各个组织连接起来：寻找粗粒度服务

这是一个不错的问题。其他人标识了很多类型的服务。我将仅回答有关“最佳候选服务”和“第一步”的问题。同时，我对这些问题也进行了一点改动。因为，SOA 首先 是一个具有很多好处的体系结构模型。很多其他文章已经对其优点进行了说明，我将不在此处进行重复了。

Web 服务是一组为 SOA 启用互操作性的标准。WS-Interop 提供运行时互操作性，而 WSDL/WS-Policy 提供工具之间的互操作性。例如，WS-Interop 支持 .NET 和 WebSphere 运行时通信。程序员在 Rational Application Developer/WebSphere Integration Developer 和 Visual Studio 之间交换 WSDL/WS-Policy，以开发协作应用程序。各个供应商均支持优化，例如 JMS/MQ 上的 SOAP（一种基于 XML 的消息传递协议）和 SCA 的 Java™ 接口。

从粗粒度服务着手，可以确保首次尝试 Web 服务不会遇到性能或可靠性问题。

既然这样说，我认为最佳的候选服务应该是：

1. 由一个组织发布而由另一个组织使用的服务。即，首先使用 SOA 跨越组织边界。
2. 非常粗粒度的服务。程序员应该寻找在发送方和调用方要进行大量处理的文档交换一类的服务（即使使用远程调用）。

实现第一种类型的服务通常是为了解决迫切的业务需求；例如，企业间的集成或企业内 LOB 间的集成。实现 SOA 的 Web 服务提供了一个用于集成异类基础设施和应用程序接口的公共模型。这是 Web 服务的一种很好的用法，通常可解决迫切的业务问题，并同时允许不同组织内保持自主权。

从粗粒度服务开始，可以确保首次尝试 Web 服务不会遇到性能或可靠性问题。此方法还允许实现 SOA 的一些好处，如松散耦合、消息路由和消息审计。

回页首

您可能已经在使用 SOA 了

如果您刚刚开始采用 SOA，或许要做的第一件事情就是使用 IBM SOA Self Assessment 工具（该工具是免费提供的）。根据评估的结果，可以确定当前的成熟度水平，并更好地为了实现 SOA 解决方案所需要进行后续步骤。也可以参阅“SOA compliance”白皮书，该白皮书描述了在这一漫长的过程中的可以采取的初始步骤。

阅读了所有相关材料后，您可能会惊喜地发现您已经在使用 SOA 了。例如，Rational Application Developer 从 V4（当前产品为 V6）开始就提供 Web 服务支持了。您可能已经使用过其提供的向导来将简单 Java 对象、存储过程、SQL 命令和无状态会话 Bean 转换为具有 Web 服务描述语言（Web Services Description Language，WSDL）接口的服务。WebSphere Integration Developer 之类的新外接程序允许使用各种标准（如业务流程执行语言——Business Process Execution Language，BPEL）来将这些服务装配为业务流程。

回页首

结合使用各种方法

服务标识显然出现在 SOA 生命周期的开始位置，在很多情况下都会为整个项目的成功打下基础。服务标识通常采用域分解、现有资产分析和目标服务建模的自顶向下、自底向上和折衷技术的组合。自顶向下通常可提供业务用例所定义的业务服务的规范。这包括使用业务用例将现有域分解为功能区域和子系统。

在自底向上方法中，会将现有系统作为实现的可行候选者进行分析和选择。例如，可能会分析 IBM CICS® 遗留环境的现有功能，以确定可能的 SOA 转换。通过确定表示组件和业务组件是否紧密耦合，可确定是否可以方便地为应用程序启用服务。

服务标识通常采用域分解、现有资产分析和目标服务建模的自顶向下、自底向上和折衷技术的组合。

这种方法包括使用目标服务建模来发掘在用例（自顶向下）和现有系统（自底向上）方法中没有真正捕获的服务。由细粒度组件和其他服务组织的服务是作为服务实现的最佳候选者。标识了服务后，就可以开始服务的分类分级阶段了。此步骤无疑将帮助减少部署数千细粒度组件时的服务增殖问题（这些细粒度组件可能在未应用正确的控制时导致性能、可伸缩性和管理问题）。

回页首

常用服务

“中间相遇”方法可非常好地确保减少连接断开的情况。进行自顶向下业务流程分析，以标识最高级别的业务流程，然后将其划分为更为细粒度的服务。同时，对组织中已经存在的应用程序和基础设施采用自底向上的方法进行分析，以尽可能对现有资产进行重用。

因此，首先要考虑的服务是那些多个应用程序间最常用的内容——您可能会在不同的应用程序中发现对这些内容进行了多次实现！这可以很快降低成本，并立即体现出其价值。要考虑的主要方面之一就是，为了能有效地对服务进行重用，需对接口进行良好的设计。另外，您可能需要将实现新应用程序所带来的成本和好处与通过包装在相应的接口中来重用现有应用程序进行比较。

回页首

首先实现基础设施服务

有三种类型的服务可在整个企业内作为共享或可重用服务公开，如下所述：

• 公共基础设施服务：在操作级别对所有应用程序和系统都必要的服务。我所说的“操作”是指支持系统和应用程序本身的运行时环境所必要的任务——如目录/LDAP 服务、安全性服务、发现服务和服务管理。
• 公共企业服务：可以在整个企业范围内作为构建块提供的服务，可用于组合成新的服务和应用程序，如协作服务、消息传递服务和内容服务。
• 域特定的服务：提供特定业务功能的服务。域服务通常是企业内现有业务应用程序的扩展，如 addCustomer、getEmployee 或 submitOrder。我建议企业就公共基础设施和企业服务支持的初始域服务集达成一致。

知道了这些区别后，要实现的第一种服务类型应该为基础设施服务，然后是支持初始域服务所需的那些公共企业服务。然后应使用基础设施和公共企业服务作为构建块来开发域服务，以扩展现有业务应用程序。选择正确的域服务进行组合实际上是对整个 IT 投资组合的潜在重用和可组合性进行评估的过程。

回页首

数据封装、遗留系统

您很可能从我们这里得到一个答案是，使用 IBM SOA Self Assessment 工具，该工具实际上更多的是确定您的组织对 SOA 的准备情况。快速了解服务概念的另一个标准答案的参阅白皮书“Five SOA projects that can pay for themselves in six months”。虽然这样说，但还是让我们了解一下可能需要使用服务的技术场景类型：数据和遗留功能的封装。

服务是一种访问高度依赖数据的行为的好方法。服务可对数据进行封装，简化客户机交互，并可在必要时从远程位置访问数据和行为——当数据快速变化或高度敏感而很难复制数据时，这将尤为有用。信用卡验证信息就是一个很好的例子；服务可以对支付操作进行验证，并同时保证信用卡数据库的安全。另一个不错的例子是股票报价服务，其中的当前数据在频繁发生变化，而历史数据又非常多。

服务也是包装遗留系统的好方法，可以更方便地访问和重用其功能。不必在新应用程序中重复相同的功能，而可以委托给已经具有此功能的现有应用程序。如果现有应用程序并不允许通过这种方式方便地调用此功能，可以使用代码对其进行包装，以将该功能作为服务公开。假定您的大型机订单处理系统已经知道订单的状态；要在网站上公开这个信息，请将相应查询作为使用大型机的服务实现。与此类似，如果该系统提供了创建、修改或取消订单的方法，请将这些任务作为您的网站也能使用的服务公开。

假定您的大型机订单处理系统已经知道订单的状态；要在网站上公开这个信息，请将相应查询作为使用大型机的服务实现。

包装数据库或大型机的服务应是什么样呢？它们应该与用例类似。我所说的用例是对“客户计划如何使用数据或功能？”这一问题的回答。将重点放在客户希望服务做什么，而不是如何使用数据库或大型机将其实现。将重点放在用例上，可以确保服务不仅从技术上可行，还能确保服务在实际中有用。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/