使用面向服务分解技术来满足架构目标,定义与业务模型一致的服务

引言

通常，企业已经拥有一组支持大多数必需业务功能的应用程序。因此，谈到服务定义，您可能以为这不过就是将现有的应用程序功能作为一组服务来公开，类似于传统的企业应用程序集成（enterprise application integration，EAI）实践。其实不然。在实现基于面向服务的体系结构（Service-Oriented Architecture，SOA）的解决方案时，正确定义服务是最困难的任务之一。遗憾的是，此方法很少有效。这种方法本质上是“一种技术优先的方法和导致灾难和/或严重过度设计 (over-engineering) 的方法”。¹（请参见 参考资料。）

一种更好的面向服务的分解方法基于企业范围的业务模型。此方法包括设计一组定义企业架构蓝图的服务，以支持当前业务目标并提供用于将来变更的功能。此方法要求您“从场景/业务需要开始，参照现有的/新的系统分析那些需要，对准切点，然后为获得有意义的服务做好计划”。¹（请参见 参考资料）。以这种方式定义的服务可以实现 IT 与业务功能之间的可跟踪性。此方法是“一个能够帮助您坚持企业架构远景的交付策略的示例”。²（请参见 参考资料）。

本文将讨论一种面向服务的分解方法，此方法符合企业业务驱动因素和面向服务的计算原则。此方法的基础是基于业务模型将企业 IT 功能初步划分为服务，然后重构初始的服务定义，以便服务与总体企业架构目标一致。这种方法可以实现为具有以下活动的多步骤过程：

• 层次结构分解，基于企业业务模型，以确保最终的服务与当前和将来的业务功能一致
• 初始服务分解的重构，以使服务与架构目标一致，例如性能、可伸缩性、安全性，等等
• 使用企业语义数据模型，基于业务模型，以确保最终服务的互操作性

ACME Insurance

本文使用虚构的 ACME Insurance 公司作为示例。ACME 专门从事两个保险行业：个人汽车保险和内陆水运保险。ACME 处理与完整的保险服务生命周期相关联的所有问题——包括评级、承保和保险单维护。为了最大限度降低复杂性，本示例完全集中于签发过程。有些细节虽然从保险公司的角度看是必需的，但是如果不会为我们的讨论增添价值，我们将省略这些细节。

保险签发的核心在于用于确定适当的客户保险费的专有评级模型。该模型是由 ACME 的保险代理人随时间推移而开发出来的，它根据与特定行业相关联并由特定保险产品定义的规则和风险因素，从而确定与保险单的签发相关联的风险。

ACME 已经拥有一个保险管理系统。IT 人员开发并发展了该系统，系统中具有若干支持所有必需功能的专有和现成的软件包。如 图 1 所示的应用程序目前支持签发流程。

图 1. 当前的 ACME 应用程序

• “接受内陆水运保险条款和条件”是一个基于 Java™ 2 Platform, Enterprise Edition (J2EE) 的 Web 前端，此前端允许用户输入保险单的条款和条件、接收报价和查看保险单的状态。类似的应用程序“接受个人汽车保险条款和条件”支持一个不同行业的相同功能。
• “内陆水运保险单和产品管理”是一个 Visual Basic 6 (VB6)/COM 应用程序，此应用程序支持两个基本功能：
• 产品管理——支持该行业的新保险产品的创建和现有产品的维护。
• 保险单管理——支持完整的保险单生命周期，包括报价、签发、背书、修改和注销。此应用程序还依赖一个索赔馈送程序，后者提供有关给定保险单的索赔历史记录的信息。

针对个人汽车保险的产品和保险单管理实现为两个 CICS/COBOL 应用程序。此外，“机动车辆报告”应用程序允许从相应州的机动车辆管理部门访问被保险驾驶员的驾驶记录。

• “内陆水运评级”是一个 VB6/COM 应用程序，并实现了用于内陆水运保险的评级引擎。“个人汽车保险”应用程序的相似功能是使用一个 CICS/COBOL 应用程序实现的。

长期业务目标

现有的一组应用程序完全支持 ACME 的当前需要。然而，这些应用程序缺乏对以下长期业务目标的支持：

保险单签发流程的标准化

目前，“内陆水运”和“个人汽车”保险单的签发基于两组不同的应用程序，使用了两个完全不同的流程和两组完全不同的屏幕。这要求将员工数年增加一倍以支持两个流程，或者对相同员工进行更广泛的培训以同时支持两个流程。

简化保险单签发流程

在当前实现中，该流程要花两周以上的时间，使得 ACME Insurance 很难与其他保险商竞争。

改进索赔数据质量

对于内陆水运保险，目前的索赔数据输入每月才更新一次，从而导致保险数据不准确。

