SOA 解决方案中涉及的遗留系统的设计策略

了解在遗留环境中使用 SOA 时的业务转换挑战

将此页作为电子邮件发送

讨论

级别： 中级

Jeremy Caine (jeremy_caine@uk.ibm.com), 高级 IT 架构师, IBM
Joe Hardman (joe_hardman@uk.ibm.com), 高级 IT 架构师, IBM

2007 年 8 月 28 日

面向服务的体系结构（Service-Oriented Architecture，SOA）是很多业务转换工作的核心。很多企业采用增量式方法进行 SOA 转换，使用其宝贵的遗留 IT 系统作为服务提供者参与其中。解决方案架构师面临的挑战不仅是将 SOA 基础设施作为促进转换的手段交付，而且还要确保企业级业务操作保持可靠性和兼容性。您的企业必须制定可作为 SOA 一部分的企业信息管理策略，并跨所有业务操作保持总体数据和内容的一致性。本文介绍了此类转换中面临的挑战，并将讨论一些值得考虑的设计策略。

引言

如果您的企业和大部分企业一样，则您的业务战略和核心竞争力分析已经确定了需要在哪些领域重点关注业务再工程和 IT 现代化。一个典型的结果（至少对于企业的某些核心方面如此）是转换到面向服务的业务，开始依赖 SOA。业务操作是围绕一组服务设计的，而这要求对当前 IT 系统进行再工程，并将其作为服务提供者加以集成。此转换还可能引入一些新的服务提供者。目标是能够构建新的组合应用程序（如内部工作区门户应用程序或 Internet 商业应用程序），从而高效地处理特定的业务需求。

作为这个充满挑战的转换工作的一部分，企业通常会开展一系列重大的业务与 IT 项目。主要的转换交付内容包括：

• 企业体系结构与业务服务模型的一致性。
• 引入能实现业务服务模型的相关部分的基于服务的 IT 技术设施。
• 对遗留 IT 系统进行转换和扩展（或向其应用包装），以便能集成到这个基于服务的 IT 基础设施中。
• 可靠的设计与开发环境及交付流程，允许为支持 IT 应用程序实现高效而灵活的实现。

转换的这些主要交付内容带来了一组略微次要的派生挑战。这些可确保企业按照其转换意图进行交付，并能够监视和适应更改，从而实现灵活性。这些转换挑战通常要遵循以下原则：

• 企业必须继续提供一组总体可靠的兼容业务操作。
• 需要治理流程和设计权威来确保总体业务服务模型与 IT 系统实现遵守全盘转换原则。
• 企业必须实现业务与 IT 服务管理的集成视图，以便能够进行度量和交付响应变更。

有些企业非常幸运，能够在整个企业内进行到 SOA 的业务转换。此方法要求为主要转换交付内容提供更富有挑战的实现，但最终能提供一个更便于发展和开发次要转换交付内容的环境。当希望在整个企业内驱动业务和 IT 变更的 C 级别的执行人员积极地帮助实现策略计划时，通常会出现这种情况。

不过，大部分企业转换都是增量式的——虽然很重要而且也采用了相应的策略，但是逐步进行的。这通常意味着将对遗留 IT 系统进行再工程，以使其参与新业务操作的支持——例如，与其他 IT 系统进行组合，以加速客户订单的直接处理。这些 IT 系统还需要执行所有（或者至少是大部分）当前功能。SOA 转换范围外 的业务操作将仍然继续。

在此转换场景中，必须仔细考虑 SOA IT 基础设施的实现设计。在这些 IT 系统内的数据处理影响范围外的数据处理，同时也受到范围外的数据处理的影响。总体数据处理环境必须继续保持可靠性和与总体业务操作的兼容性。

图 1 中的示例显示了三个再工程为服务提供者的遗留系统。

在图 1 中，业务转换项目已经构建了 SOA 基础设施，业务服务通过此基础设施进行发布，并供新应用程序使用。此基础设施通常包括用于支持软件间多协议连接、异步与同步消息流管理、消息转换、规则执行和流程编排的中间件。已经构建了使用这些服务的组合应用程序，甚至遗留系统本身也已经通过新服务调用得到了增强。

