编排是ESB的责任吗?

时间:2008-12-06 02:00:50

标签: soa esb bpel orchestration alsb

是企业服务总线(充当中介,消息代理,服务启用程序,架构转换增强器,透明位置提供程序,服务聚合器,负载均衡器,监视器等的工具)那些东西负责协调服务

如何在企业服务总线中部署超过一千个步骤和数十个服务调用的自动化业务流程呢?

您是否会这样做,或者您是否会使用业务流程专家(如BPEL引擎)?

请给你意见。

7 个答案:

答案 0 :(得分:15)

是和否。编排和聚合/服务增强之间存在一条薄薄的,有时难以区分的界限。

一般来说,如果你有任何长期运行或复杂的业务流程(流程是关键词,虽然我将避免定义它) - 这最适合BPEL。

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

虽然

,但是不值得失去太多的睡眠

免责声明:我是IBM ESB顾问,虽然我不是以官方身份撰写本文。

答案 1 :(得分:9)

不,ESB的责任不在于服务的编排(本身)。 ESB在“软件基础架构级别”提供了一层抽象。

这意味着ESB是与公共汽车上发布的任何服务的“单一逻辑抽象连接调用端口”。

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

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

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

上述步骤显然是一个业务流程(甚至可能被中断......例如,如果无法自动承保,那么人类承销商需要进一步评估风险)。

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

同时猜测过程中的许多步骤:在上面的示例中,验证是一种(课程粒度)服务。验证规则本身是该服务的内部规则。对于复杂的业务规则(即非业务流程),可能需要使用业务规则引擎。

答案 2 :(得分:5)

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

我宁愿把它放到BPEL或BPM套件中。

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

答案 3 :(得分:5)

现在我自己的愿景。

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

聚合,好的!但是,保持沟通渠道忙于业务逻辑肯定会对提供其他功能的能力造成严重影响。

毕竟,BEA Aqualogic Service等大多数ESB 都有有限的编排支持,包括缺乏有状态功能,以及类似的活动等待(计时器)或选择(等待一些输入继续进行),拆分/加入功能(已在ALSB 3.0上添加),依此类推。

没办法。只需使用BPEL引擎或Weblogic Integration等工具即可。

感谢。

答案 4 :(得分:2)

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

答案 5 :(得分:1)

是的,编排在大多数情况下是ESB的责任。或者,如果您在下面的ESB infra和编排之间绘制一条线,那么出于性能原因,您在物理层面上这样做,而不是为了责任的逻辑归属。

您有2个选择 - 例如,当人力资源系统收到新员工时 - 您在哪里放置业务逻辑,说明“合规部门需要首先批准和检查,然后如果可以,那么HR部门需要最终确定聘用,然后会计部门需要一个新的条目,然后工资单系统将需要更新,如果失败,那么我们将需要发送电子邮件给HR“?如果所有业务流程被初始部门/应用程序视为“拥有”,则整个系统即企业变得复杂,具有不同的编排系统。

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

答案 6 :(得分:0)

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

Orchestration意味着最少的" smarts",特别是补偿失败的交易的能力。服务总线工具通常会说他们提供" try-catch"或类似的东西,但运行范围组件的能力是适当的编排工具的标志。此外,等待,了解自己的状态或保持悬念的能力是另一个指标,表明你正在与协调者而不是公共汽车打交道。

说到1000多个步骤加上数十个服务,请考虑过程中的if-then。如果1000步中的所有if-then语句仅说明路由而没有更改有效负载,那么您仍然在"路由"因此仍然在ESB中。但是,即使有一个嵌套 if-then,我也会开始寻找不同的工具。此外,看起来像路由的if-thens可以非常快地影响业务逻辑。一旦业务逻辑开始出现,那么更好的语言,如BPEL或BPMN。

管弦乐队指挥的例子经常被用来描述编排是如何工作的,一个中心个体根据得分指导音乐家。通常情况下,导体不仅指导,而且还要聆听,如果出现问题,可以以可靠,可重复的方式进行补偿。

例如,想象一下,我们的第一位指挥带着大号球员,但是大号球员决定去做其他事情。一个简单的弹球式" orchestrator"将带来大号部分,完全知道它不在那里,然后等待观众后来抱怨。一个真正精明的指挥家会看到大号走了,并立即调出更深的男中音喇叭来补偿。