“正在处理的”保险单的更好管理

管理报告系统仅提供有关已完成的投保申请的信息，从而无法在保险单处理过程中引入纠正措施。

业务扩张

当前的应用程序仅支持保险单的手工输入。这妨碍了加入需要以电子方式提交投保申请和保险单报价回报的保险交易所。

流程变更

例如，法律法规遵从性要求引入记录管理。ACME 正在研究采用一个文档管理系统来管理保险单文档。ACME 还看到了交叉销售方案的潜力，并且正在考虑为此目的而引入客户关系管理（customer relationship management，CRM）过程。

ACME 的现有 IT 系统提供了支持上述目标的所有必需功能，但是这些 IT 系统的架构 或组织结构 使 ACME 难以达到那些目标。当前实现的以应用程序为中心的性质很成问题，因为每个应用程序是单独构建和维护的，没有（或很少）考虑到公司中的其他应用程序。

结果，核心业务功能——保险单签发——不是作为一个整体流程而存在的。其功能散布在现有应用程序之间；每个应用程序负责该流程的一部分，并且总体集成是在事后实现的。

公司的大多数业务目标都要求使该业务流程成为 ACME 的架构的焦点。保险单签发流程的定义良好和外部化的实现是支持企业长期目标的灵活、自适应 IT 架构的关键要素。例如，正在处理的保险单的管理和签发的简化需要签发流程的端到端可见性。如果不外部化该流程，这样的可见性几乎是无法实现的。

ACME 的架构师寻找到一个与业务目标一致的解决方案，并决定采用 SOA 方法来实现保险单签发。

层次结构分解

SOA 分解的基础是一个企业业务模型，其中包含了用于满足操作、战术和战略业务目标的资源和流程的主要表示形式。业务模型是成功的面向服务的分解的基本组件，并确保最终的服务在整个企业中的一致性和灵活性（采用 SOA 方法的动机）。必须准备一个高级模型来帮助设定服务的方向、分区和分类。随着 SOA 实现的推进，可以随着时间的推移而逐步开发实现细节。

企业业务模型

存在许多定义企业业务架构的方法。有些架构师基于公司的组织结构来解释业务架构。可以使用业务功能或流程模型作为绘制垂直功能与水平流程之间连线的起点，以描述业务中跨功能的流程。

企业业务架构的一般定义如下：

“……[企业业务架构] 定义企业价值流及其与所有外部实体和其他企业价值流以及触发实例化的事件之间的关系。它是对企业为满足其客户、在市场中竞争、与供应商交往、维持运营和关怀员工所必需产生的内容的定义。它由架构、工作流和事件组成。价值流是为客户创建成果的活动的端到端集合，该客户可以是最终客户或该价值流的内部最终用户。价值流具有清楚的目标：满足或取悦客户。” ³（请参见 参考资料。）

价值流有效地描述了核心企业业务流程，后者包含了从 IT（服务）的功能组件产生结果的有序活动序列。

许多行业（例如保险、制造和金融服务）具有定义给定行业中的企业功能的行业模型。如果存在这样一个模型，则在创建公司的业务模型时使用该模型始终是有利的，至少也要使用该模型作为起点。 3

此方法使您可以定义核心企业业务流程和支持这些流程所必需的服务。此方法还是确定当前流程有效性和效率的基础。

业务模型的关键组件是对企业业务流程的描述，这些描述定义了支持流程的活动、输入和输出。流程活动为定义企业服务提供了基础。使用业务模型作为将解决方案分解为服务的起点，这样可以促进业务与技术之间的一致性——SOA 方法的目标之一。

由企业业务模型驱动的服务划分符合自顶向下的设计，并代表了从流程到服务和流程的层次结构分解。

从最高级别看，企业系统可表示为编排多个服务的业务流程。一般来说，可以使用编排较低级别服务的子流程来进一步分解每个服务。图 2 显示了到业务流程和服务的层次结构分解。

图 2. 流程、服务和组件的分解

分解是一种沿用已久的技术。取决于具体的目标，可以应用许多分解条件。分解条件对诸如性能、灵活性、全面性、开发时间、可变性、重用等架构目标具有重大的影响。

几个影响层次结构分解的因素如下：

粒度

流程或服务的级别越高，接口的粒度就越大。较高级别的流程或服务在每次调用时比较低级别的服务做更多的工作。这是有道理的，因为较高级别的服务使用较低级别的服务来实现它们的功能。选择适当的服务粒度并不是一个简单的任务。当前没有任何数学理论或方法学能够告诉设计人员或架构师服务分解是否完成得正确。下面的测试 ⁴可以验证服务的粒度。

