2007 年 8 月 28 日 面向服务的体系结构(Service-Oriented Architecture,SOA)是很多业务转换工作的核心。很多企业采用增量式方法进行 SOA 转换,使用其宝贵的遗留 IT 系统作为服务提供者参与其中。解决方案架构师面临的挑战不仅是将 SOA 基础设施作为促进转换的手段交付,而且还要确保企业级业务操作保持可靠性和兼容性。您的企业必须制定可作为 SOA 一部分的企业信息管理策略,并跨所有业务操作保持总体数据和内容的一致性。本文介绍了此类转换中面临的挑战,并将讨论一些值得考虑的设计策略。 如果您的企业和大部分企业一样,则您的业务战略和核心竞争力分析已经确定了需要在哪些领域重点关注业务再工程和 IT 现代化。一个典型的结果(至少对于企业的某些核心方面如此)是转换到面向服务的业务,开始依赖 SOA。业务操作是围绕一组服务设计的,而这要求对当前 IT 系统进行再工程,并将其作为服务提供者加以集成。此转换还可能引入一些新的服务提供者。目标是能够构建新的组合应用程序(如内部工作区门户应用程序或 Internet 商业应用程序),从而高效地处理特定的业务需求。 作为这个充满挑战的转换工作的一部分,企业通常会开展一系列重大的业务与 IT 项目。主要的转换交付内容包括:
转换的这些主要交付内容带来了一组略微次要的派生挑战。这些可确保企业按照其转换意图进行交付,并能够监视和适应更改,从而实现灵活性。这些转换挑战通常要遵循以下原则:
有些企业非常幸运,能够在整个企业内进行到 SOA 的业务转换。此方法要求为主要转换交付内容提供更富有挑战的实现,但最终能提供一个更便于发展和开发次要转换交付内容的环境。当希望在整个企业内驱动业务和 IT 变更的 C 级别的执行人员积极地帮助实现策略计划时,通常会出现这种情况。 不过,大部分企业转换都是增量式的——虽然很重要而且也采用了相应的策略,但是逐步进行的。这通常意味着将对遗留 IT 系统进行再工程,以使其参与新业务操作的支持——例如,与其他 IT 系统进行组合,以加速客户订单的直接处理。这些 IT 系统还需要执行所有(或者至少是大部分)当前功能。SOA 转换范围外 的业务操作将仍然继续。 在此转换场景中,必须仔细考虑 SOA IT 基础设施的实现设计。在这些 IT 系统内的数据处理影响范围外的数据处理,同时也受到范围外的数据处理的影响。总体数据处理环境必须继续保持可靠性和与总体业务操作的兼容性。 图 1 中的示例显示了三个再工程为服务提供者的遗留系统。 图 1. 新 SOA 环境中的遗留 IT 系统 在图 1 中,业务转换项目已经构建了 SOA 基础设施,业务服务通过此基础设施进行发布,并供新应用程序使用。此基础设施通常包括用于支持软件间多协议连接、异步与同步消息流管理、消息转换、规则执行和流程编排的中间件。已经构建了使用这些服务的组合应用程序,甚至遗留系统本身也已经通过新服务调用得到了增强。
要实现 SOA 基础设施,所生成、维护和增强的主要资产是业务服务模型。要使用得到广泛认可的技术来开发该模型,如 IBM® 面向服务的建模与体系结构(Service Oriented Modeling and Architecture,有关更多信息,请参见参考资料)。在典型的企业中,这将混合使用自顶向下分析、自底向上分析和目标-服务建模。转换的业务目标将派生出流程与信息体系结构,用于驱动新业务操作的实现和支持 IT 应用程序:
流程和信息体系结构观点通常一起形成并通过流程数据 (CRUD) 矩阵之类表现出来。它们一起定义组成服务体系结构的一系列服务。服务是一组在消息数据传入时调用的操作。服务实现执行操作数据或内容的处理(通常通过持久存储或访问),并返回结果。可以同步和异步使用服务,调用通常由集成基础设施代理。在完全分离的系统中,有些服务负责流程状态的更改(例如,将信息表示为已请求,将客户 X 的新地址表示为已验证)。其他服务负责对信息状态进行更改,确保将已经进行了操作的数据和内容置为所需的状态,以作为以后的服务事件的依赖(例如,客户 X 的新运输地址已生效)。
遗留 IT 系统无疑将作为您的企业服务提供者实现的一部分,将集成到 SOA 基础设施中。遗留系统不仅包括传统大型机处理,而且也包括企业资源规划(Enterprise Resource Planning,ERP)应用程序、内部和外部 Web 应用程序、工作流应用程序、扫描与打印系统等等。可以进行很多工作来支持使用这些遗留系统并将其集成到服务提供者实现中:
为了参与 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 隐藏了如何访问和操作信息以及如何跨多个物理 IT 系统的细节。基本上来说,查询 Facade 可以实现两个模式来实现数据集成。由于企业中存在很多方案和遗留系统,很可能将同时使用这两种方法来实现服务:
在 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(但涉及的内容并不限于此范围)。此解决方案应该在 SOA 中跨 IT 系统处理数据和内容的一致性和同步问题,以便能将信息服务公开供使用。 负责交付 SOA 转换的解决方案架构师还必须在考虑总体受控的企业体系结构和预算的情况下,对遗留 IT 系统的功能与 SOA 的需求进行权衡。信息管理解决方案的实现策略中的数据集成技术和主数据管理因素。 我们感谢 Rick Robinson、Patrick Dantressangle、Bob Lojek 和 Claudio Cozzi 对本文进行审阅并提供了指导。 学习
|
联系客服