面向服务的体系结构：实现难题【转载】

 

发布日期： 6/21/2004 | 更新日期： 6/21/2004

本期的其他文章

通过建立并遵循能够将公司特有的各种标准结合起来的路线图来确保成功

Easwaran G. Nadhan

EDS 部门主管

摘要：本文讨论了各种用来解决企业在实现面向服务的体系结构时所面临的八个主要难题的方法，并提供了有关 EDS 在客户服务方面的经验的示例。

本页内容

	简介
	体系结构组件
	难题
	小结

简介

您很可能正在考虑在整个企业中部署面向服务的体系结构。在任一此类部署中，都会遇到一些复杂的难题，其中包括您的行业和公司所特有的难题。然而，如果手中握有灵活的实现路线图，您就能够在难题出现时迅速采取行动来应对和解决这些难题。

面向服务的体系结构是一种重要的新范型，它支持在中间层以模块方式实现解决方案。当多个运行在各种技术和平台上的应用程序必须互相通讯时，这些体系结构尤其适用。

然而，面向服务的体系结构不是一夜之间就能实现的。企业必须首先加快行动步伐并致力于逐步构建相关的组件和服务。为确保在企业范围内系统地实现这样一个体系结构，路线图和企业特有的标准是关键的前提条件。

本文提供了各种不同的方法，以供企业用来解决各种与实现相关的难题。本文中的示例尽可能地基于 EDS 在为客户提供服务时获得的实际经验。本文还利用了 EDS 在构建便于在企业内部配置、管理和部署 Web 服务的工具时所获得的经验。

返回页首

体系结构组件

图 1 显示了面向服务的体系结构的基本组件。面向服务的体系结构的组件包括：

·	服务提供者。服务提供者是一个或一组以无状态方式执行业务功能的组件，接受预定义的输入和输出。
·	服务使用者。服务使用者是一组有兴趣使用服务提供者所提供的一项或多项服务的组件。
·	服务储备库。服务储备库包含服务的说明。服务提供者在该储备库中注册其服务，而服务使用者访问该储备库以发现所提供的服务。

图 1. 面向服务的体系结构组件

返回页首

难题

在实现面向服务的体系结构时，企业最多会面临八个主要难题。这些难题分别对应一个典型项目部署计划的各个步骤：

1.	服务识别。什么是服务？给定的服务要提供哪种业务功能？该服务的最佳粒度是什么？
2.	服务定位。服务应该位于企业内部的什么位置？
3.	服务域定义。应该如何将服务组合到逻辑域中？
4.	服务打包。如何对旧式主机系统中的现有功能进行再设计或者将其包装到可重用的服务中？
5.	服务协调。如何协调复合服务？
6.	服务路由。如何将来自服务使用者的请求路由到适当的服务和/或服务域？
7.	服务控制。企业如何实施控制程序以便管理和维护服务？
8.	服务消息处理标准的采用。企业如何始终如一地采用给定的标准？

我将详细地讨论这些难题，并研究可用来解决这些难题的方法。我将在适当的位置提供有代表性的实际示例。

服务识别

难题

正确地识别服务并确定相应的服务提供者是设计面向服务的解决方案的至关重要的第一步。在当今世界，类似的业务功能很可能由企业内部的多个系统提供。

方法

解决这一难题的方法有两种：服务合理化和服务合并。服务合理化涉及到对提供给定业务功能的所有系统和应用程序进行仔细的分析。通过服务合理化，可以将访问次数最少的系统所支持的业务功能转移到访问次数较多的系统中加以实现。用这种方式对系统进行简化以后，我们就可以更加一致地提供服务。

图 2. 帐户资料管理服务合理化

图 2 提供了一个服务合理化示例。许多前端应用程序（如联机银行业务、CRM 和 VRU 应用程序）都需要通过“帐户资料管理”业务功能来接收信息。客户和帐户储备库是支持“帐户资料管理”业务功能的记录系统。根据调用该业务功能的前端应用程序的特性，将返回帐户资料的不同子集。

