评论专栏: Scott Simmons：不要错过 SOA 的最大的优势

企业体系结构与 SOA

回顾进行过的很多 SOA 客户合作项目，我发现几乎所有的客户都会想到在其面向服务的体系结构（Service-Oriented Architecture，SOA）解决方案的设计和部署中采用自底向上方法。总的说来，他们在分析现有资产、支持（或仅仅“包装”）相关项（或他们认为相关的项）以及开发服务目录来处理需求方面都做得相当不错。总的说来，通常是业务部门要求使用 SOA 作为体系结构模型来进行以 IT 为中心的集成。其积极的一面在于，此方法提供了灵活性和基本的重用，但 SOA 的最大的回报并非在于此。

在企业级实现 SOA 成功需要将 SOA 概念与企业体系结构的业务（及技术）战略及治理集成，并要支持自顶向下（及自底向上）SOA 解决方案分析和设计。通过关注业务方面，将其作为 SOA 设计和开发不可或缺的一部分，组织就能更好地从其 SOA 解决方案获得实际的价值。

之所以有这篇文章，我的目的是希望能够增强将 SOA 设计与以业务为中心相结合的概念。本文并不是要作为企业体系结构或 SOA 设计方法方面的教程，如果您希望了解更进一步的信息，请参考参考资料部分提供的有关 IBM® 的 SOA 方法的信息。

回页首

从项目级到企业级

开始之前，让我们澄清一点：在项目级别进行 SOA 采用工作并没有什么错，事实上，大多数企业 SOA 活动通常都是从恰当划定了范围的项目开始的。此外，采用企业体系结构的组织会希望通过试验实现来验证 SOA 解决方案。关键是要通过项目/试验级获得的经验，并将其推广到企业体系结构级别。

我在数周前与一家大型企业的首席企业架构师进行了一次有意思的交谈。尽管最初讨论的是 SOA 的技术方面和 SOA 设计模式，但我们花了大量时间讨论 SOA 和企业体系结构。在客户的 IT 战略中，SOA 是按逐个项目的方式实现的。这个以项目为中心的开发方法是目前实现 SOA 的大部分企业的特征——是由于传统企业文化和基于项目的资金投入模型促成的。尽管以项目为中心的 SOA 活动提供了一定的好处，但企业级别的 SOA 支持能够提供更大的灵活性和服务重用，并能促使在业务和 IT 之间进行更好的相关。除非 SOA 成为企业体系结构的一部分，并彻底进入组织的开发、设计、部署和治理方法，否则就不能完全实现 SOA 的最高回报。

在企业级别成功实现 SOA（及后续的其他成功）能带来更多的好处，包括快速适应市场动向、缩短新解决方案的上市时间、提供与业务需求的联系以及减少长期 IT 成本。2006 年进行的 IBM Institute of Business Value 调查可为这些结论提供支持。

另一方面，项目驱动的 SOA 实现面临的一个挑战是，对解决方案提升，使其不仅在一个服务调用集合上工作。通过在企业体系结构级别集成 SOA，可使其成为业务/IT 生态系统的一部分。通过此方法，可将服务作为创建新解决方案的基础，并能够提供业务需求与 IT 解决方案间的内聚。

在图 1 中，业务和 IT 战略对企业体系结构的定义和规范起到促进作用。从下游的角度而言，企业体系结构支持在组织级别以信息、应用程序和组织方面为中心进行规划。此框架实现企业级治理，并为 IT 解决方案设计和交付提供指导和支持。企业级别的 SOA 设计通常要求 SOA 成为企业体系结构的战略、规划和执行层的主要支持框架。

图 1. 关注项目与关注企业的情况对比

图 1 供稿人：Gil Long ，IBM 杰出工程师来源：IBM Global Services – EA Method Class.

回页首

对业务进行分解