• 业务一致性 观点探究建议的服务与业务之间的一致性：
  • 是否可以基于某个业务远景（模型）论证该服务？
  • 企业是否希望对合作伙伴公开该服务？
  • 企业是否设想将该服务外包给某个贸易合作伙伴？
  • 该服务对业务的功能是否关键？
• 可组合性 观点考虑在多个业务流程中使用该服务的能力（例如，在与定义该服务的的上下文不同的上下文中）：
  • 该服务是否可以在其他场合使用并组合到另一个业务流程中？
  • 将该服务组合到另一个业务流程中是否需要非常深的组合层次结构？

可见性

流程或服务的级别越高，其可见性越广。例如，企业业务流程具有跨整个企业的可见性（或范围）。其接口对所有企业用户可用。相反，低级别的业务流程或组件仅在其应用范围内可见。该范围之外的用户无法直接使用或看到此业务组件，而是通过较高级别的服务间接地使用此业务组件。

一般来说，这些因素集合起来决定了较高级别的流程具有更大的粒度和更广的可见性，而较低级别的组件具有更细的粒度和有限的可见性。

为了实现层次结构分解，ACME 的业务分析人员通过开发一个用于保险单签发的业务模型，从而开始确定企业业务服务。该模型涵盖公司中的所有关键业务流程，并包括实现流程及其排序所需的主要业务活动。

该 ACME 业务模型基于 IBM Insurance Application Architecture (IAA) 定义的行业标准概念、定义和高级流程，IAA 定义了标准化的保险单签发模型（请参见 参考资料）。遵循 IAA 使得 ACME 可以利用保险行业积累的集体知识。这个基于 IAA 的高级保险单签发流程如 图 3 所示。

图 3. 简化的保险单签发流程

基于该业务模型将解决方案分解为服务产生了一组服务，如 图 4 所示。在此例中，我们仅使用了一个级别的分解。

图 4. 基于层次结构分解的 ACME 服务

其他因素

基于企业业务模型的层次结构分解可以实现业务与 IT 之间的一致性，但是并不保证最终的服务将遵守基本服务原则。应该将以下附加的服务方面考虑进分解过程中。

显式边界

服务通过显式的远程调用进行交互。服务实现人员可以控制服务边界内的执行，但是无法控制跨边界的调用。此类调用会受到网络延迟、网络故障和分布式系统故障的影响。

在多个服务之间划分时效性很强的功能会导致违反总体系统的性能要求。类似地，两个或更多个服务之间真正的两阶段提交要求通常是无法达到的。因此，如果基于某个业务模型定义了多个具有以下特征的服务：

• 严格的调用延迟要求
• 两阶段提交要求

则应该将这些服务组合为单个服务，并在内部实现调用和两阶段提交，从而提供组合的功能。

自主

服务是在彼此独立和独立于使用它们的系统的情况下开发、部署和进行版本管理的。创建严重彼此依赖的服务增加了服务的耦合，从而对服务的自主性具有负面的影响。如果使用某个业务模型定义了几个具有以下特征的服务：

• 严重依赖相同的现有代码（应用程序）
• 主要是在一起使用

则应该将这些服务组合为一个服务，从而提供组合的功能。

服务共享模式和契约

使用基于 XML 模式的消息来实现服务通信使您可以定义与编程语言和平台无关的服务接口。您可以确保更广泛的服务互操作性，从而确保更广泛的服务适用性。应该使用语义消息（数据模型）来定义服务接口。

下面返回到保险单签发流程的分解：ACME 已购买了一个复杂的文档管理系统，该系统能够处理文档编写和存档。虽然企业业务模型指示这些功能使用单独的服务，但是分解将产生两个严重彼此依赖的服务。将编写和存档任务组合在一起就得出了一个遵守自主边界的服务。

Create quote 和 Issue policy 都需要保险单的评级。正如已经提到过的，评级是保险公司的主要能力，并且可以独立于其他实现进行更改（改进）。基于服务的自主原则，将评级实现为一个独立的服务是有意义的，Generate quote 和 Issue policy 都可以使用该服务。重构之后的一组 ACME 企业服务如 图 5 所示。

图 5. 重构的 ACME 服务

语义数据模型

定义已确定的服务的接口是 SOA 分解的一个重要组成部分。接口定义需要指定服务所交换、使用和生成的消息。

基于企业业务模型的自顶向下的设计能够产生可互操作的语义接口定义。最终的语义数据模型定义了企业的标准业务对象或实体，例如保险单、索赔等等。围绕语义数据模型（互操作性）实现的 SOA 表示语义 SOA。

