ESB的责任

Question

使用企业服务总线时，是否负责；

成功地将消息传递给消费应用程序b.成功地传递消息直到应用程序的逻辑成功完成(直到重试阈值)？c.其他事情

使用RESTful调用，请求总是有一个响应，如何处理它取决于客户端。对于ESB，它略有不同，因为客户机并不关心其他服务如何使用其发布的消息。

因此，如果客户端不关心消费应用程序是否抛出异常，ESB是否应该关注它向其传递消息的应用程序结果？

Answer 1

ESB:可靠的消息传递是传输的责任。成功的交付可能意味着非常不同的事情，取决于上下文，参见服务质量(QoS) 1、2、3。面向服务的体系结构中的ESB通常负责路由和转换以及诸如监视、审计等增值选项。

RESTful调用: REST调用应该是对对象的操作。它不应该花那么长时间来完成，并且通常能够在出现问题之前完成处理并返回HTTP响应。

异步调用--如果您真的需要在HTTP请求传入时发送异步消息，因为该操作需要很长时间，那么您将无法等待响应。在这种情况下，ESB并不真正有责任对它做些什么。你真的要决定你的程序如何处理这个问题。您的ESB可能会在这方面帮助您，例如，通过为您协调全局事务。如果您已经回复您的HTTP请求者已经执行了该操作，就像MQTT客户端在将消息状态与服务器确认为指定级别的QoS后负责消息一样，您需要将此进程视为失败的事务，或者撤消所有发生的事件，或者补偿无法回滚的事情。然后，发端者需要用相同行为的假设进行编码，并知道它需要检查到底发生了什么，或者通知客户。

Answer 2

那得看情况。

消息传递体系结构的要点是，发送方不关心谁接收消息，虽然这意味着触发和遗忘方法工作得很好，但它不适合于需要保证传递或接收确认的某些情况。

幸运的是，后一种方法非常容易--接收者只需将一条消息发送回发送者。注意，在这些情况下，它是关心的应用程序，ESB不应该需要知道发送方是否需要响应，它所需要做的就是为这些服务相互发送消息提供一种方式。

保证交付，这是架构的责任。有些有两种类型的消息，一种是有保证的，另一种是不需要跟踪的资源密集型的。