为了在企业体系结构中将 SOA 作为战略和规范不可获取的一部分启用，通常需要了解组织的核心竞争力，以确保在业务目标和体系结构需求之间建立紧密的联系。分析企业中的核心功能的流程可以通过各种技术来完成。例如，IBM Global Business Services 使用组件业务建模（Component Business Modeling，CBM）来评估组织竞争力。ibm.com 提供了有关 CBM 流程的文献供参考。

从较高的抽象级别而言，CBM 是相对较为直观的概念。CBM 解决方案的基础是组织内核心业务组件的定义。业务组件是提供特定业务价值的人员、技术和资源的分组，能独立进行操作。销售管理和产品管理/营销以及人员、流程和技术方面（进行呈现或执行功能）都是业务组件。业务组件支持从分析和记录所使用的业务服务以及组件提供的服务的角度对业务功能和服务进行标识和设计。例如，“销售管理”业务组件可能会使用来自帐户管理的服务，并可能向其他组件（如“收货”）提供销售订单处理之类的服务。

派生出业务组件后，CBM 允许我们根据其相对于业务的总体成本对其进行分类，并评估业务部门是否会认为这些功能具有足够的竞争力。通过对竞争力进行分组，可标识有待改进和优化的区域。图 2 显示了一个示例 CBM 工作产品，其中突出显示了标识为需要进行持续分析和设计的区域的组件。

图 2. 示例组件业务模型

所标识的这些“重点区域”可能成为流程建模之类的 SOA 设计活动的输入。例如，如果我们决定帐户开立 (Account Opening) 是有待改进的区域，我们可以通过清楚说明与帐户开立相关的业务远景、业务目标和用户规范来确定初始需求。

作为此流程的示例，我们在进行与大型零售银行的合作项目时在内部使用了 CBM。在分析期间，我们认识到帐户管理 (Account Management) 是该银行的一项核心竞争力，同时也是客户满意度和减少客户大量流失方面的一项重要决定因素。CBM 活动认为，帐户开立流程可通过转换为跨银行的多个业务部门支持更为简单和标准的流程集（如服务）获益。通过交付这个增强的功能可以减少成本并增加客户满意度。通过将 CBM 分析与 Information Warehouse 信息及流程建模结合使用，此银行目前正在积极地开发企业级解决方案来跨各个业务部门对帐户开立流程进行转换。

CBM 技术提供了一个框架，用于确定组织中的主要竞争力和从后续步骤方面提供有关组织优化的指南。此外，几乎每个主要垂直行业都可以通过 IBM Global Business Services 合作项目获得的 CBM 模版。业务组件设计流程会在业务级别定义需要改进的战略区域、将这些目标与业务服务视图进行协调并将此服务视图与 IT 规划结合使用，从而为企业体系结构提供输入。

回页首

面向服务的建模与体系结构

服务建模方法对获得经过优化的服务模型来实现解决方案设计非常重要。面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）技术提供了严格的有相关记录的分析和设计方法，用于确定 SOA 解决方案。SOMA 是 IBM 的端到端 SOA 解决方案开发方法。我在此将不会对 SOMA 进行详细讨论，而将重点讨论以业务为中心进行 SOA 设计的概念。不过，Ali Arsanjani 所撰写的出色文章中对 SOMA 进行了详细讨论。（请参见参考资料。）

SOA 模型中三个基础构造是服务、服务组件（实现这些服务的实现实体）和编排服务的流（或流程）。之所以提出 SOMA，主要是用于处理所有这三个构造的分析和设计工作。正如 Rational® Unified Process (RUP) 中所述，SOMA 实际上由三个主要步骤组成，如图 3 中所示。

• 服务标识：派生和定义候选服务。
• 服务规范工作：建立并验证服务公开决策和高级服务模型的派生物。
• 服务实现：从整体组件设计的角度确定属性并扩展高级服务模型。

图 3. SOMA 的三个步骤

尽管 SOMA 通过多种方式在 SOA 与业务之间建立联系，但服务标识和 Service Litmus Test（服务规范的第一个关键步骤）是我们将重点关注的领域。

