Responsibility of an ESB

Question

When using an enterprise service bus, is it responsible for;

a. the successful delivery of a message to a consuming application

b. to successfully deliver a message until the application's logic completes successfully (up to a retry threshold) ?

c. something else

With 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 ?

Answer 1

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 calls If 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.

Answer 2

It depends.

The point of a message passing architecture is that the sender doesn't care who receives the message, and while this means a fire-and-forget approach works very well, it isn't suitable for some situations where either guaranteed delivery is required, or a acknowledgement is received.

Fortunately the latter approach is very easy - the receiver simply sends off a message back to whoever sent it as needed. Note that in these cases, its the applications that care, the ESB should not need to know if a response is required by the sender or not, all it needs to do is provide a way for these services to send each other messages.

The guaranteed-delivery, that's a responsibility of the architecture. Some have 2 types of message, one that's guaranteed and one that's less resource intensive to track.