第 1 部分：构建服务组合

作者：Dan Hynes 和 Salil Pradhan

尽管面向服务的体系结构或 SOA 仍然是新生事物，但许多公司正逐步认识到需要采用 SOA 方法作为执行满足业务需求的解决方案的方法。采用这种方法的一个关键步骤是构建可重用服务的组合。

SOA 表示新应用程序的设计、开发和集成方式的根本性转变。它还将企业应用程序的开发简化为模块化业务服务，可以轻松地对其进行集成和重用。

SOA 的一个主要优点是缩小了业务和 IT 之间的差距。作为需求收集活动的一部分，将业务和技术需求与机构的与项目有关的主要业务目标相对应，将对确保项目与业务需求同步大有帮助。

着手构建服务组合的动力主要源于意识到需要保持业务需求与 IT 项目之间的一致性。一般来说，该过程始于初步确定所需的服务，进而发展到发现它们所依赖的服务与资源（如定义特定业务规则的政策等）并对其进行分类。理想状况下，这样做的成果是一套面向服务的业务应用程序，应用程序可以修正和重用，以满足企业不断变化的业务需求。

尽管在执行 SOA 时有许多问题需要考虑（如业务流程的编排、用户界面的开发以及支持安全和性能的基础架构等），但是获得服务组合在逻辑上显然是第一步。在“精通 SOA”系列的此部分中，您可以大致了解用于构建服务组合的框架。

SOA 管理驱动组合构建

对 SOA 组合的创建起积极推动作用的通常是那些最为关心 SOA 管理相关问题的人。理想状况下，这个“管理委员会”应当是相关组的交叉项，包括业务流程所有者、系统架构师和开发人员。

SOA 管理是一个宽泛的题目，值得专门撰文加以论述。不过，在这里我们不妨将其概括为“将 SOA 的灵活性与传统 IT 体系结构的控制及可预言性相结合的框架”。

SOA 管理在本文中一般涉及下列方面：

• 服务与相关资源的生命周期管理
• 相关性管理
• 策略的应用与管理
• 安全性和运行时策略执行
• 服务可用性
• 服务供应

执行能够管理不断增长的服务组合的管理平台的重要意义远远不止于对技术基础架构和运行时间环境所需进行的改进。

对任何管理计划来说，主要目标都是通过定义将管理建立在其核心内的 SOA 策略来最大限度地降低风险。不受管理的 SOA 可能会导致如下后果：

• 由于发布的服务不完全符合服务级要求而导致过程的中断
• 由于服务问题和故障而使帮助台和现场服务呼叫猛增，导致支持费用的增加
• 缺乏互操作性，从而形成业务服务的孤岛并时刻面临传统的、紧密耦合的体系结构所带来的挑战
• 由于无法使主要策略与服务相关联而导致无法满足合归性要求
• 由于允许随意访问数据和服务而形成安全漏洞

随着服务产品的增加，未受管理的 SOA 中存在的这些问题所形成的风险会成指数倍地增加。不过，通过对服务组合的正确执行和管理，其中许多风险能够得以减少。

服务发现

逻辑上，构建服务组合的第一步是确定需要哪些服务。用于鉴别和发现候选服务的可行技术有三种，即自顶向下分析、自下向上分析以及业务流程跟踪。注意，应当考虑使这些技术互为补充，不要唯一排外，每一种技术都应当在您的服务发现过程中发挥作用。

第一步，您应当启动自顶向下的分析，重点将机构的业务分解为若干功能“域”。在这里，域是指密切相关的功能和数据（如客户、产品和合同）的逻辑分组。

自顶向下的分析一般会形成一个符合业务需要的、实际的候选服务集。不过，单凭该过程并不能发现机构内的所有候选服务。接下来要做的是对 IT 基础架构、应用程序的功能性、业务应用程序以前曾使用过的数据以及现有的服务进行彻底的检查。这种自下而上的方法通常会产生大量的高级和低级候选服务。

作为补充手段，您应当对每个业务事件的生命周期进行跟踪，以便发现哪些服务是通过其生命周期处理该事件所需要的。该过程称为业务流程跟踪，它不但可以发现处理该事件所需的服务，还可以发现仅通过自顶向下或自下而上的方法操作时所遗漏的候选服务。

除了识别交付项目所需的服务之外，该业务流程驱动的方法还能够提供完整性检查，并就特定服务的重用潜力给出首要指示。

服务发现的最终结果将是一个概念上的服务组合，该组合包含了项目最需要的候选服务。

服务分类

发现一组候选服务之后，对它们进行分类是对其进行设计、开发和后续执行的至关重要的一环。

分类可以按照功能、用途、结构和调用等标准进行。例如，将服务分为基础架构服务（DNS 查找、电子邮件）或工具服务（转换）是基于功能进行的分类。

这种分类方法有助于识别属于同一功能域的服务、允许定义标准和最佳方法并对不同服务类的要求进行管理和监控。对服务进行分类的过程还将会发现业务服务的规则，可以将这些规则转换成一组应用于不同类型服务的、标准的、可重用的策略。

虽然服务进行分类还没有业界统一的标准，但通用描述、发现和集成 (UDDI) 注册表正在成为事实上的标准。UDDI 不但允许将元数据设置在服务上，还允许将其设置在诸如策略和 XML 模式等相关产物之上。

例如，您可以在 UDDI 注册表中创建下列分类模型以简化服务的发现、管理和控制：

• 服务所有者和联系人信息
• 服务或产物的功能描述
• 版本信息/状态，例如“版本”或“状态：测试 | 生产 | 维护”
• 服务类型（“订单输入”）或业务范围（“会计”）
• 使用模式/建议，例如“事物处理 | 子事物处理”、“同步 | 异步”
• 预期的错误信息，用于现有服务的重用
• 服务相关性，可能包括相关的策略、XSL 转换和 XML 模式
• 可用的服务端点，以及 Web 服务中抽象的和具体的 WSDL 位置

给 UDDI 注册表中的服务和产物分类，不但可以使您能够更好地为潜在的候选项分类，而且还能发现可以重用的现有服务，从而避免了功能的不必要重复。

确定服务粒度

争取合适的粒度级别将实现使用、重用和可管理性方面的最佳化。顶级的、业务驱动的分析通常会发现与现有需求相对应的高级（粗粒度）服务。例如，一个粗粒度服务可能表示“流程采购订单”，它清晰地映射到一个业务流程。

由于自下而上的分析专注于 IT 基础架构和现有的 API，因此该方法通常会产生大量的粗粒度服务和低级（细粒度）服务。激活低级任务（例如“插入订单行项”）的功能就是一个示例。

理想状况下，您的 SOA 组合应当首先包括粗粒度服务界面，该界面直接与业务语义相对应。高级服务在动态的业务环境中灵活得多，因为它们没有紧密地耦合到下层基础架构之中。粗界面还允许您利用来自异类环境的其他服务来构建应用程序和流程，而不必考虑细节和差别。

