业务流程是ESB责任吗？

Question

是一个企业服务总线(充当中介、消息代理、服务增强器、模式转换增强器、透明位置提供者、服务聚合器、负载均衡器、监视器等)，负责编排服务

在您的企业服务总线中放置一个具有上千个步骤和数十个服务调用的自动化业务流程如何？

您会这样做，还是会使用业务流程方面的专家(如BPEL引擎)？

请告诉我你的意见。

Answer 1

是也不是。在编排和聚合/服务增强之间有一条薄薄的，有时是难以区分的界线。

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

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

不过，睡不着觉是不值得的

免责声明:我是IBM顾问，尽管我不是以官方身份编写这篇文章的。

Answer 2

不，ESB的责任不是服务的编排(本身)。ESB在“软件基础设施级别”提供了抽象层。

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

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

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

您通常在ESB中避免的业务流程是:为了处理此(保险)销售，我们首先需要验证买方提供的信息，然后我们需要承保保险风险，最后计算需要支付的保险费，然后我们需要…。等。

上面描述的步骤显然是一个业务流程(甚至可以中断…)。例如，如果不可能自动承保，那么人工承销商需要进一步评估风险)。

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

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

Answer 3

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

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

我不知道还能加什么:) .祝好运?