编排是ESB的责任吗？

企业服务总线(充当调解器,消息代理,服务启用器,架构转换增强器,透明位置提供程序,服务聚合器,负载平衡器,监视器以及所有这些东西的工具)是否负责协调服务？

如何在企业服务总线中放置超过一千步和几十个服务调用的自动化业务流程？

你会这样做,还是会使用编排专家如BPEL引擎？

请给你意见.

是的,不是.编排和聚合/服务扩充之间存在一条薄薄的,有时难以区分的界限.

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

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

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

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

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

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

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

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

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

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

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

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

我的简短快速回答是否定的,不是它的责任.

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

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

现在我自己的愿景.

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

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

毕竟,大多数ESB(如BEA Aqualogic Service)对编排的支持有限,包括缺乏有状态功能,以及等待(计时器)或选择(等待一些输入移动进程),分割/连接功能等活动(已添加到ALSB 3.0),依此类推.

没门.只需使用BPEL引擎等工具或Weblogic Integration等工具即可.

谢谢.