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

　　业务的第一项是分析需求，并确定所选流程是否为较适合的流程。例如，如果需要有状态流程，则可以立即排除 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 的运行时可能一窍不通。还应考虑如何方便地监视环境，以及管理员处理的安全方面。