企业服务总线与 BPM
Enterprise Service Bus vs BPM
我使用过的 ESB 和 BPM 工具都接受一些输入，调用多个步骤来完成任务。我所看到的不同之处在于，在 ESB 中，一切都是自动化的——流程是自动触发的，涉及许多外部调用/数据被转换并发送到适当的系统以供使用。在 BPM 系统的情况下，流程要么手动启动，要么自动启动，它涉及一系列决策步骤，其中一些涉及手动决策 steps.Once 步骤完成，任务标记为完成。能否解释清楚 BPM 和 ESB 之间的区别？
我认为你是对的，任何可以通过 BPM 实现的事情都可以通过 ESB 和一些支持手动步骤调用的 Web UI 来很好地实现。但如果你只是严格地从技术角度来看，这是真的。在更成熟的 SOA 中，涉及许多不同的各方和角色，ESB 和 BPM 都有其独特的位置。
您正在寻找的区别更多 "fuzzy"，它与这些工具的重点、它们的预期最终用户以及它们所组成的逻辑类型有关。这是我在解释 ESB 和 BPM 之间的区别时的拙劣尝试：
重点和目标
ESB 更侧重于实现互操作性、关注点分离和技术细节的抽象。它有更多的基础设施角色，它还关心监控、可扩展性、可用性、状态延迟。在 ESB 中，您的目标是通过抽象所有技术细节和公开可重用功能来创建联合互操作层。
BPM 更以业务为中心，在完美的世界场景中，它由业务人员和业务分析师自己管理，他们修改流程而无需任何想法任何技术细节。 BPMN 语言完全是关于工作流的，并且被设计成对业务友好的。在 BPM 中，您的目标是通过使用这些构建块来实现真正的业务流程。
目标用户
ESB 服务将由架构师和保管人管理（仍然根据业务分析师的要求）。
BPM 工作流最好由业务人员、业务分析师等进行管理和修改。
复合逻辑
在 BPM 中，组合（工作流）由面向业务的任务组成（例如，检查客户忠诚度并在用户 X 批准和他的等级是黄金。
在 ESB 中，组合通常包含更多的技术服务（例如从数据库中检索它，与来自该组件的组合，使用 xslt 转换） .可以有一个编排任务以 BPM 的方式实现整个工作流，它完全以业务为中心并且没有任何可重用性，但是您没有方便的工具和可视化来轻松委派管理对业务人员的这种业务逻辑。
综上所述，理想情况下，如果您拥有成熟的 SOA，您将在一个或多个 ESB 和相应的服务清单之上拥有一个 BPM 层，这些服务清单具有：
- Entity and Utility services 在底部（在 ESB 中实现）
- Task，在某些情况下 Orchestrated Task 服务 组成所述实体和实用程序服务（在 ESB 中实现）
- 工作流 在 ESB 之上的 BPM 层中使用和重用所有这些服务。
我希望这能让您初步了解这些差异。如果您需要更多信息，请随时询问。
Plamen 的回答已经很好了。我不同意介绍
anything achievable with a BPM can be achieved just fine with an ESB
and some Web UI that enables invocation of manual steps
不过他后来的解释使这一点成为现实。
在我看来，与 ESB 相比，现代业务流程管理套件 (BPMS) 处理（更好）的某些方面：
- 适合领域专家的业务流程的图形建模
- 不需要技术细节，例如没有服务组合
- 当任务执行者可以是特定的自动化（系统）与手动（人工，可能有系统支持）时，就达到了正确的粒度。低于这个粒度级别，服务组合开始（ESB）
- 基于假设或真实审计数据的工作流模拟（有或没有服务连接）
- 用于运营控制、战术分析和战略持续流程改进的仪表板和报告功能（全部在业务级别/KPI 上）
- 组织建模、授权管理
- 基于业务流程模型（例如角色）或动态基于条件、业务规则、决策表、用户技能、工作量和能力的实时分析等的任务路由和分配
- 业务流程上下文的管理，例如业务对象、文档、对外部系统中数据的引用、对属于同一业务实体的其他工作流的引用
- 在业务级别保留所有活动的审计跟踪（不是日志文件）
- 全面的工作列表管理和搜索功能
- 运营管理的功能，例如业务 SLA、优先级、基准、关键性、自动或手动任务委派的定义和监控
- 副经理、业务日历等组织方面
- 根据定义的内部或外部技术或业务事件启动或更改现有工作流
BPMS 和 ESB 是互补的系统。 BPMS 是业务层，它协调底层 ESB 层中定义的复合业务服务。 ESB 层是一个技术缓解层，它支持基本服务的定义、将它们聚合成复合服务以及数据格式转换和标准化等其他方面。由于层次很接近，因此两个领域的产品都采用了越来越多的另一层特征。随着供应商扩展其功能集，重叠也在增加。
根据系统环境的复杂性，涵盖许多 ESB 功能的综合 BPMS 可能会使 ESB 过时。扩展到业务层的 ESB 不太可能达到业务用户所需的功能集和易用性。如果 ESB 达到了这个业务级别，那么它可能会重新命名并作为 BPMS 提供。
如果您比较类似 Mule and BPMS like Eclipse Stardust 的 ESB 网站，那么不同的重点（技术集成平台与业务流程管理：建模、模拟、执行、报告、分析和改进）应该会变得很明显。
我使用过的 ESB 和 BPM 工具都接受一些输入，调用多个步骤来完成任务。我所看到的不同之处在于，在 ESB 中，一切都是自动化的——流程是自动触发的，涉及许多外部调用/数据被转换并发送到适当的系统以供使用。在 BPM 系统的情况下，流程要么手动启动，要么自动启动，它涉及一系列决策步骤，其中一些涉及手动决策 steps.Once 步骤完成，任务标记为完成。能否解释清楚 BPM 和 ESB 之间的区别？
我认为你是对的，任何可以通过 BPM 实现的事情都可以通过 ESB 和一些支持手动步骤调用的 Web UI 来很好地实现。但如果你只是严格地从技术角度来看，这是真的。在更成熟的 SOA 中，涉及许多不同的各方和角色，ESB 和 BPM 都有其独特的位置。
您正在寻找的区别更多 "fuzzy"，它与这些工具的重点、它们的预期最终用户以及它们所组成的逻辑类型有关。这是我在解释 ESB 和 BPM 之间的区别时的拙劣尝试：
重点和目标
ESB 更侧重于实现互操作性、关注点分离和技术细节的抽象。它有更多的基础设施角色，它还关心监控、可扩展性、可用性、状态延迟。在 ESB 中，您的目标是通过抽象所有技术细节和公开可重用功能来创建联合互操作层。
BPM 更以业务为中心，在完美的世界场景中，它由业务人员和业务分析师自己管理，他们修改流程而无需任何想法任何技术细节。 BPMN 语言完全是关于工作流的，并且被设计成对业务友好的。在 BPM 中，您的目标是通过使用这些构建块来实现真正的业务流程。
目标用户
ESB 服务将由架构师和保管人管理（仍然根据业务分析师的要求）。
BPM 工作流最好由业务人员、业务分析师等进行管理和修改。
复合逻辑
在 BPM 中，组合（工作流）由面向业务的任务组成（例如，检查客户忠诚度并在用户 X 批准和他的等级是黄金。
在 ESB 中，组合通常包含更多的技术服务（例如从数据库中检索它，与来自该组件的组合，使用 xslt 转换） .可以有一个编排任务以 BPM 的方式实现整个工作流，它完全以业务为中心并且没有任何可重用性，但是您没有方便的工具和可视化来轻松委派管理对业务人员的这种业务逻辑。
综上所述，理想情况下，如果您拥有成熟的 SOA，您将在一个或多个 ESB 和相应的服务清单之上拥有一个 BPM 层，这些服务清单具有：
- Entity and Utility services 在底部（在 ESB 中实现）
- Task，在某些情况下 Orchestrated Task 服务 组成所述实体和实用程序服务（在 ESB 中实现）
- 工作流 在 ESB 之上的 BPM 层中使用和重用所有这些服务。
我希望这能让您初步了解这些差异。如果您需要更多信息，请随时询问。
Plamen 的回答已经很好了。我不同意介绍
anything achievable with a BPM can be achieved just fine with an ESB and some Web UI that enables invocation of manual steps
不过他后来的解释使这一点成为现实。
在我看来，与 ESB 相比，现代业务流程管理套件 (BPMS) 处理（更好）的某些方面：
- 适合领域专家的业务流程的图形建模
- 不需要技术细节，例如没有服务组合
- 当任务执行者可以是特定的自动化（系统）与手动（人工，可能有系统支持）时，就达到了正确的粒度。低于这个粒度级别，服务组合开始（ESB）
- 基于假设或真实审计数据的工作流模拟（有或没有服务连接）
- 用于运营控制、战术分析和战略持续流程改进的仪表板和报告功能（全部在业务级别/KPI 上）
- 组织建模、授权管理
- 基于业务流程模型（例如角色）或动态基于条件、业务规则、决策表、用户技能、工作量和能力的实时分析等的任务路由和分配
- 业务流程上下文的管理，例如业务对象、文档、对外部系统中数据的引用、对属于同一业务实体的其他工作流的引用
- 在业务级别保留所有活动的审计跟踪（不是日志文件）
- 全面的工作列表管理和搜索功能
- 运营管理的功能，例如业务 SLA、优先级、基准、关键性、自动或手动任务委派的定义和监控
- 副经理、业务日历等组织方面
- 根据定义的内部或外部技术或业务事件启动或更改现有工作流
BPMS 和 ESB 是互补的系统。 BPMS 是业务层，它协调底层 ESB 层中定义的复合业务服务。 ESB 层是一个技术缓解层，它支持基本服务的定义、将它们聚合成复合服务以及数据格式转换和标准化等其他方面。由于层次很接近，因此两个领域的产品都采用了越来越多的另一层特征。随着供应商扩展其功能集，重叠也在增加。
根据系统环境的复杂性，涵盖许多 ESB 功能的综合 BPMS 可能会使 ESB 过时。扩展到业务层的 ESB 不太可能达到业务用户所需的功能集和易用性。如果 ESB 达到了这个业务级别，那么它可能会重新命名并作为 BPMS 提供。
如果您比较类似 Mule and BPMS like Eclipse Stardust 的 ESB 网站，那么不同的重点（技术集成平台与业务流程管理：建模、模拟、执行、报告、分析和改进）应该会变得很明显。