相反，低级服务是和下层基础架构或 API 紧密耦合的，不能轻易加以修改以适应不断变化的业务需求。实际上，将一个服务包装在一个现有业务对象周围（例如企业 JavaBean (EJB)）将不可避免地产生细粒度界面，把每个可供呼叫的方法显示在 bean 上。

用于处理机构内部非常特殊的案例的服务可以通过细粒度界面执行，这将为使用这些服务的客户端应用提供更多的灵活性。不过请记住，在灵活性增强的同时还须面对复杂性增加所带来的成本问题。

一般来说，您应当避免将低级界面公开出来作为服务组合的一部分以试图满足业务需求。可考虑改为将一组细粒度服务结合起来组合成粗粒度服务。

最后，需要记住的一点是，一个服务是否适当并不在于其是粗粒度还是细粒度，而要看其是否能使业务价值最大化。

服务获取

定义完服务组合之后，下一步是确定如何获取实际的服务：内部构建、获取服务或预订外部供应商提供的服务。

按照一般规则，那些关键性业务服务（即有益于业务流程、能为机构争取竞争优势地位的服务）最好是由内部提供。

您很可能在服务的发现阶段就已经在内部把可以映射到候选项的服务识别出来了。例如，倘若贵机构拥有 ERP 或 CRM 系统，则主要界面（客户、订单、帐户）都是可以加入到您的组合中去的服务。已经在企业内部使用的自定义应用程序可能也值得加以分析，以便识别可用的界面。

提供更多商品驱动的功能的服务（例如提供股票报价）可能是外部预订的候选项，很可能来自于贵机构已经与之建立关系的业务伙伴。一旦您开始搜寻符合您需要的服务，服务分类的需要便立即显现出来了。

显然，在识别候选服务时，有许多支持产物也需要创建和管理，例如，用于控制服务的策略；服务所使用的消息类型；以及将输入和输出消息转换成适当格式所使用的 XSL 转换。

创建一个这些产物及其相应服务之间的关系的目录将大大有助于构建您的组合。UDDI 注册表对本任务来说是一个价值极高的工具，它使您能够构建一个服务和相关产物的完整的在线目录。

SOA 管理需要考虑的事项

最好您的 SOA 基础架构能提供一个针对如下管理性能的平台：监控与诊断、外化的安全性、集中式审计与事件记录以及服务级协议与策略管理。有许多特定于 SOA 的组件可以用来进一步提高管理能力，例如企业服务总线 (ESB) 可用来实现可靠的消息传递；业务规则引擎可用来捕获和自动化业务策略；业务活动监控解决方案可用来优化服务。

采用中间 Web 服务管理服务器尤其受益。在这种配置中，服务通过一个向用户开放的代理 URL 被“虚拟化”，因此请求是通过媒介而不是直接发送到服务端点的。利用本集中管理平台可在服务上统一地设置策略，并为运行时策略的执行提供了一个单独的点。它还简化了服务度量和使用情况统计信息（对维护服务组合的运行状况至关重要的数据）的捕获。

服务虚拟化还具有提供位置透明度的优点：通过公开代理，可以在不影响服务用户的情况下对下部基础架构进行改动。该媒介必须维护其自身的虚拟服务到服务端点映射，或者利用 UDDI 注册表发现一个有效的服务端点。

结论

SOA 作为沟通 IT 世界和业务世界的桥梁这一论断在不断地发展着。服务组合的构建是一项时间和资源的投资，它必将在面向服务的业务应用程序方面带来巨大的回报。对这些面向服务的应用程序可以加以修改以满足企业不断变化的业务需求。

第 2 部分：通过企业服务总线连接

作者：Brian Wilkinson 和 Demed L'Her

随着实施面向服务结构体系 (SOA) 这一观念的日渐普及，企业发现自己的服务组合规模日益增大。如果不遵循正确的体系结构模式，则很难有效地利用和重用这些服务。

企业服务总线 (ESB) 是一种相对较新的软件类别，我们可以使用它来满足上述目的。它提供了一个急需的中间层，从而简化了企业 SOA 实施的数据传递、服务访问、服务重用以及服务管理。ESB 还支持智能指导的通信，调解松散耦合业务组件和取消耦合的业务组件之间的关系。

在“精通 SOA”的这一部分中，您将了解 ESB 为什么是企业级 SOA 必不可少的一部分，以及如何实施 ESB（包括常见问题）。

是否需要 ESB？

正如本系列第 1 部分中所说明的那样，SOA 是应用程序在设计、开发和集成方面的一次根本性转变。SOA 还有助于将企业应用程序作为可轻松集成和重用的模块化业务服务来进行开发。然而，SOA 还意味着各种挑战，其中许多挑战可直接通过 ESB 解决：

• 可靠的消息传递：可靠的数据传输仍然是所有集成解决方案的基本需要。虽然 SOA 的原则需要基于标准的、与平台无关的消息协议，但该原则本身并未考虑可靠的数据传递。各项标准（如 WS-RM）正在逐渐支持该功能，但它们还不够成熟或者未被广泛采用。
• 服务虚拟化：SOA 代表了一种基本的体系结构模式，在该模式中，任何服务使用方均可从任何平台访问一个服务提供方。这又意味着适当的协议和语法调解在适当的位置隔离了使用方和提供方。
• 动态发现和调用服务：为了优化服务的重用，服务使用方需要一个中介功能来了解服务请求的特性，从而方便与提供方进行连接。在理想的 SOA 中，这种关系将在运行时作为中介。
• 策略管理：已知和未知服务使用方进行访问都需要一个抽象的策略管理模型，该模型除了强制执行与服务提供方实施无关的更复杂的业务级别策略外，还能够强制执行身份验证、授权和加密。
• 管理和监视服务：逐渐增加的服务数量导致环境越来越复杂。必须监视该环境以了解其可用性、性能以及任何技术或业务级别错误。
• 系统异构性：人们通过常用的应用程序以及用来连接它们的软件可以发现，今天的新应用程序就是明天的旧应用程序。这种新技术的普及是必然的，因此，设计系统时必须考虑让其支持这种变化。
• 从技术实施细节中抽取业务逻辑：SOA 的目标之一是提供一种分层的方法来开发系统，该方法将技术变化从业务流程的变化中隔离出来，并且将业务流程的变化从技术变化中隔离出来。实际上，必须从一开始就将这种“分别考虑”设计到体系结构中。

解决这些问题的标准方法 — 无论是企业范围还是部门范围 — 是任何 SOA 项目成功的基础。不能保证数据传递的 SOA 解决方案对大多数业务事务而言不够强健，不能将业务流程从转换和路由逻辑中抽取出来的 SOA 解决方案不会很敏捷。而且，一个无法适应标准和产品发展变化的体系结构并不会降低 TCO。ESB 模式（以及相关 ESB 产品的引入）是全面的 SOA 解决方案成功的基础。

