When using an enterprise service bus, is it responsible for; a. the successful delivery of a message to a consuming applicationb. to  successfully deliver a message until the application's logic completes successfully (up to a retry threshold) ?c. something elseWith RESTful calls, a request will always have a response and it's up to the client in how it should deal with it. With an ESB it's slightly different as such the client doesn't care about how other services are consuming its published messages.So if the client doesn't care if a consuming application throws an exception, should the ESB be concerned about the applications result that it is delivering the message to ?
Responsibility of an ESB
enterprise architecture;single responsibility;service bus
ESB:Reliable delivery of a message is the responsibility of the transport. Successful delivery can mean very different things depending on context, see Quality of Service (QoS) 1, 2, 3. An ESB in a Service Oriented Architecture is normally responsible for routing and transformation as well as value add options such as monitoring, auditing etc. RESTful calls:A REST call should be an action on an object. It shouldn't take that long to complete and normally would be able to do the processing and return a HTTP response before it was a problem. Async callsIf you really need to send off an asynchronous message once a HTTP request comes in because the action takes a long time, then you are not going to be able to wait for the response. In this case it's not really the responsibility of your ESB to do something about it. You are really going to have to decide how your program deals with this. Your ESB may be able to help you with this, for example by coordinating a global transaction for you. If you have already replied to your HTTP requestor that the action has been taken in hand, just as an MQTT client is responsible for the message once it has acknowledge the message status with the server to the specified level of QoS, you need to treat this process failing as a failing transaction and either undo everything that happened or compensate for things that can't be rolled back. The originator then needs to be coded with the assumption of the same behaviour and know that it needs to check up on what really happened or inform the client. 