在该示例中，企业要增加其客户的联机访问和 VRU 访问，而要减少需要大量人工交互的 CRM 应用程序的使用。随着客户迅速适应自助渠道，通过 CRM 应用程序进行访问所占的百分比正稳步下降。作为服务合理化过程的一部分，还将扩大基于 VRU 和联机银行业务的帐户资料管理服务范围以实现 CRM 帐户资料管理业务功能。这样，合理化就消除了 CRM 帐户资料管理服务以及支持它的两种服务的定义。

服务合并

服务合并涉及到将所有服务实例重新定义为一个统一的版本，该版本支持各个实例所公开的所有接口的超集。经过重新定义和合并的服务由所有独立的应用程序一致提供。

图 3. 产品目录服务合并

图 3 阐释了由三个独立的服务访问的产品目录储备库。这些服务专门用于检索有关某种产品的可用信息的预定义子集。在进行服务合并以后，将只剩下单个服务来处理整个产品目录。该服务包含各个服务在合并前利用的所有信息段。服务使用者有选择地使用它们感兴趣的那一部分目录。因此，服务合并是对支持同一业务功能的多个服务进行简化的一种有效方式。

服务定位

难题

服务通常对驻留在给定记录系统中的一组特定的业务实体进行操作。该记录系统是执行服务的理想场所。然而，如果采用分布式体系结构解决方案，则可能会将业务数据传播到多个应用程序中，并可能为同一业务实体生成多个记录系统实例。在这两个系统之间进行数据同步就成为一项关键要求。在此类方案中，应该将服务放在何处？

方法

解决这一难题的方法有三种：基于内容的路由、基于服务储备库的路由以及后端复制。

基于内容的路由

该方法会将该服务的传入请求路由到适当的记录系统。这种解决方案为服务使用者提供了位置透明性支持：用于确定在何处提供给定服务的算法不需要向服务使用者公开。两个记录系统都支持该服务的一个实例，并且这两个服务实例都可充当给定请求的逻辑入口点。

图 4. 基于内容的路由

图 4 阐释了基于内容的路由的一个示例。在该示例中，有关客户的信息按区域分开存储。属于给定区域的客户存储在位于该区域中的数据中心的储备库中。然而，位于任一区域的服务使用者都可以访问该信息。在收到传入请求后，客户资料管理服务将执行一条业务规则，以便确定存储了有关给定客户的信息的特定储备库。然后，客户资料管理服务会将给定的请求路由到适当的区域。

基于服务储备库的路由

图 5 显示了基于服务储备库的路由方法，该方法是上述基于内容的路由方法的一个变种。尽管客户资料管理服务执行了与基于内容的路由方法相同的业务规则，但它利用服务储备库中的信息将请求定位到适当的区域。该方法使得在必要时更改路由逻辑变得更加容易。通过更新服务储备库中的信息，可以轻松地将请求重定向到不同的区域，而无须更改客户资料管理服务本身的业务规则。

图 5. 基于服务储备库的路由

后端复制

该方法利用固有的应用程序间连接功能，来访问包含所需信息的物理储备库中的信息。因此，两个记录系统实例都可以充当访问分布在这两个系统中的信息的逻辑入口点。服务可以在其中任何一个系统中执行。所操作数据的物理位置对于服务本身是透明的。图 6 阐释了后端复制的一个方案。同一客户资料管理服务在距离该服务最近的记录系统实例中执行。如果需要其他区域储备库中的信息，则将利用该数据储备库背后的技术所固有的数据复制功能来获取相关数据。

图 6. 后端复制

服务域定义

难题

通过将服务归类到多个逻辑域中，可以减少要设计的组件的数量，从而简化体系结构。可以出于多种体系结构的原因进行这种分组，例如负载平衡、访问控制、代理模拟以及业务逻辑的纵向或横向划分。然而，要使企业内部的不同业务部门和技术中心就适当的服务域定义达成一致意见，通常是一个重大的难题。如何对服务域进行良好的逻辑分组？

方法

我们可以采用多种定义服务域的方法。表 1 显示了一个在不同业务部门中分布应用程序和平台的示例。该示例将用于定义本部分中讨论的各个方法的显著特征。

表 1. 应用程序分布示例

业务部门	主要中间层平台	应用程序
住房贷款	UNIX	SAP
联机银行业务	Windows	Siebel
银行业务中心	UNIX	PeopleSoft
保险服务	Windows	SAP
消费者贷款	Linux	Oracle
公司贷款	UNIX	IBM DB2

