一种基于 SOA 的应用程序的动态实现框架

当今 IT 环境的特点是：异构而复杂的应用程序、进度紧张、受预算约束，以及一个不断变化的业务需求前景。几乎没有企业能够以一种高效率的方式，灵活而有效地增强其现有的基础架构，来迎接和克服这些挑战。即便如此，为了快速而经济高效的处理源源不断的高度复杂而动态的业务需求，企业需要一种灵活而动态的方法来自动化、构建和管理关键业务流程。

　　解决方案

　　面向服务架构（SOA）常常被奉为解决上述业务挑战的一种可行的解决方案。SOA 是一种通过使用和组装构建模块来概念化、设计和构建应用程序的方法，每个构建模块通常被表示为一个可重用的服务。目前使用的许多 SOA 方法只是简单地封装一些业务功能，然后是用在应用程序中，而且采用了一种临时、静态和不灵活的方法。开发未来应用程序和业务流程的推荐方法是采用正式的 SOA 实现框架，该框架是动态的、灵活的和可伸缩的，足以满足变化的和复杂的业务需求。不管您是否为 SOA 实现购买或构建了一个框架，该框架的功能必须要保证有利于您的解决方案。

　　SOA 实现框架概览

　　SOA 实现框架是一种允许利用 SOA 原理高效构建应用程序和业务流程的技术。它为架构师、开发人员和管理员提供了一个操作框架和工具，允许他们配置、使用和管理企业服务，这些企业服务构成了应用程序和业务流程的构建模块。这个框架在实现流程的各个级别和阶段中使用了一种以服务为中心的方法，并具有以下普遍特征：

　　※　利用高度安全的、独立于协议的方法来动态连接客户机和服务的能力。
　　※　可靠的处理服务执行的同步和异步模式的能力。
　　※　以声明方式定义和处理事件的能力。
　　※　在客户机和服务之间动态转换数据格式的能力。
　　※　以集中方式管理分布式 SOA 资源（服务、配置、策略等）的能力。
　　※　在服务执行过程中捕获和处理异常的能力。
　　※　记录和监控在客户服务交易期间出现的不同事件并进行度量的能力。
　　※　提供统一的可重用服务调用代码库，用于企业中所有应用程序。
　　※　支持 Web 服务标准堆栈，以促进大规模的采纳和互操作性。

　　框架组件

　　服务注册

　　服务注册是企业启用 SOA 解决方案的一个基础部分。它用于定义、配置和实施业务服务，这些服务以集中方式使用在应用程序中。因为缺乏一个精心设计和管理的服务注册，许多公司无法实现 SOA 全部的潜力。这包括用于定义和配置服务到服务、提供者、消费者、服务交互、策略和所有相关配置所需的重要信息。服务注册驻留在一个高性能数据存储中，并可使用服务管理器来查看和管理，这将会在稍后予以说明。

　　服务总线

　　服务总线是一个在客户机应用程序与服务之间进行协调的高性能组件，它通过代表客户机以及旨在提高统一而又可重用的技术性功能的服务来提供功能的公共部件，从而提高了其价值，这就是 SOA 真正实现的关键所在。它通过提供一种标准机制来连接服务并封装服务实现细节，使客户机可以集中关注业务逻辑。

　　服务总线使用了一种流水线的方法，即把总线看作一系列的部件 — 一条流水线。流水线的每个阶段本质上都是一个增值的部件，从前一个阶段接收一系列的输入，然后处理数据，并把输出传输到下一个阶段。

　　服务总线的特点如下：

　　※　动态连接性和路由：动态连接性是指不需要为每一个服务使用一个分离的静态 API 或者代理就可以动态连接到网络服务。现在的大多数企业应用程序都是运行在一种静态连接方式上，并且每个服务都需要一些静态代码片段。动态服务连接性是企业灵活性的关键。动态连接性 API 也是如此，如果不考虑服务实现协议（Web 服务、JMS、EJB/RMI、POJO 等等）。客户端应用程序可以通过 URI 接口访问服务，该接口要么直接映射到服务上，要么根据服务请求的环境或者内容被路由到服务上。
 
　　※　可靠的消息传输：可靠的消息传输是指把服务需求消息进行排序并确保这些消息被传输到目的地的能力。如果需要，它还包括将响应消息回馈给请求方的响应能力。这种能力主要用于处理事件，这对以异步方式响应客户和成功的 SOA 实现至关重要。它主要是通过使用可靠的 JMS 排序与存储、发送和确保交付的能力实现的。

　　※　安全：一般来说，处理和加强安全是 SOA 实现的一个关键成功因素。主要考虑以下问题：
　　　　- 联合验证：这个特性截取服务请求并添加适当的用户名和凭证。它还可以在发送服务执行请求之前验证服务请求。
　　　　- 授权：验证每一个服务请求并发放授权，来确保发送方具有访问服务的正确权限。
　　　　- 加密/解密：在元素层加密请求和响应信息的 XML 内容，并且解密相反的脚本。

　　※　转换：在客户端和服务使用不同的数据格式时需要进行转换，即根据规定的转换规则把数据的既有格式转换成目标格式的能力。

　　※　高速缓存和性能策略：对提高服务的性能和质量，以及最终增强提高整体顾客服务来说非常重要。它可以在不同的层次上执行，包括服务配置，服务响应数据的服务和其他 SOA 资源，取决于如何通过优化来获得高性能。整体性能还可以通过压缩在节点间传输的基于 XML 的消息来获得提高，这样可以降低带宽利用率。为了达到这个目标，压缩和解压缩代理被安装在 SOA 栅格的边缘。

