介绍

　　你可能考虑过在你的企业中实施SOA。在这个实施过程中，会遇到复杂的挑战—包括那些仅对你的公司和产业存在的挑战。然而，通过一种灵活的路线图去控制实施SOA，你可以在遇到这些挑战时很快的面对并解决它们。

　　SOA是一个重要的新的架构范例，它支持中间层解决方案的模块化实现。尤其适用于当多个根据不同技术开发的应用软件在不同的平台上运行时，平台间相互交互的情况。

　　然而，SOA并不是一夜醒来就可以顺利实施的。企业首先必须朝着构建先进的组件和服务的方向努力。一个路线图和企业特有标准是必备的先决条件—以保证这个架构在企业系统化的实施。

　　这篇文章针对企业实施SOA将遇到的各种挑战提供了不同的解决方法。基于EDS与客户的实践给出了一些例子。同时，还在构造一个工具时根据EDS的经验进行调节，这个工具为企业网络服务的配置、管理和部署提供了便利。

　　架构组件

　　图1显示了一个SOA架构的基本组件。这些组件包括：

　　服务提供者. 一个服务提供者是一个组件或组件集，在无状态方式下完成商业功能，接受预定义的输入和输出。

　　服务消费者. 一个服务消费者是一个组件集，有兴趣去使用一项或多项由服务提供者提供的服务。

　　服务仓库. 一个服务仓库包括对服务的描述。服务提供者在服务仓库中记录他们提供的服务，而服务消费者接受服务仓库来查找提供的服务有哪些。

　　图 1. SOA架构组件

　　挑战

　　在企业实施SOA时，需要面对的关键挑战有八个。这些挑战在一个典型的工程部署计划中排列如下：

　　服务识别.服务是什么？一个指定的服务能够提供什么样的商业功能？如何提供最佳粒度的服务？

　　服务场所. 在企业内，哪里是服务场所的最佳位置？

　　服务范围定义. 这些服务如何集合进逻辑领域？

　　服务打包. 现存的原有主机系统提供的功能如何工程化包装为可再度使用的服务？

　　服务协调. 这些复杂的服务如何协调？

　　服务发送. 服务消费者提出的要求如何发送到适当的服务或服务领域？

　　服务管理. 企业如何按步骤在管理和维持服务？

　　服务通信标准采用. 企业如何长期采取一个特定的标准？

　　服务识别

　　挑战

　　构建SOA时，正确的识别服务和确定相应的服务提供者是一个关键的首要步骤。现今世界，在企业内部，类似的商业功能可以由多个系统提供。

　　方法

　　解决这个挑战有两个方法；服务合理化与服务合并。服务合理化是对所有提供特定商业功能的系统和应用平台进行一个仔细的分析。通过服务合理化，由少量访问系统实现的商业功能可以在海量访问系统平台。在流线型系统上使用这种方法，我们可以传送更多可靠的服务。

　　图2 . 服务合理化账号配置

　　图2提供了一个服务合理化的例子。大量的前台应用，比如在线银行、CRM与VRU，需要账号配置商业功能提供的相关信息。客户与账号库的信息记录系统应该支持账号配置商业功能。根据前台应用的特性调用这个功能，可以返回账号配置的各个子集。

　　在这个例子中，企业为客户增加在线与VRU访问的同时，减少了需要人类交互的CRM的使用。

　　服务合并

　　服务合并主要将所有各种服务合并成一种服务方式，这种方式支持多个个体服务表现出的用户界面的扩展。这种合并后重定义的服务可以被各个独立的应用系统稳定的提供。

　　图3 . 服务合并产品目录

　　图3说明了一个产品目录库如何被三个独立的服务访问。三个服务被用来寻找一个产品相关信息的预定义子集。在服务合并后，只有一个服务来提供全部产品目录。这个服务包括了各个独立服务在服务合并中提供的信息。服务消费者选择产品目录中感兴趣的部分。服务合并就这样成为一种高效率的方式帮助大量流线型服务支持同样的商业功能。

　　服务场所

　　挑战服务经常在一个特定记录系统上的特定商业实体集上执行。这个记录系统是服务执行的一个理想场所。然而，分布式架构解决方案将导致商业数据通过多个应用平台扩散，而同样商业实体将产生大量由记录系统产生的记录。两个系统间的数据同步就成为一个关键需求。这种情况下，哪里才是最佳服务场所呢？

　　方法

　　这里有三种方法来解决这个挑战；基于内容方法，基于服务库方法，与后端复制方法。

　　基于内容方法

　　这个方法将收到的服务请求发送到正确的记录系统。此解决方案支持服务消费者眼中服务场所透明化：算法确定服务消费者并不知道一个特定服务是在哪里提供的。给出一个请求时，记录系统支持服务被打包为一个逻辑体。

　　图4 . 基于内容方法

