维护 
    
    当决定哪一个平台是解决给定业务问题的非常好的平台时，您需要考虑系统的总体长期维护。如果使用 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 流程引擎，以及如何确定为您的环境提供非常好的解决方案的流程引擎。您学习了每种环境的优点、如何考虑使用功能性和非功能性需求之类的标准，以及如何应用模式。最后，您还学习了一些其他标准，这些标准也许能帮助您在两个解决方案都能够满足要求的情况下做出更好的决策。

    参考资料

    您可以参阅本文在 developerWorks 全球站点上的 英文原文
    WebSphere 和 SOA 新手入门：了解 WebSphere 产品如何适应面向服务的体系结构解决方案，新手的捷径。
    WebSphere Web services 专区：获取 WebSphere Web 服务解决方案的最新技术资源，其中包括文章、教程和下载等。
    Patterns:Implementing an SOA Using an Enterprise Service Bus：此 IBM 红皮书重点介绍了如何使用流程集成模式的面向服务的体系结构概要和企业服务总线着手实现面向服务的体系结构。
    Patterns:SOA Design Using WebSphere Message Broker and WebSphere ESB：此 IBM 红皮书讨论了集成 WebSphere ESB 和 WebSphere Message Broker 的模式，并包含一个帮助您设计、开发和部署这些产品的场景。