语义 SOA 提供了服务之间增强的互操作性：在接口级别，所有服务都使用相同的数据定义进行工作。事实上，这消除了对服务之间的消息转换的需要。由于服务接口是基于标准企业语义模型创建的，因此无论服务使用者是什么，都可以保证每个服务将理解并正确解释所有消息。

语义接口的未来 服务契约的语义数据为重新思考服务接口留下了余地。由于所有服务的接口数据模型都是由相同语义驱动的，而不是将特定消息请求发送给某个服务并接收特定的应答，因此可以作为服务调用“线程”的一部分传递服务执行上下文。服务方法的接口将具有大规模的多态性，并表示为： Service.method (XML context in, XML context out) 在此例中，上下文是用 XML 表示并支持企业语义的服务执行上下文。任何服务都可以从该上下文中提取其感兴趣的数据。 此解决方案颠倒了职责：与构建特定接口来参与某个服务的服务使用者不同，服务本身将负责从执行上下文中访问所需的信息，并使用其执行结果来更新该上下文。只要所需的数据在执行上下文中可用，这样就可以最大限度地减轻服务接口变更的影响。服务实现承担了一个附加的负担，不过与重新使服务使用者与服务接口变更保持一致的开销相比，此负担可以忽略不计。

尽管语义数据模型好像类似于标准化的企业数据模型，但是两者是完全不同的，不应该彼此混淆。语义数据模型定义了服务所交换的消息。消息实现服务间的通信。因此，消息是瞬态的，并不驻留在数据存储区中（至少不显式驻留在数据存储区中）。

相反，企业数据模型定义了数据库中的数据的数据结构和数据之间的关系。企业数据模型集中于诸如快速检索、低冗余、部分聚合等在数据存储区之外的不相关方面。

实现 SOA 涉及到使现有的企业应用程序能够支持服务。更改基础数据模型是开销极高的任务，通常需要完全重新编写应用程序。相反，SOA 消息基础设施是构建架构的一部分，这意味着可以作为 SOA 实现的一部分创建 SOA 消息基础设施。

存在使用模式和最佳实践来实现 SOA 中的语义互操作性的不同方法。经验表明，用于定义服务的相同企业业务模型还应该包括语义数据定义。例如，IAA 和 ACORD 都定义了用于保险业事务的 XML 消息。这些标准减少了业务合作伙伴彼此创建新数据接口所需的时间和精力。

语义数据模型指导原则

在定义 SOA 语义数据模型时，务必记住该模型提供 XML 数据消息 而不是数据持久性 的基础。存在几个针对模型创建的重要注意事项。

XML 使用层次结构数据模型。层次结构模型与传统数据库中使用的数据模型具有显著的区别，例如旨在用于快速更新和检索的规范化关系数据模型，或者旨在按各个维度切分的多维数据模型。因此，常见的数据库设计技术（规范化、联结、外键等等）很少适用于这种情况。这些技术通常导致过度复杂的 XML 实现。XML 模型设计通常需要大量的数据反规范化 (de-normalization)，并尽量最小化 XML 对象之间的交叉引用。

XML 有效负载将在跨越每个服务边界时进行封送/取消封送，因此使用 XML 中的“小”类型导致了大量的序列化开销，从而对性能产生负面的影响。每个 XML 类型都进行封送/取消封送处理，使其成为一个单独的对象，这意味着使用小 XML 类型导致在执行期间创建和删除许多对象。建议在语义数据模型设计期间增加 XML 对象的大小。

过多的 XML 类型嵌套会导致对有效负载进行更加复杂的 XML 处理。过多的 XML 嵌套通常导致在封送/取消封送过程中创建附加的语言对象，并需要更复杂的表示法来访问数据。最大限度减少 XML 有效负载定义中的嵌套是有利的。

总结

在本文中，您探索了一种面向服务的分解方法，此方法是由面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）所定义的服务标识的扩展。此方法是对域分解和目标服务建模⁵的补充，后者由 SOMA 根据用于确保服务互操作性的企业架构原则和语义消息定义来用于重构。您还了解了：

• 改进的业务一致性

  遵循企业业务模型的层次结构分解可产生与业务保持一致的服务。这提供了从业务构件到业务服务的可跟踪性。

• 对流程的强调

  根据企业业务模型，分解强调企业业务流程而不是实现流程的应用程序或流程所使用的数据。这种强调促使了从面向功能到面向流程思想的转变，并为新的可能性（流程模拟、语义补偿、关键流程指标等等）敞开了大门。

• 语义消息模型

  自顶向下、模型驱动的分解定义了服务的功能边界，并允许定义企业语义数据模型。使用此模型可导致创建更加可互操作、更加松散耦合的服务。

• 改进的总体架构

  对于服务标识来说，诸如安全性、可用性和低耦合等架构目标与功能分解一样重要。