　　图4说明了一个基于内容方法的例子。在这个例子中，消费者的相关信息被按区域隔离开来。属于特定区域的消费者信息被储存在数据中心特定区域的库中。然而，任意区域的服务消费者都可以访问这些信息。接收到服务请求后，消费者配置服务执行一个商业规则来确定对消费者有用的信息在哪个特定区域中存储。然后，消费者配置服务再将这个请求发送到找到的区域。

　　基于服务库方法

　　上面描述了一个基于内容方法的变化，基于服务库方法显示在图5中。消费者配置服务执行与基于内容方法同样的商业规则时，协调服务配置的信息来指引服务请求到正确的区域。这种方法使得必要时改变服务请求发送逻辑更容易。通过改变服务配置信息，服务请求可以被很容易的发送到不同的区域，不用再改变消费者配置服务自身的商业规则。

　　图5 . 基于服务库方法

　　后端复制方法

　　这个方法协调内在的交互应用连接能力去访问包括指定信息的物理库。这样，各个记录系统可以像逻辑接口一样去访问分布在系统上的信息。这个服务可以在每个记录系统上执行。这些被操作的数据的物理位置对服务本身是透明的。图6说明了一个后段复制方法的情况。同样的消费者配置服务在靠近服务的记录系统被执行。当其他区域库的信息被请求时，存在于数据库的技术提供的的内在数据复制能力可以支持获取相关数据。

　　图6 . 后端复制方法

　　服务范围定义

　　挑战

　　将服务按照逻辑区域分类减少了组件的数量，从而简化了结构。因为一些结构上的原因，这些组可以被协调：负载平衡，存取控制，代理模拟，与纵向或横向的商业逻辑区分。然而，对于企业内的商业部门与技术中心来说，要在定义一个正确的服务范围上取得一致，经常有一系列的挑战。什么才是一个好的服务范围逻辑组呢？

　　方法

　　我们可以选择多个方法来定义服务范围。表格1显示了一个跨商业部门的应用和平台分类例子。这个例子将用来说明在这部分中讨论的每种方法的重要特征。

　　商业部门　　主要中间层平台　　　应用
 
　　家庭贷款　　　　　UNIX　　　　　　SAP
 
　　在线银行　　　　　Windows　　　　Siebel
 
　　金融中心　　　　　UNIX　　　　　PeopleSoft
 
　　保险服务　　　　　Windows　　　　　SAP
 
　　个人贷款　　　　　Linux　　　　　Oracle
 
　　企业贷款　　　　UNIX　　　　　　IBM DB2
 
　　功能范围

　　功能范围以一个特定服务集合的商业功能为基础。最好安排企业内的商业过程所有者来定义和隔离商业功能以及对应的服务范围。通过这样分组，某一特定范围的商业过程所有者可以自己控制此范围内的服务。只要商业过程所有者确信在他们各自范围内的服务也被提供给了其他企业，他们就完全控制了对这个服务的架构和应用。

　　在上面的例子中，有三个功能服务范围：贷款，金融和保险。在这些领域内的服务必须跨越多个平台与后端应用来处理属于他们领域的请求。然而，这些商业处理在一个特定领域内使类似的，不管执行服务的是那些应用或平台。

　　贷款. 贷款范围覆盖服务显然包含在放出和管理贷款给消费者和企业用户中。这个服务领域包括住房抵押贷款与购买其他价值等同于住房的商品的贷款。服务可能包括借贷、分期还款与利息计算。

　　金融. 金融范围覆盖服务显然通过大量媒介与金融有联系，这些媒介包括网络，ATM，VRU和金融中心。服务可能包括开设一个账户，查询帐户余额与账户间的转帐。

　　保险. 保险范围覆盖服务仅包括对保险产业的服务。服务可能包括保险费计算、医疗历史查找与投诉处理。

　　基于技术范围

　　跨越多个技术平台的功能服务范围使得保持与每一个技术平台同步的内在挑战时时存在。出售方努力用一种方式揭示工业标准来支持他们的解决方案并使得企业依赖于他们的架构，硬件和软件。基于技术的服务范围规范允许特定技术能力的高效使用。

　　在这个例子中，服务范围可以按照UNIX，Linux与Windows平台分类。基础服务比如错误记录，事务监控与时间处理是这类服务很好的处理对象。他们依赖于运行平台，但独立于驱动这个功能服务范围的商业过程。

　　基于应用范围

　　作为一种帮助企业面对更新现有系统需求的方法，企业应用集成的概念应运而生。现在，企业拥有大量前台应用系统，因此需要集成这些类似的系统，通过不同的方式处理、打包并提出同样的数据。

　　基于应用服务范围允许一个特定系统提供分组服务。这种方法使得管理和维持服务更加容易，因为一个领域内的系统对所有的服务都是一样的。