SOA 中的流程与信息体系结构

要实现 SOA 基础设施，所生成、维护和增强的主要资产是业务服务模型。要使用得到广泛认可的技术来开发该模型，如 IBM® 面向服务的建模与体系结构（Service Oriented Modeling and Architecture，有关更多信息，请参见参考资料）。在典型的企业中，这将混合使用自顶向下分析、自底向上分析和目标-服务建模。转换的业务目标将派生出流程与信息体系结构，用于驱动新业务操作的实现和支持 IT 应用程序：

• 流程体系结构是能够组合为企业操作底层的一组业务流程的操作的功能层次结构。它负责人员到系统以及系统到系统的流控制。例如，它可能包括在用户下产品订单并将其置为等待配送该产品的满意状态时所需的操作。
• 信息体系结构是一组通过对相关数据与内容进行访问、操作和存储，来向企业操作提供其状态和含义。它执行数据与内容的信息管理工作（无论在简单的访问事件还是流程流上下文中均是如此）。例如，在产品开发生命周期中使用和生成的数据和内容（制造概念等等）。

流程和信息体系结构观点通常一起形成并通过流程数据 (CRUD) 矩阵之类表现出来。它们一起定义组成服务体系结构的一系列服务。服务是一组在消息数据传入时调用的操作。服务实现执行操作数据或内容的处理（通常通过持久存储或访问），并返回结果。可以同步和异步使用服务，调用通常由集成基础设施代理。在完全分离的系统中，有些服务负责流程状态的更改（例如，将信息表示为已请求，将客户 X 的新地址表示为已验证）。其他服务负责对信息状态进行更改，确保将已经进行了操作的数据和内容置为所需的状态，以作为以后的服务事件的依赖（例如，客户 X 的新运输地址已生效）。

遗留数据处理挑战

遗留 IT 系统无疑将作为您的企业服务提供者实现的一部分，将集成到 SOA 基础设施中。遗留系统不仅包括传统大型机处理，而且也包括企业资源规划（Enterprise Resource Planning，ERP）应用程序、内部和外部 Web 应用程序、工作流应用程序、扫描与打印系统等等。可以进行很多工作来支持使用这些遗留系统并将其集成到服务提供者实现中：

• 处理功能将公开，可以对其进行访问，以便能将其组合到服务提供者实现中。这通常意味着通过新协议和调用机制公开事务，如 CICS® 事务上的 SOAP 包装。
• 可能需要对功能进行再工程，以在公开事务时保持处理完整性。此事务可以为现有的事务，也可以作为调用一个或多个其他现有事务的事务创建 (Facade)。对于前两种情况，应该通过服务粒度策略影响对这些已公开的服务的调用的设计。
• 可能需要“关闭”某些处理功能，因为数据处理现在由通过访问提供者实现调用的新功能进行。
• 必须对新访问机制强制执行现有的访问权限以及安全性与审核需求。
• 可能需要对现有系统的服务质量（Quality of Service，QoS）进行扩展或补充。例如，替换处理解决方案可能需要涉及脱机批处理方面的内容。
• SOA 可能会给现有系统带来新的无法预见的负载，从而对现有流程造成负面影响。

为了参与 SOA 而将遗留 IT 系统公开时，支持转换的范围外的业务操作的某些功能将继续进行数据处理。这通常要求了解和处理数据传播和同步问题。

用户将继续使用原始应用程序方法调用遗留 IT 系统，通常通过用户界面（如大型机哑终端或已打包应用程序的 UI）。SOA 依赖于一组用于描述在 SOA 生态系统中传递的消息的数据模式。这些数据模式实现为集成在协作服务操作集中的物理数据消息；这可以包括运行时数据转换和语义映射或消息数据的扩充。将随后由基础遗留 IT 系统使用和处理此数据。