ESB 部署的先决条件

深入讨论细节之前，我们先进行一下回顾，就会发现并非所有 SOA 实施都需要重大的重用和松散耦合。例如，较小的实施可能只会从 ESB 的增加中获得边际效益。

您需要满足一些战术条件才能建立对 ESB 的需要。按照重要性顺序，这些条件依次为：

1. 服务使用方和提供方可能是松散耦合的，或者需要同步、非确定性的路由（其中使用方需要响应，但不会显式知道服务提供方）。
2. 执行业务事务之前，需要根据数据、使用方或提供方执行专门的功能（可能包括策略验证、转换等）。
3. 必须有一种将端点应用程序连接到总线的方法（通过重新设计或者通过适配器），该方法必须能够在面向服务的模型中运行这些应用程序（并非所有应用程序都能够轻松地支持服务。例如，传统的老式程序（如客户数据应用程序）使用连接到老式屏幕的、基于批处理的编程模型来运行。它们可能不会很容易地适应更基于事务的 SOA 模式。）

对于所有复杂的计算体系结构，这三个条件仅仅是指导方针。肯定存在这样的情况：无需同时满足以上三个条件即可轻松地判别 ESB。着手进行 SOA 规划时，不但要关心战术方面，还要考虑长期策略目标。

自上而下与自下而上

SOA 的两种主要方法通常被称作“自上而下”和“自下而上”。在自上而下的方法中，采用 SOA 是由业务方驱动的，结果是一个专门设计以满足业务需求的体系结构，着重于效率。企业的 IT 部门通常推崇更实用的自下而上的方法，因为该方法更关心服务虚拟化，其主要目标是将成本降至最低并将更多灵活性结合到核心 IT 资产中。

可以想象，人们就哪种方法最适合或最有效展开了激烈的争论。在此，我们不会偏袒任何一方，而是探讨 ESB 是否与这两种方法相关。

答案是肯定的，自上而下和自下而上这两种 SOA 方法通常都需要 ESB。这两种方法所使用的工具没有太大的区别；只不过引入这些工具的时间不同。在自下而上方法中，可能在最初阶段就开始使用 ESB 来执行低级数据和系统集成。在自上而下方法中，最初关注的可能是构建服务，不过稍后这些服务之间需要进行互连时，就该使用 ESB 了。

常见用例

详尽列出所有可能的用例将需要更长的篇幅。然而，其中一些较为常见的用例需要进行强调：

服务虚拟化。服务虚拟化是实施 ESB 的主要驱动因素，其他大多数用例都是它的变形。

设计时缺少清晰的层次（或“分别考虑”）会在业务逻辑和 IT 细节之间引入不必要的耦合。起初，这些交叉相关性的影响可能不太明显，但随着集成范围的扩大，它们开始以指数级速度削弱 SOA 实施最初的优点。到端点的直接链接越多，最开始灵活、松散耦合的体系结构的僵化惯性就越大。

例如，如果将端点详细信息嵌入在一个数据库中，那么将该数据库从一个网络重新定位到另一个网络将需要一个新版本的贷款审批流程。处理几个这样的链接可能还是可管理的，但如果增加到 50 个服务和数十个端点，您就会看到体系结构很快会变成一张纠缠不清的相关性网。

该示例还暴露了这种设计在 IT 事件（数据库移动）和业务逻辑（贷款审批流程）之间引入的不正常关系。当复杂的核心商业资产（如贷款审批流程）根本没有变化时，日常 IT 事件难以接受触发这些资产的整个版本控制。

当然，这个小示例可能已经通过仔细的配置以及使用诸如 JNDI 或 DNS 这样的技术缩减至最少，但它仍然可以方便地阐释服务虚拟化所能解决的问题。更现实的用例包括添加或删除数据库、更改 CRM 供应商，甚至吸收作为合并或并购的结果而产生的新系统。

如图 1 所示，服务虚拟化是保存面向服务体系结构的增长能力的关键。通过使用 ESB，您可以从业务逻辑中彻底消除所有端点详细信息（如 IP 地址、端口以及其他低级特定于计算机的详细信息），而是公开一个稳定的接口。最终结果是将业务需求与 IT 需求完全分离，从而允许 IT 和业务独立修改各自的资产。

图 1 服务虚拟化

集中控制策略。您只需监视几个应用程序服务器日志和配置文件的日子已经一去不返。幸运的是，ESB 可以帮助您解决如今的分布式系统中固有问题的管理和监视，即，提供有关多个应用程序和协议的端到端视图，在企业范围内配置并强制执行全局策略。

由于 ESB 逻辑上作为所有集成通信的中介，因此对 SOA 基础结构的监视变得简单。ESB 管理控制台提供了流经服务的所有交换和消息的统一视图。（请参见图 2。）这些新的监视功能可用于进行被动和主动监视。例如，构建和强制执行端到端的服务级别协议 (SLA) 变成可能。实际的监视平台可能是一个外部应用程序（如 OpenView 或 Tivoli，也可能是较新的业务活动监视 (BAM) 工具，现在越来越多地用于实时基础结构监视），但 ESB 提供了所需的统一的、基于标准（SNMP、JMX、SQL）的基础结构视图。

图 2 集中控制策略

使用 ESB 可以更轻松地全局运行像安全性或可靠性这样的策略。通过将标准化的钩子（例如，WSDL 接口）公开到集成体系结构的每个步骤中，ESB 使得插入常用的安全、审计和消息处理工具成为可能。例如，您可以拦截某些站点之间的所有通信来执行安全声明标记语言 (SAML) 断言，或者在企业级别（而非每个单独的端点）支持 64 位 DES 加密。此外，ESB 还允许对专门应用程序的特定任务（如安全策略）的责任和委托进行清晰的分层。

原有数据源支持 Web 服务。最初，没有将 ESB 作为原有集成的解决方案。但是现在，普遍认为必须在 SOA 中考虑原有数据源，事实上，这些数据源通常组成所涉及的大多数服务。

一般来说，访问原有应用程序（如 ERP 或 CRM 系统）中的服务意味着使用供应商协议和 API 与目标系统直接交谈。（请参见图 3。）这意味着构建服务使用方的团队必须了解目标系统，并且能够编译其客户端的供应商 API（更不用说购买这些 API 的许可证了）。因此，部署新服务使用方的成本非常高。

图 3 访问服务（专有方式）

然而，大多数 ESB 供应商都提供可以连接到受欢迎的原有系统的适配器。然后，只需进行配置即可访问应用程序的服务，添加新服务使用方的成本显著降低，不用再使用供应商协议，所需的只是标准（SOAP、JMS 或 ESB 公开的任何其他入口点）。（请参见图 4。）

图 4 访问服务（基于标准的方法）

