bpel_BPEL或ESB：应该使用哪个？
总览
在图1所示的IBM®SOA参考体系结构中，服务被分组为功能区域，并通过企业服务总线（以下称为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网络部署平台上。 它旨在支持Web服务，JMS和XML等标准。 WebSphere Message Broker（以下称为Message Broker）是非J2EE产品，它支持WebSphere ESB中的标准（例如Web服务）以及许多基于非标准的协议和数据格式。 WebSphere DataPower是可以以线速执行ESB功能的硬件设备。 这三种产品可以一起用作ESB的基础。
BPEL概述
OASIS标准组织已将业务流程执行语言（BPEL）定义为编排由服务组成的业务流程的基于标准的方式。 WS-BPEL 2.0在2007年被批准为标准。作为一种执行语言，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。 ，并非现实世界中的所有项目都是如此干and。 通常，您需要检查几个条件才能确定最佳选择。
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在J2EE容器中运行，因此它可以对J2EE安全性提供更高的支持，例如Process Server可以使用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出版了一系列的红皮书，描述了各种技术对模式的使用，例如模式：使用WebSphere Message Broker和WebSphere ESB的SOA设计。
您可以检查您的需求，并确定是否可以使用模式来实现它们。 如果已经在给定的运行时证明了现有模式或模式的组合，则您将知道运行时能够处理您的需求。 由于以前已经做过，因此风险会更低，并且可以通过应用模式来缩短开发时间。 如果该模式仅在一个运行时存在，则可以帮助您做出决定。
一些典型的模式是：
- 消息聚合和分解（N对1和1对N）
- N个响应中的1个（发送多个请求，选择一个响应）
- 服务虚拟化（位置和身份）
- 基于内容的路由
- 适配器互动
- 邮件充实
- 动态注册表查找
- 事件传播
- 网关（内部和外部域边界之间的受控且安全的交互）
例如，参考的红皮书使用网关模式描述了DataPower的使用。 XS40 XML安全网关满足功能和非功能要求，以支持此模式。 如果您正在查看要使用哪种解决方案来实现网关模式，这可能有助于您做出决定。
灰色区域
即使使用前面几节中的条件来做出最终决定，在某些情况下，您仍然可以选择ESB或Process Server作为给定项目的运行时。 在这些情况下，您还可以考虑其他一些事项。
设计理念
一些公司拥有指导所有项目的总体设计理念。 例如，您可以决定所有转换都将在ESB中进行，而所有业务逻辑都将驻留在Process Server中。
如果客户下达在线订单，则决定他们是否有资格获得免费送货的业务决策将属于在Process Server中运行的业务逻辑层。 将消息路由到适当的运输服务将在ESB层完成。 这使公司可以更改业务逻辑，而不必更改集成逻辑（反之亦然）。
这种总体设计理念应权衡决策。 换句话说，战略方向是什么？ 如果其他所有条件都相同，则可以以此为准则。
成本
您部署的每个WS-BPEL流程或中介流都将消耗部署它的服务器上的CPU容量。 当然，运行该中间件的成本是硬件成本，支持成本，管理等等。 如果不清楚要使用哪个环境，则成本可能会影响部署位置的决定。
保养
在确定哪个平台适合特定业务问题时，您需要考虑系统的整体长期维护。 如果使用WS-BPEL 相关集比编写和维护代码以在ESB中提供类似功能要容易，那么不仅可以更快地构建解决方案，而且维护起来也更加容易。 只要有内置的原始函数可用，这将比创建自定义代码更好。 易于维护的解决方案是高度首选。
维护的另一个方面是，随着中间件产品的发展，将来升级您的解决方案将变得多么容易。 通常，主要的新版本都可以使用以前版本中的构件。 WebSphere Integration Developer是WebSphere Process Server V6的工具，可以从WebSphere Business Integration Server Foundation V5.1导入集成项目，以将先前的项目用作起点。 WS-BPEL流程中的逻辑会延续到新环境中。 但是，您可能需要做一些手动工作才能在此过程中更新Java™代码。 在大多数情况下，使用软件产品中的内置功能可以使将来的升级路径更加容易。
可重用性
每当为SOA构建任何资产时，您都应该询问如何促进该资产的重用。 创建某些东西后，它可以解决业务问题。 但是，如果可以重复使用它，则可以节省大量的开发时间和成本。
使用先前的在线订单示例，您可以使用ESB或WS-BPEL微流程流程来执行整个工作。 如果使用ESB中的路由逻辑将业务逻辑分解到WS-BPEL，则存在更大的可重用性机会。 在单一环境中使用这两个功能时，该服务只能针对其特定目的使用一次。 通过分离这些功能，可以更大程度地重用其中任何一个功能。 例如，店内运输系统可以利用路由服务。 在做出决定时，应考虑所创建解决方案的潜在可重用性。
技能实力
您的I / T员工可能在一种产品上拥有比另一种产品更高的技能。 对于您的项目的长期支持，更强大的技能组合可能是决定您的决定因素。 例如，如果您有3位强大的ESB开发人员，但对于Process Server只有一位，那么使用ESB构建项目可能很有意义。
风险
成功的项目是可以减轻风险的项目，因此项目失败的可能性很小。 如果您已经在Process Server中实现了五个模块，但是刚开始使用Message Broker，您可能会认为使用Process Server的风险较低，因为您有更多的使用经验。
同样，您可能会找到一些与您需要实现的系统类似的参考资料和案例研究。 如果其他几个客户已使用Message Broker成功完成此操作，则可以确保您没有扩大产品范围。 如果其他人已经在类似项目上取得成功，那么您的风险会更低。
在评估了构成项目风险的所有因素之后，您可以将降低的风险用作最终决策标准。
摘要
在本文中，您了解了ESB和WS-BPEL流程引擎，以及如何确定哪种引擎为您的环境提供了最佳解决方案。 您了解了每种环境的优势，以及如何考虑功能和非功能需求等标准，以及如何应用模式。 最后，您了解了一些其他准则，这些准则可以帮助您在两种解决方案似乎都符合要求的情况下做出决定。