可以使用 SOA 执行的流程集依赖于需要处于特定状态的一组集合数据和内容。通过 SOA 功能和遗留 IT 系统的并行处理可能会导致该状态模型中出现不稳定的情况。

在图 1 的示例中，此转换允许具有直接处理能力的新 Internet 应用程序设置和管理客户的保单。新应用程序可以触发与客户的接触，并在保单快要错过续签期限时给出续签协议。不过，SOA 范围外的有些现有业务操作可能会带来问题。客户可以通过很多方式通知公司自己已搬家。尽管保单最先是通过新 Internet 应用程序购买的，客户可能不会使用该 SOA 应用程序通知公司自己的地址发生变化，可能会转而采用寄信的方式。后台办公流程会导致客户的新地址仅应用到客户关系管理（Customer Relationship Management，CRM）系统。现有 CRM 系统的批处理会在夜间使用客户数据更新保险联系人管理系统。由于新的基于 SOA 的系统是围绕类似于实时的事务设计的，因此现在将导致同步时间问题。在同步期间，新应用程序可以尝试使用旧地址就续签事宜联系客户，而事实上能识别上下文的响应型 SOA 应用程序应该使用新地址取消旧保单，并设立新保单与此人联系。

服务提供者

从理论上而言，SOA 架构师角色应该考虑采用服务的基础设施的设计与实现。SOA 建模技术可指导您决定流程和信息将要使用的服务，与服务提供者联系，并构建应用程序来调用作为流程执行和数据处理一部分的服务操作。服务使用者并不管服务提供者如何实现服务，只要服务声明自己将根据事先达成的契约（服务操作及其关联的 QoS）处理和管理数据即可。

在特定情况下，此模型可能可行，特别在从企业外提供服务提供者实现时。本文所讨论的是很多企业在目前引入 SOA 过程中所采用的具体而通用的方案。

事实上，总体解决方案架构师在 SOA 转换中要担当很多职责，特别在进行增量式转换的企业中更是如此。这些职责是在企业治理流程内进行的；有关更多信息，请参见文章“SOA 治理案例”（developerWorks，2005 年 8 月）。

首先，解决方案架构师考虑 SOA 基础设施的设计与实现；这包括确定将充当软件系统（形成服务提供者实现的一部分）的遗留 IT 系统。其次，解决方案架构师提供用于组装服务使用应用程序的开发流程和环境。这包括设计模式、标准以及工具环境。而第三，解决方案架构师必须认识到承担的全盘业务与 IT 体系结构责任。业务体系结构将说明采用功能和契约外包的业务策略的合理性。IT 体系结构将提供支持总体业务操作所必要的 IT 系统。在任何企业（包括大型企业）中，这通常都是很大的战术与战略应用程序投资组合。

要考虑的设计策略

为了构建支持总体企业遵从性的可靠信息管理体系结构，可能考虑采用针对此问题的各种设计策略与原则。

在业务流程分析中对范围变更进行规划

在转换项目进行期间，经常遇到这种情况，通过系统分析和设计发现了一些不希望出现的数据处理场景。可能需要将之前在范围之外的业务操作纳入范围中，以便能够对其进行修改，以接纳一组新系统。新的基于 SOA 的系统甚至可能需要提供内部应用程序，供这些已经更改的业务操作使用，如用于更新某些客户详细信息的外部处理步骤。

发布和订阅遗留实体变更

当作为服务者参与的遗留 IT 系统中已得到一致认可的实体和属性数据发生变更时，需要开发外部处理步骤来告知 SOA。理想情况下，这应该是实时的，但此工作实际经常以计划批处理活动的形式进行。在旧式非结构化应用程序中，向遗留 IT 系统应用指令代码来检测数据记录发生更改的时间的做法可能开销非常大。

您的企业必须进行的一项工作是，要评估遗留系统所拥有的数据以及系统通知更改的相关方的能力。如果频繁更改对 SOA 非常重要的数据，而遗留系统又无法生成记录级别的事件触发器（以便最好地进行日常批量提取工作），则可能会需要进行再工程，或替换遗留系统。确保业务服务的 QoS 与计划的工程工作一致。说明在进行事先计划的增量工程改进工作（如从关键服务数据每日批处理的方式过渡到实时的消息驱动处理）的情况下，QoS 将如何随时间的增加提高。

