企业服务总线（一种充当中介、信息代理、服务启用器、架构转换增强器、透明位置提供者、服务聚合器、负载均衡器、监视器等工具的工具）负责编排服务吗？
如果将包含数千个步骤和数十个服务调用的自动化业务流程放置在企业服务总线中，您会这样做，还是会使用编排专家，例如BPEL引擎？
请给出您的意见。
7个回答
16
是和不是。编排和聚合/服务增强之间有一条薄而有时难以区分的界线。
通常，如果您有任何长时间运行或复杂业务流程（流程是关键词，尽管我将避免定义它）- 最适合使用BPEL。
简单的任务，例如聚合三个服务调用的结果，可以且经常应该在ESB层中完成。
然而，这并不值得太多担忧。
免责声明：我是IBM ESB顾问，尽管我不是以正式身份撰写此文。
- Andrew Ferrier
1
另一种替代BPEL的方案是BPMN——尽管BPEL似乎更适合编排类型的活动，而BPMN更适合像流程一样的活动。 - Marco
9
不，ESB的职责并不是协调服务（本质上）。
ESB在“软件基础架构层面”提供了一层抽象。
这意味着ESB是一个“连接任何总线上发布的服务的单个逻辑抽象端口”。
ESB是抽象的，这意味着总线上的服务消费者不需要知道服务的部署细节，并且可以使用单个文档模型公开“内部面向服务”。ESB提供低级服务（如协议转换和消息转换），以便内部服务可以以简化的方式进行通信。
这意味着一些协调：ESB提供前述低级服务的协调（例如，当通过IIOP调用X服务时，将其转换为带附件的SOAP。然后将请求从任何序列化数据转换为XML有效载荷）。
您通常要避免在ESB中进行的协调是：为了处理此（保险）销售，我们首先需要验证买方提供的信息，然后我们需要承保保险风险，最后计算需要支付的保险费，之后我们需要...等等。
上述步骤显然是业务流程（甚至可能会被打断...例如，如果无法进行自动核保，则需要人工核保进一步评估风险）。
组成业务流程（例如保险销售）的业务服务（例如验证、承保、保费计算），通常被称为协调，最适合在业务流程引擎中进行，并使用规范化的业务流程建模语言（例如BPEL）定义。
还猜测了您的流程中的许多步骤：在上面的示例中，验证是一项（粗略的）服务。验证规则本身是该服务的内部规则。对于复杂的业务规则（即非业务流程），可能需要使用业务规则引擎。
这意味着一些协调：ESB提供前述低级服务的协调（例如，当通过IIOP调用X服务时，将其转换为带附件的SOAP。然后将请求从任何序列化数据转换为XML有效载荷）。
您通常要避免在ESB中进行的协调是：为了处理此（保险）销售，我们首先需要验证买方提供的信息，然后我们需要承保保险风险，最后计算需要支付的保险费，之后我们需要...等等。
上述步骤显然是业务流程（甚至可能会被打断...例如，如果无法进行自动核保，则需要人工核保进一步评估风险）。
组成业务流程（例如保险销售）的业务服务（例如验证、承保、保费计算），通常被称为协调，最适合在业务流程引擎中进行，并使用规范化的业务流程建模语言（例如BPEL）定义。
还猜测了您的流程中的许多步骤：在上面的示例中，验证是一项（粗略的）服务。验证规则本身是该服务的内部规则。对于复杂的业务规则（即非业务流程），可能需要使用业务规则引擎。
- Brian
5
我的简短回答是不，这不是它的责任。
我更愿意将其交给BPEL或BPM套件。
嗯，我不知道还有什么要补充的 :) ...祝好运？
- Oscar Reyes
5
现在是我的个人观点。
关于ESB所需完成的所有工作，将服务编排放入SOA的主要基础设施元素中并不是一个好主意。
聚合，可以！但是让您的通信渠道忙于业务逻辑肯定会对交付其他功能的能力造成可怕的影响。
毕竟，大多数ESB（例如BEA Aqualogic Service）仅支持有限的编排，包括缺乏有状态的能力，以及等待（计时器）或选择（等待某些输入以继续进行过程），分裂/合并能力（已添加到ALSB 3.0）等活动。
没有办法。只需使用诸如BPEL引擎或Weblogic Integration之类的工具即可。
谢谢。
关于ESB所需完成的所有工作，将服务编排放入SOA的主要基础设施元素中并不是一个好主意。
聚合，可以！但是让您的通信渠道忙于业务逻辑肯定会对交付其他功能的能力造成可怕的影响。
毕竟，大多数ESB（例如BEA Aqualogic Service）仅支持有限的编排，包括缺乏有状态的能力，以及等待（计时器）或选择（等待某些输入以继续进行过程），分裂/合并能力（已添加到ALSB 3.0）等活动。
没有办法。只需使用诸如BPEL引擎或Weblogic Integration之类的工具即可。
谢谢。
- paulosuzart
2
或者 ALBPM（哎呀，我想说的是 Oracle BPM） - OscarRyz
Jjajajaja！好的，伙计，我原谅你。但对我来说，Oracle BPM或Oracle Service BUS仍然是旧而美好的BEA。 - paulosuzart
2
当您有两个或更多相互作用的服务时，请使用服务编排器进行组合和过程控制服务。如果您有ESB，则在ESB上公开此组合服务。现在，如果您必须组成包括此组合服务的新服务，请使用编排器，并再次在ESB上公开。
将ESB用作服务交付机制、Web服务代理和代理。在组合服务时，编排器将使用ESB来访问相互作用的服务。如果这些相互作用的服务使用不兼容的XML模式，则ESB可以在运行时转换/映射它们到通用模式，并基于内容（例如名称空间）路由服务请求。
- Bran
1
是的，编排在大多数情况下是ESB的职责。或者，如果你将ESB基础架构和编排基础架构之间划分一条界线，那么你这样做是出于性能原因的物理层面，而不是出于逻辑归属的责任。
你有两个选择 - 例如，当一个HR系统接收到一个新员工时 - 你会把说"合规部门需要先批准和检查，如果没问题，人力资源部门将需要最终确认雇用，并且财务部门将需要进行新的入账，然后工资系统将需要更新，如果失败了，我们将需要向HR发送电子邮件"这种业务逻辑放在哪里？如果所有的业务流程都被认为是由发起部门/应用程序所拥有的，那么企业作为整体的系统会变得复杂，具有不同的编排系统。
第二个选择是集中编排，实质上使它成为消息平台的逻辑伙伴。如果你选择把它们看作是独立的元素，那取决于你，但同时将它们描述为ESB同样是有效的。
- Sentinel
0
企业服务总线不应该负责编排服务。
编排意味着至少需要一定的“智能”，尤其是在处理失败事务时进行补偿的能力。服务总线工具通常会称提供“try-catch”或类似的功能，但运行范围内的补偿能力是合适的编排工具的标志。此外，等待、了解自身状态或保持悬而未决的能力也是您正在处理编排工具而非总线的另一个指标。
考虑到1000多个步骤以及几十个服务，可以考虑流程中的条件语句。如果您的1000个步骤中所有的if-then语句都只涉及路由而不改变有效载荷，则仍处于“路由”中，因此仍然处于ESB。但是，如果有任何一个嵌套的if-then语句，那么我就会开始寻找不同的工具。此外，类似于路由的条件语句很快就会影响业务逻辑。一旦业务逻辑开始出现，那么更好的语言，如BPEL或BPMN，就是更好的选择。
通常用指挥交响乐团的例子来描述编曲是如何工作的，一个中心人物根据乐谱指挥音乐家。经常被忽略的是指挥不仅在指挥，而且在倾听，如果出了问题可以以可靠、可重复的方式进行补偿。
例如，想象一下我们的第一位指挥去找大号手，但该大号手已经决定去做其他事情了。一个简单的弹球式“编曲者”会带来大号部分，完全知道它不在那里，然后等待观众后来抱怨。一个非常精明的指挥会看到大号不见了，并立即提高更深的低音号来进行补偿。
- staylorx
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接