在设计SOA解决方案时，并不总是清楚应该使用Web服务BPEL流程，还是应使用 ESB中介流。本文将介绍帮助您决定使用哪一个的一些注意事项。

　　概述

　　在IBM? SOA参考体系结构中(如图 1 所示)，服务被分组为多个功能区，并通过企业服务总线(以下称为ESB)进行通信。在理想情况下，每个功能区(如流程服务)都是“纯”功能区，为了实现关注点分离仅提供了一个服务类。

　　图 1. SOA 参考体系结构

　　不过，在现实世界中，存在重叠的任何产品集中通常都包含功能区。例如，WebSphere Process Server(以下称为 Process Server)是在参考体系结构中提供流程服务的软件组件。它是从 WebSphere MQ Workflow、WebSphere Interchange Server 和 WebSphere Business Integration Server Foundation 发展而来的。为便于用户升级前代产品，它包括了与旧产品中的功能等效的功能。例如，Interchange Server 包括了业务对象映射，该对象映射以接口映射形式存在于 Process Server 中。

　　可以映射流入或流出业务流程的业务对象。映射还是 ESB 中的主要功能之一。因此，如果您同时拥有 Process Server 和 ESB，则需要决定应使用哪一个产品解决给定的业务问题，原因是这些区域存在重叠。

　　还存在一些可能使用 Process Server 或 ESB 的其他用例。例如，假设需要使用两阶段提交调用三个现有服务。这称为组合服务。在 ESB 中，您可以使用中介流调用这些服务。中介流是作为事务提交或回滚的。您可以使用 WS-BPEL 微流调用这三个服务，同时提供事务性。这样，可以使用这两种产品作为解决方案。如何决定哪一种产品是正确的?

　　ESB 概述

　　ESB 是一种体系结构模式，而不是软件产品。不同的软件产品可以构成 ESB。在某些情况下，公司在不同的区域中使用多种产品，利用特定的功能来满足其独特的需求。可以将这些不同的产品联合在一起实现 ESB 模式。

　　概括地讲，ESB 具有四个主要功能：

　　消息路由：将传入消息发送到目的地，该目的地通过硬编码方式连接的逻辑确定或基于内容的动态方式确定。路由是启用服务虚拟化的关键功能。在调用方和服务之间建立中间层可以在调用方不知道更改的情况下移动服务的位置。

　　消息转换：将传入消息从一种格式转换为另一种格式。例如，可以将逗号分隔的消息转换为 SOAP，这样可以将数据传递到 Web 服务。

　　协议中介：传入消息使用不同的协议从发出位置发送。例如，传入消息可以使用 HTTP，而传出消息可以使用 WebSphere MQ。

　　事件处理：事件的传入消息一般通过发布和订阅模型分发给许多端点。

　　在给定的事务中，通常会合并这些主要高级功能。例如，传入消息可能是一个使用 SOAP/HTTP 的 Web 服务调用，而目的地是需要使用 WebSphere MQ 的固定长度消息格式的遗留系统。必须转换消息、协调协议并且必须将消息路由到正确的位置。

　　对 ESB 编程通常涉及虚拟环境，并将逻辑表示为称为消息流或中介流的连接活动流。这些流都是事务型的，使用的是两阶段提交之类的机制，这样在失败时可以回滚整个流，或者在成功时提交整个流。这些流是无状态的;通常情况下是消息传入，流对该消息执行各种操作，然后发送传出消息。

　　由于 ESB 的无状态事务特性，因此高性能是前提条件。在大型组织中，ESB 每天处理数百万条消息的情况并不少见。

　　IBM 在 ESB 方面提供了多款软件产品。WebSphere ESB 是基于 WebSphere Application Server Network Deployment 平台构建的。构建它是为了支持 Web 服务、JMS 和 XML 之类的标准。WebSphere Message Broker(以下称为 Message Broker)是一种非 J2EE 产品，它支持 WebSphere ESB 中的标准(如 Web 服务)，以及许多基于非标准的协议和数据格式。WebSphere DataPower 是一种硬件工具，它可以飞速执行 ESB 功能。总之，这三种产品都可以用作 ESB 的基础。

　　BPEL 概述

