15

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

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

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

请给点意见。

4

7 回答 7

15

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

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

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

不过，这不值得失去太多的睡眠

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

于 2008-12-07T09:25:21.233 回答
9

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

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

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

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

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

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

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

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

于 2012-12-03T03:45:42.157 回答
5

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

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

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

于 2008-12-06T02:05:24.103 回答
5

现在是我自己的愿景。

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

合体，好！但是，让您的通信渠道忙于业务逻辑肯定会对交付其他功能的能力产生可怕的影响。

毕竟，像 BEA Aqualogic Service 这样的大多数 ESB对编排的支持有限，包括缺乏有状态的功能，以及等待（计时器）或选择（等待某些输入在流程上移动）等活动，拆分/加入功能（ ALSB 3.0 中已添加），依此类推。

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

谢谢。

于 2008-12-06T02:09:14.640 回答
2

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

于 2011-09-30T16:25:00.393 回答
1

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

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

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

于 2011-10-25T06:46:24.300 回答
0

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

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

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

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

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

于 2016-03-14T23:42:03.447 回答