编排是 ESB 的责任吗？

Posted 2023-03-08

【中文标题】编排是 ESB 的责任吗？

【英文标题】：Is orchestration an ESB responsibility?

【发布时间】：2010-09-25 15:15:28

【问题描述】：

是一种企业服务总线（一种充当中介、消息代理、服务启用者、模式转换增强器、透明位置提供者、服务聚合器、负载平衡器、监视器等的工具那些东西）负责协调服务？

在您的企业服务总线中放置一个包含上千个步骤和数十个服务调用的自动化业务流程怎么样？

您会这样做，还是会使用编排专家（例如 BPEL 引擎）？

请给点意见。

【参考方案1】：

我的简短回答是否定的，这不是它的责任。

我宁愿把它交给 BPEL 或 BPM 套件。

嗯，我不知道还有什么要补充的:) ...祝你好运吗？

【参考方案2】：

现在是我自己的愿景。

关于 ESB 必须完成的所有工作，将服务编排放在 SOA 的主要基础架构元素中并不是一个好主意。

聚合，好的！但是，让您的沟通渠道忙于业务逻辑肯定会对交付其他功能的能力造成严重影响。

毕竟，大多数 ESB（例如 BEA Aqualogic Service）对编排的支持有限，包括缺乏有状态功能，以及诸如等待（计时器）或选择（等待某些输入在进程中移动）、拆分/连接功能（已在 ALSB 3.0 中添加）等等。

没办法。只需使用 BPEL 引擎之类的工具或 Weblogic 集成之类的工具。

谢谢。

【讨论】：

或 ALBPM（哎呀，我的意思是 Oracle BPM）

Jjajajaja！好吧，我原谅你。但对我来说，Oracle BPM 或 Oracle Service BUS 仍然是旧的和不错的 BEA。

【参考方案3】：

是和不是。编排和聚合/服务增强之间有一条细线，有时甚至无法区分。

一般来说，如果您有任何长期运行或复杂的业务流程（流程是关键词，尽管我将避免对其进行定义） - 最适合 BPEL。

简单的任务，例如聚合三个服务调用的结果，可以而且经常应该在 ESB 层中完成。

不过，睡太多觉是不值得的

免责声明：我是一名 IBM ESB 顾问，尽管我并非以官方身份撰写本文。

【讨论】：

BPEL 的另一个替代方案是 BPMN——尽管 BPEL 似乎更适合编排类型的活动，而 BPMN 更适合处理类似的活动。

【参考方案4】：

只要您有两个或多个交互的服务，就使用服务编排器，即用于组合和流程控制服务。如果您有 esb，请在 esb 上公开此组合服务。现在，如果您必须编写包含此组合服务的新服务，请使用协调器并再次在 esb 上公开。 使用 esb 作为服务交付机制和 Web 服务代理和代理。在编写服务编排器时，将使用 esb 来访问交互服务。如果这些交互服务使用不兼容的 xml 模式，esb 可以在运行时将它们转换/映射到公共模式并根据内容路由服务请求，例如命名空间。

【参考方案5】：

是的，在大多数情况下，编排是 ESB 的职责。或者，或者，如果您在 ESB 基础架构和编排基础架构之间划清界限，那么您是出于性能原因在物理级别上这样做，而不是出于责任的逻辑归属。

您有 2 个选择 - 例如，当 HR 系统接收新员工时 - 将“合规部门需要先批准和检查，然后如果没问题，HR部门需要完成招聘，然后会计部门需要一个新条目，然后工资系统需要更新，如果失败，那么我们需要给 HR 发送一封电子邮件”？如果所有业务流程都被认为是由发起部门/应用程序“拥有”，那么作为企业的整个系统就会变得复杂，具有不同的编排系统。

第二种选择是集中编排，本质上使其成为消息传递平台的逻辑伙伴。如果您选择将它们视为单独的工件，这取决于您，但将两者都描述为 ESB 同样有效。

【参考方案6】：

不，ESB 的职责不是编排服务（本身）。 ESB 在“软件基础架构级别”提供了一个抽象层。

这意味着 ESB 是与总线上发布的任何服务的“连接的单一逻辑抽象端口”。

ESB 是抽象的，意味着总线上的服务消费者不需要“知道”服务的部署细节，并且可以使用单个文档模型公开“面向内部的服务”。 ESB 提供低级服务（例如协议转换和消息转换），以便内部服务可以以简化的方式进行通信。

这意味着一些编排：ESB 提供了上述低级服务的编排（例如，当通过 IIOP 调用服务 X 时，将其转换为带有附件的 SOAP。然后将请求从任何序列化数据转换为 XML 有效负载）。

在 ESB 中您通常会避免的编排是：为了处理此（保险）销售，我们首先需要验证买方提供的信息，然后我们需要承保保险风险，最后计算需要为保险支付的保费，之后我们需要……等等。

上述步骤显然是一个业务流程（甚至可能被中断……例如，如果无法自动承保，则需要人工承保人进一步评估风险）。

构成业务流程（例如保险销售）的业务服务（例如验证、承保、保费计算），通常称为编排，最适合在业务流程引擎中发生并使用形式化的业务流程建模语言（如 BPEL）。

还要对流程中的许多步骤进行猜测：在上面的示例中，验证是一项（课程粒度）服务。验证规则本身是该服务的内部。对于复杂的业务规则（即非业务流程），可能需要使用业务规则引擎。

【参考方案7】：

企业服务总线不应该负责编排服务。

编排意味着最少的“智能”，特别是补偿失败交易的能力。服务总线工具通常会说它们提供“try-catch”或类似的功能，但运行范围补偿的能力是正确编排工具的标志。此外，等待、了解自身状态或保持悬念的能力是另一个表明您正在与协调器而不是总线打交道的指标。

谈到 1000 多个步骤和数十项服务，请考虑流程中的 if-then 条件。如果 1000 步中的所有 if-then 语句仅涉及路由而没有更改有效负载，那么您仍处于“路由”状态，因此仍处于 ESB 中。但是，如果甚至有一个 nested if-then，我就会开始寻找不同的工具。此外，看起来像路由的 if-then 会很快影响业务逻辑。一旦业务逻辑开始出现，那么更好的语言（例如 BPEL 或 BPMN）会更好。

经常以管弦乐队指挥为例来描述管弦乐的工作原理，一个中心人物根据乐谱指挥音乐家。通常留下的想法是，指挥不仅在指挥，而且在倾听，如果出现问题，可以以可靠、可重复的方式进行补偿。

例如，假设我们的第一位指挥要请大号手，但说大号手决定去做别的事情。一个简单的弹球式“协调员”将带入大号部分，完全知道它不存在，然后等待观众稍后抱怨。一个真正精明的指挥会看到大号消失，并立即调出更深的男中音号角来弥补。