进行服务虚拟化之后，即可以在许多情况下利用 ESB 了。例如，多通道支持。（请参见图 5。）只需进行简单的配置，即可向过去只能通过单独的 API 访问的服务中添加新通道。因为使用同一个体系结构来支持多个通道，因此，确保所有访问（不论是哪个通道）都归属一个全局策略中是可能的。

图 5 多通道支持

例如，通过一个 ESB，只能通过 SOAP 从客户门户访问的 Web 服务可以允许其他面向客户的系统（如可以与 JMS 或 DCOM 交谈的 IVR 或传真网关）访问相同的服务。

实施 ESB 的科学

虽然许多人会认为开发以业务为中心的 SOA 是一门“艺术”，但 ESB 的实施更大程度上是一门科学。遵循正确的方法、标准和体系结构原则将确保成功实施 ESB。

ESB 的实施通常在两个工作流中进行；软件体系结构和支持基础结构（即“技术体系结构工作流”）；以及支持业务所必须的服务逻辑（以及支持配置）的设计、开发和部署（即“应用程序体系结构工作流”）。让我们看一下这两个工作流。

技术体系结构工作流。该工作流包括选择软件、识别常见体系结构功能和基础结构要求，以及部署可以开发服务（最终是组合应用程序）的整个基础体系结构。与传统项目相同，有必要对技术体系结构工作流的组成部分进行需求分析。针对该分析，有必要广泛地调查期望 SOA 所具备的功能，并将它们分解到分散的服务中。需求列表示例（不详尽的）包括：

• 错误处理
• 审计
• 策略管理（不同的详细信息级别）
• 服务发现
• 有保证的传递
• 协议支持（特定于所涉及的应用程序和需求）
• 标准支持（通常是 WS* 标准，可能包括其他标准，这取决于规划）
• 智能路由

只有明确了这些需求并选择了产品之后，才能开始开发。如果重用是所有 SOA 实施的主要着眼点，那么开发人员培训可以更广泛。

应用程序体系结构工作流。应用程序体系结构工作流包括识别、设计、创建业务级别服务以及将其部署到总线上。通过上述的自上而下或者自下而上的方法可以处理这个特殊的工作流；然而，随方法的不同，管理实际设计和开发过程的基本原则只会略有不同。

针对 ESB 进行设计时，第一个也是最重要的决策是识别出在哪些条件下服务应该位于总线上，在哪些条件下服务应该位于（例如）业务流程管理 (BPM) 工具中。虽然这两种功能表面上看来有很大差异，但是用 BPM 工具设计类似于总线的功能是很有可能的（在某些情况下，甚至更可取)。通常，以下准则适合这种情况：

• ESB 上的服务应该是短生命、不连续的事务。
• 需要复杂规则来确定路由、访问以及其他基于数据的决策的服务应该位于 ESB 上。
• 具有特定于端点的逻辑的服务应该位于 ESB 上。例如，如果无法在应用程序自身内将规范的数据对象映射到特定于应用程序的对象上，就应该在总线中进行该操作（因为您在该应用程序中无法进行控制，也可能是因为您没有留下任何 COBOL 程序员来进行修改）。
• ESB 服务应该不包含任何人力工作流活动。

除了这些高级准则以外，您还应该在全局范围内实施一些较低级别的设计和开发准则。其中某些准则不是 ESB 所特有的，但由于 ESB 会变得更相关。我们已经在下面用斜体标明了新准则。

• 建立成功度量。乍一看，这似乎是显而易见的，但经常有很多 ESB（以及 SOA）项目失败，都是因为它们无法量化地演示其所支持的过程或服务中的成功。有用的度量可能包括服务的使用方数量以及服务的响应时间（平均时间和高峰时间）。
• 对于每个应用程序，必须识别适当的适配器以及必须应用的相应协议和封套技术。这包括识别交互中所需的所有标准（例如，Web 服务可靠的消息传递）。确保在选择适配器和协议时考虑事务模型（异步或同步的）以及可靠性需求。
• 必须详细定义所涉及的源数据对象和目标数据对象，并将它们映射到对应的规范对象。如果某个规范对象不存在，您必须识别、设计并开发一个。规范对象的存在对于广泛采用 ESB 范例很重要。
• 将度量设计到服务中。利用 BAM 工具可以轻松地访问实时度量。实时度量的示例可能包括给定值上的订单数、某种类型的客户更新数，或者一段时间内一个人（客户或其他）的请求数。
• 识别所有级别的安全限制。这些级别包括应用程序、事务、数据对象内容以及潜在的数据域内容。还必须将安全策略定义为支持这些要求。
• 在可能的情况下利用现有服务。所有企业级的 SOA 都应该有一个可搜索的服务注册表。
• 识别审计要求以及技术和业务级错误处理要求，相应地设计服务。某些 ESB 工具具有重要的现成功能，对这个特殊步骤有所帮助。
• 设计时牢记所有可用的标准。企业体系结构组发布给定的 SOA 环境中将支持的标准并且支持所有开发人员轻松地访问该列表，这是一个不错的做法。
• 部署服务时，定义并发布 WSDL。将服务注册到企业服务注册表中。

遵循这些准则就可以成功实施 ESB，从而可以随着时间的流逝轻松地进行小改动。

其他注意事项

和其他所有技术一样，ESB 也有自己的特性和困难。以下是使用 ESB 时会遇到的一些问题。

• 开始使用 ESB 时就要分别考虑。您新获得的 ESB 是对您技术库的一个非常强大的补充。它还是一个工具，经常展示其 BPM 形式的许多特性（如逻辑结构或转换功能）。当想使用 ESB 进行一些轻型进程协调时，先回头想想您将 ESB 引入 SOA 的初衷：虚拟化您的 IT 基础结构，将业务需求与 IT 需求相分离。因此，遏制将某些逻辑泄露到 ESB 中的念头；让对 BPM 工具的编排和流程协调待在它们该待的地方。
• 转换到何处？使用大多数集成工具（消息处理、ESB、BPM）所提供的转换功能，将“什么”转换到“何处”的决定不再是一个问题，而是一个最佳实践。因此，在 ESB 和 BPM 工具中应该进行什么类型的转换呢？此处没有适合所有情况的答案。一个省事的经验是将方便的“分别考虑”原则扩展到转换，这意味着在 ESB 中执行系统级别的语法转换（例如，CSV 到 XML），在 BPM 中执行应用程序级别的语义转换（例如，CRM 客户到规范客户）。
• 影响分析。松散耦合的体系结构的问题之一是详细计划服务之间的关系以及评估变化或中断的影响。在大型 SOA 中获得直接和间接的相关性是一个恐怖的任务。通过支持更大的分离，ESB 可能会加剧这个问题。另一方面，由于 ESB 了解所有的服务及其相关性，因此它还是执行相关性分析的最好信息来源。这对集成供应商而言是一个新兴领域。
• 接受异构性的现实（即“总线舰队”）。虽然构想完美的 ESB 可能是一个逻辑的、单一供应商的总线，但是您必须接受当今世界的现实：企业将必须处理多条总线，这些总线可能来自多个供应商、跨部门、位置和时间（通过升级和移植）。记住这些之后，采用将使这种现实更易于处理的最佳实践和技术就非常重要了。标准的使用在以下这些地方很重要：HTTP、JMS 或 WS-RM 用于消息传递，XSLT 用于转换，WSDL 用于接口，等等。