功能域

功能域基于一组服务所提供的业务功能。最好由企业内部的业务处理所有者来定义和划分业务功能，并进而定义和划分服务域。通过这样的分组，给定域的业务处理所有者可以自行控制该域内部的服务。只要业务处理所有者确保将其各自域中的指定服务提供给企业的其他域，他们就可以对服务的体系结构和实现进行完整控制。

在上面的示例中，有三个功能服务域：贷款、银行业务和保险。这些域中驻留的服务可能必须越过多个平台和后端应用程序来处理特定于其所在域的传入请求。然而，在给定域内部，服务所提供的业务处理都是类似的，而无论用来执行服务的应用程序或平台是什么。

1.	贷款 贷款服务域中驻留的通常是一些在向客户和公司实体发放贷款并管理这些贷款的背景下提供的服务。该服务域既包括用于购买住宅的抵押贷款，也包括用于购买除住宅以外的其他资产的贷款。服务可能包括贷款的议定、贷款的分期偿还以及每月付款计算。
2.	银行业务 银行业务服务域中驻留的服务通常与通过多种媒介（如 Internet、ATM、VRU 和金融中心）执行的银行业务相关联。可能的服务包括开户、检索帐户余额以及在帐户之间转帐。
3.	保险 保险服务域包含保险业所特有的服务。可能的服务包括保险费计算、病历检查以及索赔处理。

基于技术的域

跨越多个技术平台的功能服务域造成了一个固有的难题，即随时把握各个技术平台的状态。供应商倾向于按照有利于其解决方案的方式来解释业界标准，并迫使企业依赖于他们的体系结构、硬件和/或软件。通过基于技术的服务域的规范，可以直接有效地利用相应技术的独特功能。

在上面的示例中，服务域可以按照 UNIX、Linux 和 Windows 平台来进行划分。基础性服务（如错误记录、事务监控和事件处理）都可以作为此类服务予以实现。它们都依赖于执行的平台，并且通常都独立于驱动功能服务域的业务处理。

基于应用程序的域

作为企业摆脱更换现有系统需要的一种方式，企业应用程序集成的概念应运而生。今天，企业所具有的许多个多前端应用程序都需要与相同的记录系统进行集成，以便用不同的方式处理、打包和呈现相同的信息。

通过基于应用程序的服务域，可以组合给定系统上提供的服务。这样一种方法可以简化服务的管理和维护，因为对于该域中的所有服务而言，底层系统是相同的。

在上面的示例中，SAP、Siebel、PeopleSoft、IBM DB2 和 Oracle 都可以作为基于应用程序的服务域予以实现。下面列出了这些域中可能驻留的一些示例服务。

SAP

·	应付帐款-应收帐款对帐
·	财务会计

PeopleSoft

·	增加雇员
·	赔偿更新

Oracle

·	数据复制
·	基于角色显示帐户信息

服务打包

难题

在面向服务的体系结构中，企业的系统必须将功能作为服务公开。为便于集成而构建的系统可以更容易地做到这一点，而基于主机的旧式系统则会有更多的困难。当构建这些系统时，它们充当了整体式应用程序，其中包含涉及到的所有业务规则和处理逻辑。这些信息被分布到多组互连的程序中。

面向服务的体系结构鼓励各个服务成为独立服务，且无需了解其他服务的上下文。主机程序深深地纠缠于特定于上下文的知识。如何将这样的主机程序重新包装为独立自主的服务呢？

方法

我们可以使用一种由三个步骤组成的方法来解决这一难题。该方法涉及到定义主机解决方案内部的逻辑业务区域，向这些业务领域分配程序组，然后在这些程序组之间设计一个松耦合解决方案。下面对这些步骤进行详细介绍：