　　OASIS 标准组织已将 Business Process Execution Language (BPEL) 定义为基于标准的方法，使用该方法可以编排由服务构成的业务流程。2007 年，WS-BPEL 2.0 被批准为标准语言。作为一种执行语言，WS-BPEL 定义了如何表示业务流程中的活动，以及流控制逻辑、数据、消息相关性和异常处理等。

　　IBM 的 WebSphere Process Server(以下称为 Process Server)包括业务流编排器(即基于 WS-BPEL 的流引擎)。上一版本称为 WebSphere Business Integration Server Foundation，该版本也包括 WS-BPEL 支持。

　　Process Server 包含多个主要功能，其中包括：

　　业务流程：流程可以是有状态和长时间运行的，或者是事务型微流。长时间运行的流程无法像微流那样回滚，不过，它们可以使用补偿处理程序撤消先前执行的活动。流程可用于实现组合服务。

　　人工任务：业务流程的一个关键部分是能够将人员引入该流程。人工任务管理器启用一些步骤，通过这些步骤可以将人员作为一种服务来调用。工作流模式是使用 BPEL 扩展通过外部(参与)任务或内联任务进行支持的。

　　业务规则：集成的规则引擎允许创建和评估业务规则，而不是将决策硬编码到业务流程。授权用户可以使用 Web 浏览器更新该规则。管理员可以激活更新，并将其导出，因此开发环境可以与运行时保持同步。

　　集成 ESB：Process Server 包括完整的 WebSphere ESB 产品。在本文中，我们只介绍 Process Server 的 BPEL 引擎组件。

　　SCA：Process Server 中的服务调用是使用服务组件体系结构 (SCA) 规范完成的。SCA 接口映射可用于调用其接口与调用组件不同的服务。接口映射也支持高级功能(如关系)。如果系统 A 使用“123”作为客户标识符，而系统 B 使用“ABC”作为客户标识符，则在这两个系统之间转换时，您可以使用关系建立“123”到“ABC”的中介，反之亦然。

　　决定使用哪一个运行时

　　正如前面所提到的，Process Server 和 ESB 之间存在一些功能重叠。二者都可以与适配器一起工作。二者都可以转换数据。二者都支持组合服务模式。当面临使用最佳软件解决给定的业务问题时，您需要决定使用哪一个。

　　作为架构师，您需要熟悉两个软件平台的功能。收集了完整的需求集后，便可以开始决定要使用的流程。

　　业务的第一项是分析需求，并确定所选流程是否为较适合的流程。例如，如果需要有状态流程，则可以立即排除 ESB。另一方面，如果要求在 0.2 秒内处理消息转换，则显然应该选择 ESB。遗憾的是，在现实世界中，并不是所有项目的需求都能机械套用的。通常需要检查多个条件才能确定最佳选项。

　　ESB 的优点

　　ESB 的主要优点之一就是处理消息。消息的传入和传出也许会用到协议或格式中介。当这些需求明显需要处理消息时，使用 ESB 可以提供许多优势，其中包括在转换中处理较复杂事务的能力。当这些需求需要使用 ESB 基本功能(如消息路由、转换或协议中介)之一时，则 ESB 是最佳选择。

　　ESB 的另一个优点是性能。ESB 在计划上能够处理大量的消息。例如，如果需求是每天处理 200,000 条消息，则 ESB 显然是较好的选择。

　　如果需求是以数据为中心的，则显然要选择 ESB。

　　BPEL 的优点

　　BPEL 引擎的主要优点是能够编排业务流程。如果需求是处理具有复杂逻辑的流程，则 BPEL 是较好的选择。WS-BPEL 包含容器活动，如 ESB 不支持的 while 循环和范围。ESB 中的逻辑通常非常简单，而 WS-BPEL 可以处理更复杂的情形。

　　WS-BPEL 引擎(如 WebSphere Process Server)的另一个优点是能够让业务流程长时间运行并维持其状态。当需要状态时，不应使用 ESB，因为维护状态会占用许多自定义代码。如果需求是进行有状态的处理，则在选择时可以排除 ESB。

　　如果需求是以流程为中心的，则显然要选择 WS-BPEL。

　　功能注意事项

　　特定项目的具体需求是确定哪一个环境最适合给定项目的主要因素。您需要考虑的一些重要问题包括：