结论

ESB 体系结构模式（以及相应的产品）是任何企业级 SOA 的重要组成部分。ESB 提供了一个重要的功能，可以断开特定于应用程序的逻辑与 BPM 功能的连接，同时还提供了一种支持松散耦合的、虚拟化的服务层的方法。通过精心的前期体系结构考虑以及目前正在严格强制执行的一组简单明了的设计准则，通过 ESB 编写服务成为一门非常产业化的科学。

第 3 部分：编制为端到端流程

作者：Joan Lawson 和 Dave Shaffer

该系列文章的前几部分描述了如何利用最新的标准和体系结构方法为后端应用程序提供服务，并在企业服务总线 (ESB) 上发布这些服务。但所有这些服务只能在访问它们的客户端和业务流程的上下文中使用。本文关注如何构建能够将服务编制为端到端业务流的灵活且标准的业务流程。

业务流程是实现业务功能所需的一系列步骤。业务流程可能包括企业内或企业间的系统交互和/或人工交互。出于一致性或合规性目的，一些企业只记录他们的业务流程。然而，在过去几年中，我们看到越来越多的组织使用 IT 系统自动执行和监控其业务流程。我们认为，越来越多的人采用业务流程管理 (BPM) 的主要原因之一是，出现了能够被广泛接受的标准（例如，WS-BPEL）来实现和执行业务流程。

图 1 用于定单处理的 BPEL 流程示例

在“精通 SOA”系列的这部分中，我们将描述如何使用这些标准，并结合 Oracle 供应商和 Monster Worldwide 的经验以及生产中若干个成功的 Oracle 企业服务总线和 Oracle BPEL 流程管理器的面向服务体系结构 (SOA) 实现，来面对业务流程编制的挑战。Monster Worldwide

Monster Worldwide 已经确定 BPEL 是一个重要标准，因为 SOA 和 BPEL 不仅能够提供成为全球标准所需的敏捷性和可扩展性，同时还能满足客户的本地业务需要。此外，BPEL 由若干个 IT 行业公司支持的标准化委员会推动，从而最小化了由选择专用集成平台而带来的供应商束缚风险。

随着 Monster Worldwide 应用程序的不断增多，需要使用 Web 服务和 SOA 将这些应用程序互联。它通过将接口以标准方式公开给现有系统来发布服务，从而利用 Web 服务标准，例如，SOAP、WSDL 和 XML Schema。然后，Monster Worldwide 可以将这些服务编制为端到端业务流。BPEL 是此类编制的行业标准。

在本文中，您将看到关于 Monster 如何实现 SOA 和 BPEL 的示例，以及来自其他 Oracle 客户的 SOA 实现的提示和技巧。您还将学习 BPEL 标准的特性，它如何适应 SOA 空间中的其他标准，以及 Oracle SOA 套件如何提供实现这些标准的基础架构。

BPEL 基础知识

BPEL 定义了一个基于 XML 的语言，用于指定基于 Web 服务的业务流程行为。第一个公开的 BPEL 规范在 2002 年 7 月发布（即 BPEL4WS 版本 1.0），它结合了 IBM 的 Web 服务流语言 (WSFL) 和 Microsoft 的 XLANG 规范。版本 1.1 于 2003 年发布，是由许多业界供应商协作完成的，而 WS-BPEL 标准的 2.0 版预计将由 OASIS 标准机构于 2007 年初发布。

BPEL 标准将企业业务流程的互操作性和可移植性提高到一个前所未有的程度。互操作性使运行在不同业务流程引擎上的业务流程能够彼此交互，以及与多个供应商和开源平台发布的服务交互。能够实现这一点是因为 BPEL 基于较低级的 Web 服务堆栈 — 即 SOAP、UDDI、WS-Addressing、WSDL、XML、XML Schema 等。业务流程方面的互操作性已经实现多年了；然而，BPEL 和 Web 服务标准可将其带入下一级别。继互操作性概念之后，业务流程的可移植性概念则是全新的。BPEL 提供的流程可移植性确保您可以使用支持该标准并可以运行在任何兼容系统上的工具定义业务流程。如今，您可以从较大的平台供应商（例如，Oracle 和 IBM）获得 BPEL 引擎，也可以从较小的特定供应商和开源公司获得。

编排和编制

实现业务流程的运行时生命周期需要执行多个活动。BPEL 是一种 Web 服务编制语言，不同于流程编排。流程编排（IT 界常用术语）可描述多个贸易伙伴为了实现多组织业务功能而进行的交互。例如，在供应链方面，实施产品采购可能涉及到多家公司的定单、发货通知单和资金的交互。编排不描述每个公司如何处理操作，只描述不同公司如何彼此交互。

流程编制使用一个中心流程来协调不同的 Web 服务操作。这个中心“指挥家”（就像在管弦乐团一样）了解编制的总体目标、涉及的操作以及操作的调用顺序。这种集中化管理使 Web 服务能够在不了解彼此影响的情况下进行添加和删除，还允许在出现错误和异常的情况下进行补偿。

流程编制和流程编排仅在描述服务接口和交互方面类似。对本文而言，我们将关注流程编制。当您使用 BPEL 进行编制时，BPEL 语言将提供一个标准来控制整体操作序列、调用服务以及在 BPEL 服务器上执行。

Monster Worldwide 最复杂的一项集成工作是开发一个从 Oracle 的 Siebel 客户关系管理 (Siebel CRM) 到 Oracle 电子商务套件的定单-发票集成。这些要求包括将初始定单消息（一个 Siebel 生成的对象，包括定单和客户数据）分为两个消息，转换这两个消息中的数据，以及在将消息发送到 Oracle 电子商务套件之前丰富定单数据。此外，需要在发送客户定单之前在 Oracle 电子商务套件中创建客户配置文件。我们将构建一系列 BPEL 流程来协调这些步骤的执行。收到 Siebel 定单对象之后，第一个服务将对象分为两个消息，即客户和定单。然后，编制将并行增强该定单和客户数据。转换定单数据之后，将其传递到演练整个定单数据增强功能的服务。完成后，编制将客户消息发送至 Oracle 电子商务套件，并等待成功响应后再发送定单消息。该编制可确保 Monster 的所有活动按预期序列发生，并确保在该过程中遇到错误时进行正确的补偿。

BPEL 框架

BPEL 是一个强大的语言，允许使用 Web 服务组件开发复杂的业务流程。BPEL 流程可指定调用哪些 Web 服务以及调用的顺序。BPEL 服务器跟踪事务中涉及的业务流程；确保这些步骤以正确顺序执行；并管理事务、补偿和异常。

