如何选择

　　正如前面所提到的，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 流程引擎，以及如何确定为您的环境提供非常好的解决方案的流程引擎。您学习了每种环境的优点、如何考虑使用功能性和非功能性需求之类的标准，以及如何应用模式。最后，您还学习了一些其他标准，这些标准也许能帮助您在两个解决方案都能够满足要求的情况下做出更好的决策。