信息服务查询 Facade

信息管理服务的操作应该提供能够应用于数据或内容的简单操作。查询 Facade 隐藏了如何访问和操作信息以及如何跨多个物理 IT 系统的细节。基本上来说，查询 Facade 可以实现两个模式来实现数据集成。由于企业中存在很多方案和遗留系统，很可能将同时使用这两种方法来实现服务：

• 将数据带到查询中。将变化慢的信息整理到承载数据存储区（例如，仓库），并在其中对数据进行操作。可以在此处使用提取、转换和加载（Extract, Transform, and Load，ETL）技术。
• 将查询带到数据中。对于快速变化的事务数据，操作必须进入物理源中对其进行操作。可以使用连接器和适配器技术来进行此类访问（例如读取和更新）。

在 SOA 中，实际查询 Facade 可以使用各种模式实现，如联合 与填充（有关更多信息，请参见参考资料中的“数据集成应用程序模式”），还可以使用服务数据对象 (Service Data Object) 和数据访问服务 (Data Access Service) 等技术（请参见参考资料）。各个服务实现的总体设计模式将影响这些决策；有关更多信息，请参见“Toward a pattern language for Service-Oriented Architecture and Integration, Part 1”（developerWorks，2005 年 6 月）。但在此问题中，将需要对实现设计进行扩展，以让服务更为智能化。假定已经为遗留系统配备了发布实体数据变更的解决方案（达到认可的 QoS 水平），信息服务需要订阅变更（哪些数据和频率如何）并将变更应用到相应的基础物理系统，如执行数据同步的物理系统。

而这正是在体系结构的此处做出主要实体决策。哪个遗留 IT 系统应该视为主系统，在哪些事务场景中应这样处理？主数据管理技术可在此处为您的实现提供帮助，不过这些选项及决策（与遗留系统的集成能力进行权衡）应该是体系结构定义中非常重要的部分。

业务规则放置

到 SOA 的转换引入了新 IT 基础设施，其中包括集成中间件和新组合应用程序以及其他实体。业务规则不再包含在应用程序中。状态通过业务规则的执行有效地进行管理。作为开发信息管理设计的一部分，必须了解业务规则逻辑的类型和位置。

SOA 中的业务规则的类型包括：

• 引用完整性规则
• 应用程序行为规则
• 跨应用程序完整性规则
• 事务处理业务逻辑规则
• 数据实体处理规则，如存储过程

应该重用此类策略，而不是重新生成业务规则。随着 SOA 的引入，必须仔细地考虑现有业务规则和新业务规则的执行（以支持服务的可靠执行）。规则逻辑本身（无论其位于上下文中任何位置）可能需要作为服务公开，以便能调用来维护特定处理场景的完整性。

潜在设计策略影响

做出这些决策时必须考虑的解决方案的潜在影响包括：

• 双密钥处理。通过引入 SOA 而获得的业务领域的效率需要与额外的数据输入任务（从而增加了数据输入错误的风险）进行权衡。但这可能是用于处理数据同步时间确定场景的唯一选项。通常并不会轻视这些场景。您的企业需要建立人头计算来执行事件驱动的双密钥生成，从而避免由于夜间批量更新造成的时间延迟。需要通过在系统中开发自动接口来帮助进行数据同步，以抵消此成本。这个循环分析应该评估实现自动化接口（特别测试）所需的时间是否对总体交付时间表造成影响。
• 不必要的反馈循环。对 CRM 系统中的客户记录的更新之后紧跟对 SOA 的手动或自动调用，以告知其他应用程序这个意外的客户数据变更。为了更新客户，SOA 将调用其信息服务，该服务本身将调用原始 CRM 系统并更新客户数据。根据用法模型不同，信息服务体系结构需要实现不同样式的 update customer 操作。
• 范围渐变。定义 SOA 范围声明时，缺乏遗留 IT 系统的知识，不了解哪些流程和信息管理功能一定将更改。服务模型的派生对遗留分析起到促进作用，只会发现需要更多的 SOA 基础设施实现。在定义业务服务和工程计划的整体范围前，需要考虑发现阶段的预算和规划。