　　※　日志：在出于审计、问题诊断和监控等目的而需要跟踪系统执行和性能。可以为任何服务记录日志，还可以在各种不同的层中记录日志。

　　※　监控：是指跟踪通过总线发生的服务活动，并提供可见的度量标准和统计数据的能力。监控的特殊意义是指能够发现业务流程中出现的问题和异常情况，并且快速采取行动来解决问题。

　　※　服务水平协议（SLA）：SLA 定义了与 Web 服务操作和业务流程相关的性能担保——诸如响应时间和服务可用性等——性能担保对业务关键的操作来说很重要。服务提供商可以使用 SLA 来推广和创建服务水平协议。这可以帮助他们提供适当数量的资源和优先提供维护服务。

　　※　版本控制：是指版本化 Web 服务和前摄性地帮助客户开展客户端应用程序迁移工作，Web 服务的最新版本一经推出，就立即帮助客户把客户端应用程序迁移到最新版本中。版本控制支持包括能够注册同一服务的不同版本，根据需要向客户端提供所有版本的 API 和库，以及帮助把客户端迁移到新版本中。版本控制组件使用基于 XLST 的转换规则把对旧版本服务的请求转换成对新版本的请求。

　　※　异常管理：是指在客户访问业务服务时跟踪和处理出现的异常的能力。异常细节包括捕获和日志记录的异常代码、名称、原因和描述。可以通过按照预先定义的次数尝试重复连接，路由到一个替代服务中，或者简单地返回执行失败的原因来处理异常。
 
　　※　定制业务逻辑处理：为在服务处理过程中插入定制的业务逻辑提供灵活性。举例来说，一个具体的业务逻辑要么先于提交服务执行请求之前在服务请求上执行，要么先于发送服务响应到客户端之前在服务请求上执行。

　　服务总线本身是作为一种服务实现的，使用了 Web 服务或者 EJB 技术。这种服务被部署到服务器池或者群集中，并可以横向扩展。上述组件必须符合相应的 Web 服务标准。

服务管理器：

　　服务管理器是一种基于 UI 的管理工具，它可以授权管理员和业务经理来定义、配置、管理和监控业务服务以及应用程序中使用的相关资源。它可以被看作是 SOA 实现的控制中心，主要用于供应和监控服务。服务管理器的两个关键功能如下：

　　※　服务配置管理：使用这个功能，管理员可以随时随地配置服务注册中存放的服务。用户可以定义服务、位置、绑定信息和服务配置设定（如安全性、高速缓存、转换、日志和监控）。他们还可以定义服务提供商和消费者以及相关的服务契约。

　　※　服务活动监控：为业务经理和管理员提供一个查看通过总线发生的服务活动相关的主要性能数据和统计指示板。用户可以查看和监控服务使用、响应时间、服务异常、行为日志、信息等等。服务管理器就像一种基于 Web 的应用程序，可以在没有任何客户端安装需求的情况下访问。

　　客户端 SDK

　　客户端 SDK 是一种连接服务总线时所需的软件。SDK 被以 API 的形式包装和提供，可以从服务管理器中下载这个软件。它是一种易于使用的库，开发人员可以用来在应用程序和业务流程中发现、访问和利用业务服务。这样可以显著的提高了开发人员的生产力，因为它把开发人员从信息调查工作中解放出来，而由服务总线来执行。客户端 API 不使用服务位置依赖的、硬连线的代理和调用存根来访问服务。相反，它使用一种动态机制来通过总线连接到服务。

　　SOA 实现框架使用

　　SOA 实现框架可以用来开发强大的应用程序和业务流程。图2展示了一个使用场景，使用 SOA实现框架来构造客户自我服务的应用程序，其中包括订单管理和客户支持功能。应用程序使用客户端 SDK 通过总线来连接订单和支持流程中的核心业务，诸如提交购买订单、第三方信用验证、订单状态、支持案例条目和支持案例状态等。这些功能要么作为 Web 服务，要么作为其他 Java API 发布，通过在现有应用程序中包装业务逻辑 —— SAP 订单管理和定制的客户支持应用程序。进一步说，信用服务是一种驻留在合作伙伴站点中的 Web 服务。

　　这个例子阐述了客户端应用程序轻松地以一种统一的、独立于服务逻辑的方式连接异构服务的能力。

　　SOA 实现的最佳实践

　　除了使用强大而灵活的 SOA 实现框架之外，任何成功的 SOA 实现都需要一系列在开发周期不同阶段中的指导和最佳实践。一组核心的指导如下：

　　※　使用新服务的流程必须是受配置和发现流程驱动的，这与实现一种冗长的手工流程周期相对。这样可以确保整个系统能够以最少的投入来满足未来需求。

　　※　一次 SOA 实现就像用来设计业务服务的方法一样成功，每一服务必须被抽象为一种粗粒度的业务功能，并按照可以在企业之间耦合和重用的方式进行设计。

　　※　在可以缩短响应时间和提高整体用户体验的地方，服务必须设计成异步的。
 
　　※　客户端应用程序必须使用统一的服务访问机制，以一种独立于协议的方式，而且不必考虑服务是本地还是远程。此外，客户必须关注业务逻辑，而业务连接性逻辑必须从客户端 SDK 中抽象出来。这样确保了集中式管道逻辑、更高的应用程序开放人员生产力以及易于维护。

　　※　SOA 实现框架中的普通组件必须以一种标准方式发布，来促进代码的统一和重用。

　　※　在可能的地方使用配置，而不是基于定制和代码的业务逻辑。这样可以提高以最少的投入和最短的时间来满足未来业务需求的能力。

　　※　重用和包装现有业务应用程序逻辑和更加粗粒度的业务水平服务。避免重写原有实现逻辑。