·	业务领域定义。在该步骤中，我们将建立业务功能的逻辑区域。我们可以使用程序调用图和进程流程图来定义这些业务区域。我们还可以通过利用主机系统中程序之间的关系来定义这些区域。[主机系统中的程序倾向于互相联系。在这种程序对程序关系的背后，有着共同的底层业务处理。]
·	程序分配。在标识业务区域之后，我们将各个程序分配到给定的业务区域。我们可能需要重新设计那些不太适合特定业务区域的程序，以使它们更加匹配给定的业务区域。这样的程序分组正好与前面讨论的服务域概念相对应。
·	松耦合集成。此时，即使这些程序已分配到已标识的业务区域，它们之间仍然是互相联系的。在最后一个步骤中，我们将使用耦合度更低的方法来替换这种紧耦合关系。为此，我们重新定义了主机程序接口，以使其他应用程序可以利用它们；这些程序将像原来一样提供相同的输入并接受相同的输出。这一重定义过程提供了一个很好的机会，可以确保这些程序为企业提供整体服务，而不是为彼此隔离的单个应用程序提供服务（后者正是最初创建这些程序的目的）。该方法还可以推动现有的主机程序向更加面向服务的方法演变，并将它们定位为由主机系统外部和内部的服务使用者使用的服务。

服务协调

难题

给定服务存在的原因是至少有一个服务使用者实例启动了对该服务的请求。然而，在某些方案中，一个服务可能必须调用许多其他服务来满足服务使用者的最初请求。简单的方案涉及到给定服务将最初的请求延伸到一个或多个服务。不过，复杂的方案可能涉及到对多个服务的递归调用，并且在某些极端情况下，还可能涉及到对多个服务的彼此依赖的调用 — 这可能会导致死锁。

下面是一个示例。要售出一张飞机票，需要执行以下服务：

获得客户

获得时间表

检查是否有票

报价

收款

在各个服务中融入协调智能可以得到相当复杂的方案，如图 7 所示。

图 7. 服务协调难题

如何协调这类复合服务？

业务处理管理方法

该方法使各个服务保持简单：这些服务不具有协调对完成请求所需的所有其他服务进行程序调用的智能。

相反，该智能被置于业务处理层中。业务处理负责对其中的各个服务进行程序调用，从而提供服务使用者最初请求的复合服务。该业务处理成为复合服务的专用实例。

图 8. 业务处理管理方法

图 8 阐释了“买票”业务处理，它包含要执行的各个步骤的程序逻辑。“买票”业务处理通过单独访问服务储备库来发现所包括的服务，随后按顺序协调适当的步骤。

服务路由

难题

面向服务的体系结构必须向服务使用者提供位置透明性：服务使用者必须能够向位于任何服务域中的任何服务发送请求。同时，在每次调用服务前访问服务储备库可能是一个非常耗费时间的过程。这些体系结构如何能在提供位置透明性的同时，确保达到可以接受的系统性能级别？

方法

我们可以用两种方法解决服务路由难题。

智能服务

使用该方法时，我们将所有服务的位置信息嵌入到每个独立的服务中。这可以消除所需的某些步骤，但会导致服务超载。根据这些服务及其位置发生更改的频率的不同，该方法可能需要大量的维护工作。此外，这样的方法并不符合服务所采用的松耦合体系结构。尽管如此，它仍然支持高性能的解决方案。

路由器

另一种方法是将路由智能从各个服务移到路由组件中。这些路由组件可以位于两个级别：服务域和服务。

1.	服务域路由器 服务域路由器具有与所有服务域的位置有关的智能。在收到请求后，它将确定是否能够通过它所支持的其中一个服务来处理给定的请求。如果是，它将处理该请求。如果否，它会将该请求传递给可以处理该请求的相应域。
2.	服务路由器 服务路由器用在服务域内部，以便将传入请求定向到该域中的适当服务。只有那些可以在给定服务域内得到处理的请求才会被传递给服务路由器。服务路由器可减少各个服务中位置信息的负载。

服务域路由器和服务路由器更适用于那些含有大量服务的服务域。如果只有少数几个服务，则智能服务是一种可行的选择。

图 9. 服务域路由器和服务路由器

图 9 阐释了服务域路由和域内部的服务路由的概念。

服务控制

难题

无论在企业内部定义服务域的方式如何，都有各种用来创建新服务和修改现有服务的哲学的和技术的方法。应该由谁来监控、定义和批准对企业内部所支持的现有服务套件的更改？应该由谁来负责这些服务的供应和维护？

方法