结束语

共享本文……

请 Digg 这个故事 发布到 del.icio.us Slashdot 一下!

为了让企业在所有操作上保持可靠性和一致，转换项目必须开发企业信息管理解决方案，而此方案中包括 SOA（但涉及的内容并不限于此范围）。此解决方案应该在 SOA 中跨 IT 系统处理数据和内容的一致性和同步问题，以便能将信息服务公开供使用。

负责交付 SOA 转换的解决方案架构师还必须在考虑总体受控的企业体系结构和预算的情况下，对遗留 IT 系统的功能与 SOA 的需求进行权衡。信息管理解决方案的实现策略中的数据集成技术和主数据管理因素。

致谢

我们感谢 Rick Robinson、Patrick Dantressangle、Bob Lojek 和 Claudio Cozzi 对本文进行审阅并提供了指导。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 阅读 Ali Arsanjani 的文章“基于服务的建模和架构”（developerWorks，2004 年 11 月），其中提供了有关构建 SOA 所需的分析和设计活动的更多信息。
  
  
• Tilak Mitra 的文章“SOA 治理案例”（developerWorks，2005 年 10 月）可增强您对 SOA 治理在 IT 部门是关键组织的企业中的重要性的认识。
  
  
• 从 IBM Patterns for e-business 了解关于数据集成应用程序模式的更多信息。
  
  
• Bertrand Portier 和 Frank Budinsky 撰写的“服务数据对象简介”（developerWorks，2004 年 9 月）提供了对采用服务数据对象的下一代数据编程的介绍。
  
  
• 了解关于服务数据对象规范的更多信息。
  
  
• Ali Arsanjani 的文章“迈向面向服务的体系结构和集成的模式语言，第 1 部分: 构建服务生态系统”（developerWorks，2005 年 8 月），讨论了有关 SOA 和面向服务的集成的迁移、建模、设计和实现模式。
  
  
• 了解关于 developerWorks 技术事件和网络广播的最新消息。
  
  
• IBM SOA 网站提供了 SOA 的概述，并说明 IBM 可以如何帮助您实现此目标。
  
  
• 有关 SOA 的更多信息，请访问 developerWorks 上的 SOA and Web services 专区。
  
  
• 访问 Safari 书店，浏览有关这些技术主题以及其他方面的书籍。

• 使用 IBM 试用软件开发您的下一个项目，可下载或索取 DVD 光盘。
  
  

• 参与论坛讨论。
  
  
• 参与 developerWorks Blog，从而参加到 developerWorks 社区中来。
  
  

作者简介

Jeremy Caine 是 IBM Global Business Services 的一名高级 IT 架构师兼技术策略顾问。他主要进行业务转换与系统集成项目、交付复杂 IT 系统、Web 技术解决方案和企业应用程序集成策略方面的工作，主要服务对象是金融服务与政府部门一类的客户。Jeremy 还是很多全球性 IBM 技术社区的活跃成员，积极向社区其他成员推广各种领先思想和为创建新产品及服务提供支持。他是一位具有丰富经验的方法领袖，同时还是 IBM 体系结构培训团队的成员。

Jeremy Caine 是 IBM Global Business Services 的一名高级 IT 架构师兼技术策略顾问。他主要进行业务转换与系统集成项目、交付复杂 IT 系统、Web 技术解决方案和企业应用程序集成策略方面的工作，主要服务对象是金融服务与政府部门一类的客户。Jeremy 还是很多全球性 IBM 技术社区的活跃成员，积极向社区其他成员推广各种领先思想和为创建新产品及服务提供支持。他是一位具有丰富经验的方法领袖，同时还是 IBM 体系结构培训团队的成员。