BPEL 支持来自任何编制语言的所有控制流结构：循环和条件、变量，分配数据值，定义错误处理程序，等等。BPEL 接收活动用于定义当客户端通过服务接口首次调用它时将创建业务流程实例的事件或消息。然后该流程将调用其他服务（定义的业务流程序列中的活动）。通常将生成一个响应（回复）。

其中，BPEL 流程可能必须操作数据变量（赋值），处理错误和异常（引发）或等待一段时间。最后，该流程可以在任意时刻结束（终止）。

该元素变量定义在整个流程描述中使用的所有消息和数据。变量用于发送到涉及的服务或从它们接收的每个消息。它们用于与任何编程语言相同的方式处理流程执行。

结构化活动可能包括按顺序（序列）执行活动或并行（流）执行活动的 BPEL 编制。以下是 BPEL 中最重要的一些控制流活动：

• switch — 基于条件选择路由
• while — 等待特定条件的满足
• pick — 等待接收若干消息之一

BPEL 可以基于条件行为定义业务流程异常。例如，将 Monster 按区域划分：北美、欧洲和亚太地区。根据定单的来源区域，BPEL 流程执行区域特定的逻辑。

同样，Monster 已经定义了定单-发票 BPEL 流来并行处理客户和定单，同时按顺序处理定单服务。

BPEL 处理编制服务 (partnerLink)，该服务可为该流程与之交互的各方定义接口。这些 partnerLink 包括 BPEL 流程和该接口（客户端通过该接口调用 BPEL 流程自身）调用的服务。BPEL 流程灵活绑定到物理服务端点可以在设计、部署或运行时进行。对于上面描述的服务，Siebel 和 Oracle 电子商务套件适配器是我们的关键 partnerLink。

BPEL 具有对异步事件的丰富支持。BPEL 流程可以等待在任何时候从客户端（同样的 BPEL 接收活动用于实例化新的流程实例）接收消息或请求。BPEL 引擎将处理保持流程状态的开销，直到该消息传入并将消息与特定流程实例相关（通过标准 WS-Addressing 或自定义相关机制）。

BPEL 流程自身可将同步或异步接口公开给它们的客户端。同步 BPEL 流程操作锁定客户端直到流程返回对客户端的响应。异步 BPEL 接口可以是单向的（“即发即弃”），或通过回调返回对客户端的响应。异步流程常用于较长期运行的操作，而同步常用于较短期运行的操作。

在 Monster，上面描述的定单-发票流程是长期运行的异步流程。除了上面描述的逻辑，Oracle 电子商务套件中创建的发票号通过回调返回到 Siebel，如果发生异常，异常处理过程包括人工流程。

异常和补偿处理

通常，实现有用的业务流程用例（当一切准备就绪时）只是业务流程总体设计和实现工作的一小部分。大部分时间都花费在定义所有适当的异常处理逻辑上，以便构建在所有预期条件下（甚至在意外条件下）能够进行合理操作的强健且灵活的流程。BPEL 提供了丰富的异常处理功能，以便开发人员可以定义（以分层 try/catch 类型模式）在流程执行过程中出现异常和错误时如何处理。

但是，除了异常处理之外，一些流程需要更具事务性的行为。在短期流和服务方面，标准事务模型足够用了，因为它们使用的是 XA 或 ACID 事务模型，其中的资源可在事务持续时间内锁定并在必要时回滚。

但是，在业务流程编制领域，服务可能由外部组织拥有，并且执行流程和服务接口可能要花几分钟、几小时甚至是几天，因此需要一个新的事务模型。这称为长期运行的事务或补偿事务。虽然该领域正等待这方面的实际标准来允许事务协调器自动处理补偿事务，但是 BPEL 语言通过一个称为补偿处理程序的特性为该功能提供了支持。

补偿处理程序可以显式撤销在某个错误条件生成前成功完成的工作。每个调用活动可以按需与撤销它的补偿活动配对。如果出现错误，针对在失败活动范围内已经完成的工作的补偿处理程序将用于撤销完成的工作。

不足之处在于，该补偿处理程序方法需要流程设计器显式考虑如何补偿每个活动。正面来讲，BPEL 引擎然后将在运行时跟踪所有活动并只为以前完成的步骤执行那些补偿处理程序。此外，BPEL 引擎将在运行时对数据进行快照，以便补偿处理程序在初始活动完成时可以访问当前数据。最后，该方法意味着服务自身无需具有对补偿事务的显式支持 — 这是好事，因为对补偿事务而言仍然没有诸如 XA 和 JTA 的标准。

BPEL 2.0

BPEL 2.0 是作为通用 OASIS 标准的 BPEL 1.1 的发展演变。BPEL 2.0 提供一些重要的增强功能，例如：

• 新活动类型 — if-then-else、repeatUntil、validate、forEach 和 extensionActivity
• forEach 活动中的完成条件
• 变量初始化
• 用于变量转换的 XSLT — 新的 XPath 扩展函数 bpws:doXslTransform
• 对变量数据的简化 XPath 访问 — XPath 变量语法 $variable[.part]/location
• Web 服务活动中的 XML Schema 变量 — 用于 WS-I doc literal 样式服务交互
• 局部声明的 messageExchange — 接收和回复活动的内部关联，抽象流程的分类

除 BPEL 2.0 之外，我们 BPEL 的其他发展以及相关标准包括对人工流程和子流程的显式支持。（有关 BPEL 2.0 的更多信息，参阅 OTN 上“新 SOA 标准”系列的技术白皮书。）

人工流程

BPEL 旨在实现建模为 Web 服务的服务间的交互。这意味着，它不通知任何有关人工交互和手动流程的步骤。但是，由于 BPEL 具有对异步服务的丰富支持，可以将人工流程服务实现为，使人工和手动步骤从流程角度看起来像其他任何异步服务。该方法的优势在于，BPEL 流程可以保持百分之百的标准，而手动和自动系统交互可以轻松编制。Oracle 已将该方法用于 Oracle BPEL 流程管理器的人工流程服务。

使用此方法，用户交互的范围从简单的方案（例如，流程中的手动批准步骤）延伸到复杂的方案（其中用户必须输入数据才能使流程继续）。现在有一个积极的标准化工作正在进行中（称为 BPEL4People），它旨在标准化该方法论以将人工任务合并到 BPEL 流程。

业务规则

业务规则是将业务的特定操作或策略抽象为外部化描述的方式。使用能够将经常变化的业务逻辑具体化为业务规则的开发方法（而非将它们嵌入在服务和流程中），使业务在描述其操作、定义和约束时能够保持敏捷。业务能够更有效地响应更改，因为规则集中在一个信息库中，从而可从核心业务流程分别管理它们。

以下是当敏捷需要可通过抽象业务规则来满足时的一些示例方案：