服务标识

正如前面提到的，服务标识步骤的主要输出是一组候选业务服务。可通过三种技术在服务标识过程中生成候选服务列表：

• 自顶向下方法，称为域分解。
• 自底向上以 IT 中心的方法，以对现有 IT 资产进行发现和描述其特征为重点。
• 中间相遇方法，称为目标-服务建模。

域分解提供自顶向下业务驱动的技术，旨在捕获关于组织的重要业务域、功能与概念子系统和业务流程的信息。域分解是通过源自业务组件设计的业务需求规范实现的。此外，还可以通过使用 WebSphere® Business Modeler 之类的工具对流程模型进行创建和验证来启用域分解。

业务流程建模通常在业务组件的设计中的主要业务活动标识工作之后进行。流程建模通常首先由业务分析人员使用工具来建模业务流程的现有（当前）状态。在流程模型中，分析人员给出作为流程中的步骤的工作活动或任务。随着流程模型的发展并由其他业务涉众进行复查后，“任务”将成为类似于候选服务的项目。在有些建模工具实现（如 WebSphere Business Modeler）中，业务分析人员可以设计现有模型和将来模型，并能够对流程进行模拟，以确定运行时特征，包括成本、资源需求和流程瓶颈。有些工具还支持对业务关键业绩指标（Key Performance Indicator，KPI）进行定义和规范。帐户开立的业务 KPI 之一可以为，要求开立帐户的平均时间不应超过 18 个小时。通过持续的设计和模拟工作，流程建模可在业务需求和业务服务之间建立联系，从而帮助标识候选服务。

现有资产分析技术可通过工具加以利用，也可以通过回顾现有 IT 资产的现有文档和知识来进行利用。此活动检查可能考虑用于实现将来流程所需的功能的现有 IT 资产。现有资产的来源可能包括以下方面：

• 基于大型机（例如 CICS/IMS/Batch）的事务。
• 通过 API、消息传递或服务接口连接的商业应用程序（如 SAP、Siebel）。
• 自定义内部应用程序，如 J2EE、.Net 和客户机/服务器应用程序。
• 通过合作伙伴获得的外部服务和组件的服务与接口。

可以用于支持此功能的工具之一就是 WebSphere Asset Transformation Workbench。此工具可帮助 IT 人员对现有应用程序进行扩展、重用和转换，并支持对大型机和/或分布式环境中的应用程序进行依赖关系分析。

对于域分解，资产分析活动所得到的结果是潜在候选服务列表。其中应该清楚地指出，所发现的资产（以及潜在候选服务的第一次迭代）并不等于服务。事实上，大部分操作都是细粒度的，即使是组合后的服务（如通过 SAP 的 IDOC 或 BAPI 交互）也是如此。这些候选服务通常在遵循 SOA 设计原则方面并非极为理想，将可能使用更抽象的服务对其进行封装。

最后，目标-服务建模从自顶向下和自底向上方法派生，使用业务和 IT 需求促进其他候选服务的标识。此活动可帮助标识与业务一致的服务，确保发现在域分解或现有资产分析期间未能标识的服务。目标-服务建模从业务目标标识开始，将其细分为子目标，然后确定需要哪些服务来完成这些子目标。

服务规范

SOMA 中的第二个主要阶段是服务规范。此技术包含一系列步骤，但对于文本，我们将主要讨论两个活动：

1. 应用 Service Litmus Test，以确定候选服务是否适合公开。
2. 从依赖关系、组合、非功能需求、消息定义和状态管理需求的角度确定服务模型规范。

Service Litmus Test 是所定义的一组标准，用于确定是否应该公开候选服务。这些标准主要归为四个大的领域：

1. 业务一致性：关注服务的业务相关性、是否存在用于支持开发和维护的资金投入模型以及在整个组织内共享服务的能力。