企业可以通过建立内部的控制机构来最有效地解决这一难题。可以采用多种控制模型。下面将对其进行讨论。

中央控制

使用中央控制，企业内部的控制机构既有来自各个服务域的代表，也有来自不直接对任何服务域负责的独立团体的代表。还必须有来自不同业务部门的代表，以及能够对解决方案的主要技术组件提出见解的项目专家代表。中央控制机构作为一个整体来审核服务的添加和删除以及对现有服务所作的更改，然后才决定是否批准予以实现。

图 10. 中央控制模型

如上面的图 10 所示，中央控制机构负责在整个企业中建立和实施面向服务的体系结构准则和标准。该机构还负责将这些标准传达给业务部门、体系结构团队以及技术团队。

分布式控制

使用分布式控制，每个业务部门都可以自主控制在其自身组织内部提供服务的方式。分布式控制要求采用功能服务域方法。服务体系结构委员会仍然可以提供服务实现方式的高级准则和标准，但对业务部门内部的现有服务基础结构的更改不必征得该委员会的批准。该委员会可以建议遵循这些准则，但并不负责实施它们。

图 11. 分布式控制模型

在图 11 中所示的分布式控制模型中，业务部门 A 和 B 可以自由建立他们自己的独立标准。但是，仍有一些现成的非强制性措施（体系结构和程序准则）供这些部门去遵守。

服务消息处理标准的采用

难题

特定于纵向行业的消息处理标准用于对一组数据元素和消息格式实施标准化。然而，在各个数据元素级别，这些标准具有足够的灵活性，使企业可以对它们进行定制以适应企业特有的业务环境。因此，同一企业内部的不同业务部门可以使用多种方式来遵循相同的标准。另外，这些标准还提供了创建自定义数据元素的方式。

例如，Interactive Financial Exchange (IFX) 标准指定了对客户进行唯一标识的多种方式：

·	它是唯一标识客户的内部数据库项。
·	它是客户用于登录的 ID。

这两个字段都是唯一的。采用 IFX 标准的企业必须决定在什么时候以及在哪里使用各个字段。在与此类似的一些情况下，客户已经决定忽略这两个字段，而创建能够更好地适应其企业记录系统的自定义字段！

如何才能在整个企业中强制采用单一标准呢？

元数据控制方法

企业内部的元数据储备库支持对主要业务实体采用一致的表示形式。这些表示形式是分布在多个企业系统中的信息的超集。数据词典以及逻辑和物理数据模型是元数据储备库的定义和维护的主要输入内容。

元数据控制团队应是前面讨论的中央控制模型中的专门组织。元数据控制必须在企业级别执行。换言之，即使企业对服务的维护普遍采用了分布式控制模型，也必须对元数据采用中央控制模型。

在上面的示例中，客户的元数据应包含对客户进行唯一标识的单一方式。此外，元数据应确保以一致的方式表示身份验证信息，包括登录名和密码。因此，即使某个公司已经选择使用自定义字段来唯一标识客户，该字段在元数据储备库中仍将以上述方式表示。

返回页首

小结

面向服务的体系结构正在迅速地被 IT 领域接受，以作为在扩展的企业中构建和部署服务的合理的模块化方法。然而，实际实现这些体系结构时需要进行认真的计划。感兴趣的企业必须首先确保他们已做好长期实现和支持这些体系结构的准备。

通过制定和遵循实现路线图，企业可以提前解决他们将在完成这一工作的过程中遇到的一系列难题。每个企业都将面临一组独特的难题，而解决这些难题的相应方法也将各不相同。这些难题在实现过程中以及实现之后所具有的影响还取决于相关企业的环境。

关于作者

Easwaran G. Nadhan 是 EDS (Plano, Texas) 的 Solutions Consulting 部门的主管。在过去 20 年时间里，Nadhan 一直从事软件行业中分布式解决方案的设计和实现工作。近来，Nadhan 利用他在企业应用程序集成方面的经验与许多企业进行合作，以实现面向服务的体系结构。本文档中的示例基于在 EDS 以及 EDS 所服务的组织中经历的实际案例。读者可以通过以下电子邮件地址与 Easwaran Nadhan 联系：easwaran.nadhan@eds.com