• 定期或经常改变的业务逻辑（例如，定价规则和促销）
• 复杂的决策逻辑难以使用诸如 BPEL 或 Java 的语言实现
• 合规要求

Monster Worldwide 认为 Oracle SOA 套件是合适的解决方案，这主要因为其组件产品的紧密集成。这些组件之一是 Business Rules Engine，它与 BPEL 结合使用时允许划分我们的业务逻辑。例如，Monster 使用业务规则进行销售定单的定单项税款计算。Monster 的规则还包括业务特定的规则，例如，描述工作和简历在工作搜索站点中的张贴位置的规则。

有两个主要的结构方法可用于在 SOA 中包括业务规则引擎。业务规则可以在实用工具服务层实现。这些规则是按通用方式设计的，可以提供能够从多个地方利用的决策服务。业务规则还可以实现为具有特定业务行为的服务。无论是实用工具服务还是业务服务，当业务规则作为编制的流程的一部分时，它们能以更灵活的方式指定流程后台的逻辑和流，而不是使用过程编程语言进行硬编码。我们推荐一个最佳实践：组织考虑业务规则适用于业务流程的何处，并使用业务规则产品为业务用户定义和执行这些规则 — 在适当的时候友好地编辑可用界面。

设计模式

设计模式是“对所遇到问题的解决方案”；即，它表示对设计中重复出现的问题的高质量解决方案。在过去几年中，设计模式在 IT 界非常引人注意，而我们现在注意到服务编制设计模式的出现。这里我描述几个此类模式。

错误诊断 (Error Hospital)。 该模式将异常处理作为服务提供。要最大化流程简易性和性能，需要将业务流程设计为简单的异步流程甚至短期同步流程。当出现异常时，消息会发布到错误诊断过程，然后提供所需的异常管理，包括人工服务（如果需要）。

很多服务编制模式在诸如 Oracle BPEL 流程管理器的编制引擎中实现：

• 组合服务。 将多个服务的功能合并到一个组合服务中，并将其作为一个整体提供给感兴趣的客户。BPEL 通过自动将每个过程作为服务提供来支持这一点，这些服务可用作构建块来构建较高级的复合流。
• 编制引擎。 使用可运行在编制引擎上的标准语言（例如，BPEL）显式指定与编制相关的控制流和数据流。编排引擎可以提供基础架构服务，例如，审计线索、长期运行流的持久性、常见异常处理模式，等等。
• 服务补偿。 以与松耦合、无状态服务和长期运行流程结合的方式提供事务性支持。
• 编制实例。 创建用户并允许其独立观察并管理业务流程的并发实例。

Monster 在我们的集成中间件的体系结构中使用了大量设计模式。

• 有保证的提交
  • 消息发送者如何确保其消息提交到 BPEL 编制引擎中的相关流程（即使消息处理系统失败）？
  • 在将消息传送到 BPEL 编制引擎之前以事务方式将消息保留到数据存储。每次都要删除在前一流程前保留的消息。

• 消息历史和审计日志
  • 如何在松耦合系统中分析和调试消息流？
  • 为消息附加消息历史以列出消息从产生以来经过的应用程序和组件。

• 过滤器
  • 如果消息包含多个元素（每个元素可能经过不同处理），如何处理消息？
  • 将组合消息分为一系列单独消息，每个包含与一个项相关的数据。

• 消息存储
  • 如何在不破坏消息处理系统的松耦合和临时特性的前提下报告消息信息？
  • 在中心位置（独立于基础编制引擎平台的事务性数据存储）捕获每个消息的信息。

• 异步请求回复
  • 当应用程序发送消息时，它如何从服务器获取响应？
  • 发送一对请求-回复消息，每个消息在它自己的信道上并通过消息主体数据或 WS-Addressing 关联。

• 聚合函数
  • 如何合并相关联的单个消息的结果，以便将它们作为整体进行处理？
  • 使用会话状态的过滤器收集并存储单个消息，直到它接收完整的相关消息组。然后，发布从多个单独消息浓缩提取的单个消息。

测试编制的 BPEL 流程

当涉及到编制多个服务的长期运行的异步流程时，测试变得既关键又复杂。要全面测试一个流程，需要满足以下情况：

• 服务满足功能要求。每个服务需要单独满足定义的功能要求。此外，需要针对功能和服务质量要求单独测试每个流程。
• 流程将模拟具有所有可能返回值（包括异常、超时和重试等）的服务之间的所有可能交互。测试应该在包括所有可能的正反面用例以及可能的异常处理选项的情况下进行。流程可在生产中伸缩。在 Monster，我们认为性能测试应该至少模拟预期最大事务量的 200%。
• 对共享服务的修改不公开共享缺陷。确保服务中的更改不损害使用它们的应用程序。

结论

过去几年，我们看到诸如 BPEL 的业务流程编制标准以及诸如 Oracle SOA 套件的技术平台从出现到走向成熟。随着这些标准和平台的采用，开始出现一组最佳实践和设计模式。我们希望诸如本系列的文章将鼓励更多用户分享其想法和知识。

在本文中，我们讨论了现今在大量业务应用中常见的大量业务流程编制特性和要求：长期运行的流程和人工流程、可靠的通信、Web 服务的使用、流程可持续性和补偿处理。

诸如 BPEL 的新标准和 Web 服务的强大之处在于它们的抽象和平台基础架构，它们本身就可以提供这些功能，以便 IT 组织可以编写较少的衔接代码。有了这些工具，我们相信企业能够获得比以前更强健、更灵活的业务流程自动化和监控。

第 4 部分：通过富用户界面公开服务

作者：Jennifer Briscoe

富用户界面（富 UI）是一个在外观上与桌面应用程序类似的界面。这些类型的界面既有优势又有劣势，但却能够向 IT 和终端用户均衡展示面向服务的体系结构 (SOA) 的优势。

最近，富 UI 空间有了一系列改进，随之而来的是各种各样的工具包、吸取的经验和教训，以及最佳实践。这部分的“精通 SOA”将描述富 UI 的优势以及如何在 SOA 中利用从 Collect America SOA 中吸取的经验和富 UI 计划来成功地提公开服务。

Collect America

Collect America 提供资产管理服务和可以持续重新定义同类最佳的财务产品。Collect America 体系结构是一个 N 层体系结构，支持多个商业应用程序和第三方供应商交互。该体系结构基于 SOA，可以提供数百种内部和外部服务，其中许多服务参与编制自动及手动工作流程。Collect America 的最终用户应用程序需要有一个动态界面，为多个不同的数据源提供一个响应迅速、统一的视图以直观地展示交互过程。

以下是 Collect America 体系结构的高级概览。

什么使界面丰富？

虽然富 UI 还没有被普遍接受的标准定义，但在本质复杂的应用程序中发现了一些关键特性。