　　在上面的例子中，SAP，Siebel，PeopleSoft，IBM DB2与Oracle都是很好的基于应用范围的客户。这些范围中的一些典型服务列在下面。

　　·SAP

　　账户支付—帐目核对

　　财政计算

　　·PeopleSoft

　　增加雇员

　　更新补偿

　　·Oracle

　　数据复制

　　基于账户信息的角色说明

　　服务打包

　　挑战

　　在SOA中，一个企业系统必须功能以服务为主。方便集成的构造系统可以很容易的做到这一点。面向结构的系统有一些困难。是一些集成电路应用构造了这些系统，系统包括了所有的商业规则与过程逻辑。这些信息被分配给多个多个连接程序的集合。

　　一个SOA支持独立的服务—没有任何其它服务的相关知识。结构化程序与特定上下文紧密联系在一起。这些结构化程序如何被再次打包围独立的服务？

　　方法

　　我们可以使用一个共有三个步骤地方法来应对这个挑战。这个方法包括在架构方案中定义逻辑商业领域、为这些商业领域分配程序集、并使两个程序集之间松耦合关联。这些步骤在下面详细说明：

　　商业领域定义. 在这个步骤中，我们建立商业功能的逻辑域。我们可以使用程序调用规划图和过程流图来定义这些商业领域。我们也可以通过调节架构系统的程序间的关系来定义商业领域。[架构系统的程序往往是与其它程序有关。在这种程序到程序的关系中，有一些通用的商业方法。]

　　程序分配. 在标准的商业领域，我们分配独立的程序到一个特定的领域。我们非常需要再分配那些没有讲自己关联到对应商业领域的程序，使在特定商业领域内排列更有规则。在前面讨论过的服务范围概念的引导下，这样一组程序集可以排列的更好。

　　松耦合关联. 在这一点上，甚至即使这些程序已经在标准商业领域内排列过了，她们海狮需要彼此间相互关联。在最后这一步骤中，我们将原来的轻度耦合关联替换为一个更加松散的耦合。为了这样做，我们重新定义架构程序界面，这样其它的应用可以调节自己；程序提供同样输出并且接受同样输入，就像它们开始做的那样。这个重定义过程提供了一个非常好的机会来确保这些程序就像一个整体来服务企业，而不是单个程序独立服务企业—就像它们开始被创建时那样。这个方法同时也使现有架构系统朝着面向服务方向靠近，配置他们使它们在内部是结构系统，外部对服务用户来说是面向服务的。

　　服务协调

　　一个特定服务的存在是因为至少有一个服务消费者发出了这项服务的请求。然而，在一些情况下，一个服务不得不调用许多其它服务来满足服务消费者的原始请求。简单的情况导致一个特定服务扩展原始请求到一个或者更多其它服务上。然而，复杂的情况可以导致大量服务的递归调用，在一些极端的例子里，一些服务的内部依赖调用—可以导致死循环。

　　这里有一个例子。当一张机票被出售时，下面的服务需要被执行：

　　取得消费者
　
　　取得日程表

　　检查可用信息

　　提供费用

　　接受支付

　　构建协调能力使得每一服务在如此复杂情况下都能顺利执行

　　如图7所示。

　　图7 . 服务协调挑战

　　这些综合服务如何被协调？

　　商业过程管理方法

　　这种方法使独立的服务更简单：这些服务没有能力来协调其它为了满足请求而调用的服务。

　　替代性的，这种能力被放置于商业过程层。商业过程负责调用每一个子服务，这样来提供组合服务来满足消费者的原始请求。商业过程就成为一个组成服务的专业例子。

　　图8 . 商业过程管理方法

　　图8说明了这张机票购买的商业过程，包括每一个独立执行的逻辑步骤。这个商业过程通过一个简单的访问来查找服务，然后按顺序协调为适当步骤。

　　服务发送

　　挑战

　　SOA还要提供对消费者的地域透明性：服务消费者必须能够在任意服务范围内发送任意服务的请求。同时，在调用一个服务前访问服务库是一个减少时间的步骤。这些架构在保证可接受的系统性能水平的同时，如何提供地域透明性？

　　方法

　　我们能够用两种方法解决服务发送挑战。

　　智能服务

　　使用这种方法，我们为所有的服务建造各自的地域信息。这就消除了一些跳跃性的请求同时也导致了服务重载。考虑到服务以及服务所在场所的更新频率，这种方法有着持久性。另外，这种方法并不与松耦合的服务架构时刻一致。不过，他支持一个更高层次执行的解决方案。

　　发送

　　另一种方法是智能的移动将发送从一个发送组件移动到独立的服务。这些发送组件可以在两种层次：服务域和服务。