2. 可组合性：关注与组合级别的非功能需求的一致性、状态管理方面的注意事项、服务依赖关系的标识以及对技术/平台独立性的支持。

3. 外部化服务描述：关注是否存在外部服务描述（如 WSDL）、支持通过服务描述进行服务发现和绑定的能力以及将元数据作为服务描述的一部分提供。

4. 冗余消除：关注跨所需特定功能的多个组合场景重用候选服务的能力。

通过这组问题，设计团队可以就哪些服务应该作为服务实现开发、公开和管理做出恰当的体系结构决策。

作为 Service Litmus Test 的示例，我们与一家大型运输与物流公司举行的研讨会确定了超过 400 个最初被视为候选服务的业务相关 SAP 交互（BAPI 和 IDOC）。除了这组服务，还有其他近 400 个自定义应用程序中公开的服务。总共有超过 800 个候选服务。尽管此分析工作仍然在继续，但我们预计公开的服务的数量将不会超过 200 个。

服务模型的定义由多个步骤组成，通常会由此创建 UML 成果。可通过使用体系结构工具（如 Rational Software Architect 和 UML Profile for Software Services）帮助进行此步骤。在此步骤期间，将通过记录服务依赖关系、定义服务组合、记录服务非功能方面、定义高级服务消息模型和指定状态管理需求来设计服务模型。

服务实现

作为 SOMA 中的最后一项主要活动，服务实现将定义组件的服务分配以及这些组件到实现解决方案的分配。例如，某个服务可能通过使用我们作为 Web 服务公开的 EJB 实现，而另一个服务可能通过包装一个或多个 CICS 事务实现，另外的服务还可能通过提供 J2C 交互模式的适配器实现。

回页首

实际运用

我们在讨论的过程中已涉及了三个核心区域：企业体系结构、业务组件设计及通过 SOMA 的 SOA 分析与设计。这三个领域如下面的关系图中所示：

图 4. SOMA 的三个核心领域

企业体系结构内的战略及评估与核心组织竞争力分析间的联系将导致一组高级业务与 IT 需求的出现。这些需求反过来形成了 SOA 设计业务需求的初始步骤基础。

如图 4 中所示，此流程实际上具有迭代性质。随着新市场动向开始促使企业体系结构成形或随着组织的核心竞争力发生更改，这些更改要求对其对整体服务设计的影响进行分析。此外 SOMA 服务建模流程中的步骤也具有迭代性质。由于开发服务模型或开始考虑服务实现的各个方面的因素，我们可能最终会回到之前的设计工作中所做出的决策。

在 Grady Booch 的 developerWorks Blog中，他给出了非常精辟的评述：

我认为，SOA 的价值主张源自其缩写中的 A：体系结构 (Architecture)。其在治理和发展系统的体系结构方面具有可靠的、经过验证的价值；另外还必须坚进行一些艰难的抉择，其中的很多决策都不能视为前瞻性的（正是由于这个原因，其流程以有规律的增量式迭代发布可执行版本才如此重要）。

结束语

基于项目的 SOA 解决方案通常会采用自底向上以技术为中心的方法，可帮助实现 SOA 设计与开发入门，但从企业体系结构的角度而言，其提供的好处非常有限。

通过采用以业务为中心的方法设计 SOA 解决方案，可在企业级别将业务需求与 IT 开发流程联系起来。通过将 SOA 定义为主要支持体系结构，可为企业解决方案开发提供可靠的基础平台。将 SOA 作为核心企业解决方案方法的这种实现方式可允许基于组织的核心竞争力定义需求及确定其范围。将这些业务和 IT 需求作为输入，可以通过 SOMA 之类的服务开发方法以最佳的方式设计 SOA 解决方案。设计 SOA 解决方案的这种方法可提供服务的企业级视图，而且能缩短新应用程序上市的时间，并同时减少通过服务重用公开的 IT 资源。更为重要的是，以业务为中心的 SOA 解决方案设计可确保 SOA 与组织的相关性及其对组织的价值。