提升的响应性。 传统的 Web 应用程序通常以自上而下的方式呈现页面。这意味着载入一个页面所花费的时间不短于该页面的最长操作时间。此外，传统的 Web 应用程序将数据留给其在服务器上与之交互的一方，从而延长了往返路线，即便是排序和筛选等简单的活动也是如此。富 UI 通常在客户端缓存数据集，由于不必再返回到服务器，从而可以更快地响应排序和筛选等活动。

与服务器进行异步通信。 除客户端数据缓存外，与服务器进行异步通信消除了传统的自上而下呈现页面的操作，从而使用户感觉性能提高了。可以异步进行耗时长的操作，一旦完成，回调机制会触发呈现页面的某一部分。这自然导致了创建标记片段（portlet 和 JSF 制作的简单事物）以利用并行化的趋势。

HTML 自身不提供行为。 富 UI 在外观上明显不同于传统的 Web 应用程序，在与最终用户的交互以及浏览应用程序的方式上差别也很大。那种外观仅凭 HTML 是无法营造出来的。例如，HTML 自身无法打开新窗口或改变鼠标上的颜色。然而，这些动态特性与异步行为和并行化相结合，在应用程序中创建了非常精美的窗口。图 A 显示了一个使用 javascript 动态构建搜索查询的示例。然后，使用 HTML 之外的其他技术显示查询的结果（只显示了部分结果列表，根据用户鼠标的滚动情况获取下一列表内容）。

然而，单独这些特性无法丰富界面。用户还必须具有丰富的经验，即有关界面特性和底层体系结构的经验。富 UI 位于 SOA 之上，可以提供业务流程和域模型。它们可以提供丰富的数据源，并且随着使用会更加丰富。最重要的是，它们展示了底层体系结构的智能。

为什么选择富 UI？

富 UI 有许多优势。这些优势不仅涵盖了性能和增强的功能，还涉及到可维护性和灵活性。但是，为什么富界面始终是正确答案呢？

富 UI 通常适合用于以下情况：

• 应用程序很复杂且包含一系列联系松散的功能，这些功能分散在不同的数据源/系统中，但需要单一的界面聚合。
• 用户经常需要并行处理事务，收集有关某一事物的知识，然后将其运用到另一事物。
• 不仅功能不同，而且用户需要并行操作不同的数据。
• 会话需要是“丰富的”— 它们需要会话状态以追踪目前为止发生的和即将发生的事情，并与服务器进行交互。
• 保留每次与应用程序会话的状态很重要 — 您不必因为用户选择启动另一个活动而使原来的活动失效。

在 Collect America 案例中，主要的业务需求是围绕在一个屏幕上向用户展示尽可能多的数据。这需要将大量数据聚合在一个界面中。此外，最终用户和应用程序交互的目标有两个 1) 使用附加信息批注一个现有帐户 2) 随着每个帐户所属数据集的增大，及时在不同点作出帐户处理策略的决定。结果是，在操作数据集的不同最终用户之间产生长时间运行的会话状态，该数据集随着使用变得越来越丰富。Collect America 案例中的会话状态、消耗时间、多个用户以及数据集使得富 UI 成为天作之合。

富 UI 以何种方式应用在 SOA 的什么地方？

此处的 SOA 原则为人们所熟悉：

• 基于策略的行为协商
• 边界清晰
• 自治
• 约定交换

如果服务有清晰的边界，则实体会互不信任，也不共享数据。服务可以强制使用自己的安全策略。此外，自治理念的内在含义是服务自我管理、位置透明、相互独立和松散耦合。这些特性使得公开独立周密的模块功能变得非常容易。事实上，通过提供可在任何数量的业务流程中组合和重组的底层体系结构，JSF 和 portlet 等富 UI 技术和框架的发展增强了丰富的用户体验。

然而，如此松散耦合的服务如果没有事件将它们联系起来，就会形成业务流程难以跨越的垂直功能孤岛。富 UI 通过在 SOA 上提供一个事件框架来帮助跨越这些垂直孤岛，它们提供了一种方法使用户可以切实形象地了解该体系结构的优势。

例如，portlet 提供了一种出色的方法以向最终用户公开基础服务。通过挑选页面或屏幕上驻留的内容，最终用户可以看到该体系结构的灵活性甚至底层智能。此外，最终用户享有重用的权利。

开发过程和考虑事项

现在我们已经了解了 SOA 和 富 UI 是如何互为支持的，下面讨论实施。开发富 UI 时主要考虑的事项为：

• 业务流程分析
• 高级交互设计
• 框架/工具包选择
• 培训
• 测试和诊断

开发 SOA 或富 UI 时一个主要的工作就是业务流程分析。此分析不仅用于确保服务级别粒度是适当的，还通过用户界面更加清楚地定义交互和导航路径。重点应该放在对业务流程的透彻分析上。

创建了业务流程模型库后，服务粒度就开始形成。下一步主要是对交互设计执行同样的分析流程。交互设计必须直观。人们只使用他们了解或者可以很快学会的事物。例如，下面的屏幕截图展示了通过 Collect America 应用程序的一个页面提供的一些服务。每个演示区都通过基础服务提供不同的数据集和数据视图。这样，一个页面可以展示大量数据而不会对用户造成混乱。此外，正确的服务粒度确保了对后续页面和/或应用程序最大程度的重用。

交互设计完成后，您应该了解实施所需的一切了，可以选择框架或工具包。选择框架时考虑以下事项：

• 网络带宽
• 显示操作
• Web 远程控制
• Web 服务的使用
• 对 DOM 操作的需求
• 优化性能的能力
• 可维护性

许多框架以小部件和打包视觉效果的形式不同程度地提供对以上各项的内置支持。正确的框架可以促进生产率的大幅提高。例如，为 Collect America 选择框架时，主要考虑的是开发工作生产率的增长。下面的屏幕截图是 Collect America 应用程序内的一个主页示例。使用 Oracle ADF Faces 实施中的一个即需即用的小部件来制作图形，这样可以节省大量开发时间。

对所选工具的培训也是重要的考虑因素。这些工具包和框架在提供灵活性的同时也增加了培训的难度和需求。

最后，需要改变测试和诊断方法以反映所选工具包和框架的使用。DOM 检查、带有日志记录的 instrumenting javascript、javascript 调试器和流量嗅探等诊断科技都需要是随时可用的工具。

此外，从整体考虑测试时，可以使用一些方法。服务模拟提供了很好的解除前后端耦合的方法，有助于敏捷开发。还应考虑如何像 Junit 在服务器端进行自动单元测试那样自动进行 JavaScript 单元测试。另外，在服务级考虑自动测试而非仅在方法或类级。最后，综合测试 Web 应用程序行为的工具包和内嵌的 Ajax 模型从整体考虑系统测试自动化。

结论

在过去的几年中，可供富用户界面使用的工具包和框架的数量猛增。随着这些框架被集成到企业应用程序中，开始出现一组最佳实践和设计模式。经过深思熟虑和预先规划，富 UI 概念可以发挥 SOA 的优势并将其送到最终用户的手中。