　　服务域发送. 一个服务域发送在所有服务域的场所上是智能的。当接收到一个请求，它确定是否它能够仅靠自己支持的服务来满足这个请求。如果能，它处理这个请求。如果不能，它将这个请求传送到正确的可以满足这个请求的服务范围。

　　服务发送. 一个服务发送在一个服务范围内被调用，在域内将请求发送到正确的服务。只有哪些可以在域内满足服务的请求被传递给服务发送。服务发送减少了各个服务上场所信息的负载。

　　服务域发送和服务发送对那些包括一定数量服务的服务域来说更加实用。对那些只有几个的服务，智能服务是一个可行的选择。

　　图9 . 服务域发送和服务发送
　
　　图9说明了一个域内服务域发送与服务发送的概念。

　　服务管理

　　挑战

　　不管一个企业以何种方式定义服务域，这里有几种哲学与技术上的方法来创建新的服务或修改现存的服务。谁来监控，定义和管理企业内这些对现存服务的改变？

　　方法

　　一个企业可以通过建立一个内部管理体来更有效的应对这个挑战。大量的管理模型都是可能的。下面讨论了一些。

　　中心管理

　　通过中心管理，企业内的管理体从各个服务域和各个没有直接依赖于各个服务域的部分得到说明。也必须从不同的商业部门和一些事件处理专家那里得到说明，这些专家可能在解决方案的关键技术组件上发表看法。中心管理体就像一个服务的删减后的完整回顾，也包括对现存服务的改变，在允许他们执行前。

　　图10 . 中心管理模型

　　如上面图10所示，中心管理体依赖于企业建立与执行SOA时的指导方针与标准。还依赖于通过这些标准与其他商业部门，架构小组和技术小组的交流。

　　分布式管理

　　通过分布式管理，每一个商业部门可以独立控制如何在自身组织内部提供服务。分布式管理要求一种功能性服务领域方法。一个服务架构委员会可以依旧提供高水平的指导方针的标准给服务执行，但是委员会不必批准商业部门内部对现有服务架构的调整。委员会可以建议与指导方针保持一致但不能强迫这样做。

　　图11 . 分布式管理模型

　　如图11 分布式管理模型所示，商业部门A与B都有权利来建立他们自己的独立的标准。然而适当的被动标准（架构和程序标准）都在适当的位置等候部门去遵守。

　　服务通信标准采用

　　挑战

　　对纵向工业来说，通信标准是不同的，这导致了基于一个数据元素集合和通信方式的标准。然而，在一个独立数据元素层次，这些标准是弹性的，企业能够适应它们来与企业特定商业限制保持一致。这样，同一企业内的不同的商业部门可以通过不同方式与统一标准保持一致。另外，这些标准还提供了客户数据元素的创建。

　　举例，IFX标准确定了多种方式对一个顾客：

　　〈客户唯一标识符〉内部数据库用来唯一标识消费者

　　〈客户登录标识符〉消费者登录使用的账号

　　两个域都是唯一的。企业采用IFX标准就必须决定使用每个域的时间和地点。有时，消费者甚至决定忽略这两个标识符，自己重新创建一个客户域，这个客户域对企业记录系统更适合！

　　如何使企业选择一个单独的标准成为可能？

　　元数据管理方法

　　企业内元数据库支持关键商业体的可靠描述。这些描述是分布在多个企业系统上信息的扩展集。数据字典也就是逻辑与物理数据模型是元数据库定义和维护的关键输入。

　　元数据管理组在前面讨论过的中心管理模型中应该是一个焦点集中的组。元数据管理必须在企业层次执行。换句话说，即使一个企业选择了分布式管理模型来维护服务，它也必须选择一个中心管理模型来支持元数据。
　
　　在上面的例子中，消费者的元数据包括一个简单形式的标识符，这个标识符是唯一的。另外，元数据要确保维持管理信息的描述，这些描述包括登录帐号和密码。因此，即使一个企业已经通过一个客户域为消费者选择了唯一标识符，这个客户域也必须在元数据库中被描述。

　　结论

　　像一声春雷，SOA已经被IT界迅速接受，它帮助企业用模块化的方法搭建并部署服务。然而，架构的实际应用需要仔细的规划。感兴趣的企业必须首先确定他们适合长期应用和支持SOA。

　　通过开发并制定一个实现路线图，企业可以预先应对好一系列将遇到的挑战。每个企业都将面对一个独特的挑战集；相应的应对这些挑战的方法也就各自不同。这些挑战的影响—在执行中与执行后—还依赖于这些特定企业的环境。

　　关于作者

　　Easwaran G. Nadhan是EDS，Plano，Texas顾问中的关键人物。他有在软件产业设计并实现分布式解决方案的20年的经验。最近，他借助自己的经验帮助企业完成企业应用集成，同时实现了SOA。这篇文章中的例子以EDS提供服务的实践经验为基础。可以写信与Nadhan联系easwaran.nadhan@eds.com