　　需要哪些传输协议?例如，Process Server 和 Message Broker 都支持 WebSphere MQ，但是只有 Message Broker 支持 IP 多播。如果使用 JMS，还务必了解系统是否支持特定的 JMS 提供程序。

　　需要哪些标准?例如，需求可能是 WS-Security，或支持复杂的工业标准模式。您需要知道服务器是否支持这些标准。例如，Message Broker 对无类型的消息处理可能具有更强的支持，而 Process Server 可以使用 J2EE 安全，因为它运行在 J2EE 容器中。不同的环境可能都支持某个标准，但支持的级别不同。在做出决定之前，确保检查所有的细节。

　　什么是服务质量 (QoS) 需求?系统必须是高可用的吗?如果在高可用性环境中安装了 Message Broker，而未安装 Process Server，则可能会影响您的决策。您需要了解特定的环境，才能理解可用的 QoS。您需要考虑性能需求以及有保证的邮件传递之类的需求。

　　需要哪些路由和消息传递样式?在系统中可以使用各种消息传递样式，如同步或异步、请求/响应、单向和发布/订阅。需要哪些消息传递样式?可能是一种消息传递样式或消息传递样式的组合。在给定的环境中支持哪些消息传递样式?

　　Process Server 可以通过 JMS 主题执行消息发布，而 Message Broker 具有更高级的功能(如基于内容的订阅)。这些需求有助于缩小运行时选择范围。

　　非功能性注意事项

　　除功能性需求外，每个系统还包含一组非功能性需求，在选择正确的运行时还需要考虑这些非功能性需求。

　　什么是总拥有成本?您需要考虑软件的最初成本，以及相关的长期成本。例如，如果客户通过在 J2EE 平台上实现解决方案可以获得较低的成本，则这样会影响选择 Process Server 的决定。

　　什么是管理成本?每个系统都需要一个管理员。如果公司让原有的管理员管理新项目(不添加新资源)，则可能会影响总拥有成本。例如，MQ 管理员可能比较熟悉 Message Broker，而对基于 J2EE 的运行时可能一窍不通。还应考虑如何方便地监视环境，以及管理员处理的安全方面。

　　需要哪些技能?除需要管理员、开发人员、测试人员外、还需要其他角色。如果能够利用现有的技能，则可以节约相关的时间和成本。学习项目的新技能可能需要培训或辅导。

　　什么是现有环境?中间件环境属于生产环境吗?用户熟悉工具集吗?如果需要新工具，则这些新工具与当前工具环境的亲和力如何?必备软件的当前版本级别是否同步?是否必须升级现有资产?在使用系统之前，需要进行任何迁移吗?

　　某个选项提供独特的功能吗?某个环境中的独特功能可能会促进您的决策。例如，您可以在 ESB 中执行映射，也可以通过 Process Server 中的接口映射来执行映射。但是，只有 Process Server 中的接口映射可以提供关系映射。如果您需要此功能，则只有 Process Server 可以提供。

　　当 Process Server 和 ESB 可能都是理想的备选项时，非功能性需求通常可以缩小选择范围。

　　模式

　　电子商务模式是一组经过验证的可重用资产，可使用这些模式帮助您加速开发和部署电子商务应用程序。IBM 发布了一系列描述模式用法和各种技术的红皮书，如 Patterns:SOA Design Using WebSphere Message Broker and WebSphere ESB。

　　您可以检查您的需求，并确定是否可以使用模式来实现这些需求。如果证实现有模式或模式的组合适用于给定的运行时，则可以知道该运行时能够处理您的需求。这样风险就会降低，因为以前处理过，并且通过应用该模式可以缩短开发时间。如果该模式仅在一个运行时上存在，则可以帮助您做出决策。

　　一些典型的模式包括：

　　消息聚合与解聚合(N-to-1 和 1-to-N)

　　1-of-N 响应(发送多个请求，选取一个响应)

　　服务虚拟化(位置和标识)

　　基于内容的路由

　　适配器交互

　　消息充实

　　动态注册中心查询

　　事件传播

　　网关(控制并保护内部和外部域边界之间的交互)

　　例如，引用的红皮书描述了使用网关模式的 DataPower 用法。XS40 XML Security Gateway 可以满足支持此模式的功能性和非功能性需求。如果为实现网关模式查找要使用的解决方案，这有助于促进您的决策。

　　灰色区域

