介绍

　　你可能考虑过在你的企业中实施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显示了一个跨商业部门的应用和平台分类例子。这个例子将用来说明在这部分中讨论的每种方法的重要特征。

　　功能范围

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

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

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

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

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

　　基于技术范围

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

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