　　尽管在使用上述标准筛选后可以帮助确定最终的决策，但仍存在是选择 ESB 还是选择 Process Server 作为给定项目的运行时的情况。在这些情况下，需要考虑一些其他事项。

　　设计理念

　　某些公司具有指导所有项目的总体设计理念。例如，您可以决定将在 ESB 中进行所有的转换，而所有的业务逻辑驻留在 Process Server 中。

　　如果客户进行了在线订购，则决定他们是否具有免费发货资格的业务决策属于在 Process Server 中运行的业务逻辑层。可以在 ESB 层完成消息到相应发货服务的路由。它允许公司更改业务逻辑，而不必对集成逻辑进行更改(反之亦然)。

　　此总体设计理念在决策中应占有重要的地位。换句话说，什么是策略方向?如果所有其他情况相同，则可以使用此总体设计原则作为标准。

　　成本

　　在服务器上部署的每个 WS-BPEL 流程或中介流都占用该服务器的 CPU 容量。当然，除了硬件成本、支持成本和管理成本等，它运行的中间件也是一种成本。如果不清楚要使用的环境，则可以在部署位置决策中考虑成本因素。

　　维护

　　当决定哪一个平台是解决给定业务问题的最佳平台时，您需要考虑系统的总体长期维护。如果使用 WS-BPEL 相关集 比在 ESB 中编写和维护代码来提供类似功能容易，则您不仅能够快速构建解决方案，而且维护起来也比较容易。如果内置基本函数在任何时间都可用，则与创建自定义代码相比，它是较好的设计备选方案。应优先考虑容易维护的解决方案。

　　维护的另一个方面是，随着中间件产品的发展，将来升级解决方案的难易程度如何。通常，新的主要版本能够使用以前版本中的构件。WebSphere Process Server V6 的工具 WebSphere Integration Developer 可以从WebSphere Business Integration Server Foundation V5.1 导入集成项目，并使用以前项目作为起点。WS-BPEL 流程中的逻辑将转移到新环境。不过，您可能需要在流程中执行一些手动操作才能更新 Java? 代码。在大多数情况下，使用软件产品的内置功能可以使将来的升级途径更容易一些。

　　可重用性

　　为 SOA 构造任何资产时，您应该知道如何促进该资产的重用。在创建某项资产时，您可以用它解决某个业务问题。但是，如果可以重用该资产，则可以大大节省开发时间和成本。

　　通过前面的在线订购示例，您可以使用 ESB 或 WS-BPEL 微流流程执行整个工作。如果将业务逻辑引入 WS-BPEL，并使用 ESB 中的路由逻辑，将存在更大的可重用性机会。在单一环境中使用两种功能，该服务只能使用一次，因为它们都是为特定的用途设计的。通过分离功能，将有很大机会重用其中任何一个功能。例如，内部的装运系统可以利用路由服务。在进行决策时应该考虑创建的解决方案的潜在可重用性。

　　技能优势

　　IT 员工对于某种产品可能有比其他产品更高的技能。为长期支持您的项目，具有较强的技能可能是决策中的关键因素。例如，如果有三名经验丰富的 ESB 开发人员，但是只有一名熟悉 Process Server，则选择使用 ESB 构建项目会更好。

　　风险

　　成功的项目是可以减少风险的项目，这样的项目失败的机会也非常小。如果您在 Process Server 中实现了五个模块，但刚使用 Message Broker 开始构建，这时您可能认为使用 Process Server 风险较低，因为您对 Process Server 有较多的经验。

　　同时，您可以找一些参考资料和案例研究，了解与您需要实现的系统类似的情况。如果有若干其他用户成功使用 Message Broker 完成了项目，这样在您使用时的保险性也会大一些。如果其他用户在类似项目上获得成功，则您的风险也会降低。

　　在评估了项目中所有的风险因素后，您可以将较低风险用作决策的最终标准。

　　总结

　　在本文中，您学习了 ESB 和 WS-BPEL 流程引擎，以及如何确定为您的环境提供最佳解决方案的流程引擎。您学习了每种环境的优点、如何考虑使用功能性和非功能性需求之类的标准，以及如何应用模式。最后，您还学习了一些其他标准，这些标准也许能帮助您在两个解决方案都能够满足要求的情况下做出更好的决策。