Supporting Duplex and Unary Communication Patterns in a Handler


(Jimmy Zimmerman) #1

Looking to get a best practice for this particular scenario here from the experts. :slight_smile:

We’ve got a handler set up working in a dialog between an end user app (legacy MVC) and another backend system leveraging the nifty callbacks feature.The user clicks the button, message goes out, it processes, result information is returned to the replyTo queue, client code resumes the await, scenario continues in the controller. Easy peasy and life is good.

Let’s just call this particular code IFooCommand that has a corresponding IFooResponse message.

So the question’s come up about handler implementation that the caller may be expecting a reply and simultaneously supporting clients that don’t care (eventual is good enough). If the caller isn’t waiting for a reply the response message gets dumped in the error queue because there’s no one expecting the reply message and no handler’s in place.

Is there a clean way in a handler to know if Reply is expected or not by the caller to take the appropriate action?

Is it perhaps better to reveal the intention explicitly via two messages instead (IFooDialog/Response vs IFooCommand) and have the handler implement both? Flags? Other magic?

What’s the general consensus for this type of scenario?

For completeness we’re using

NServiceBus 6.2.0
Sql Transport 3.0.0
Castle integration 6.0.0
Callbacks 2.0.1
NHibernate integration 7.1.1


(Ramon Smits) #2

In most scenarios, when synchronous request/response as when performing queries from a UI you should try to avoid doing this using messaging. You should query the storage directly, messaging is not going to solve anything and only adds an additional layer of latency and transformation.

Asynchronous nonblocking request/response between different endpoint is very common and the response is not awaited by a UI and would even matter is the response comes back in an hour and would be a good candidate to use message based request/response.

If you send a request, then you would eventually always have a response why else would a caller send a request if it is not interested in the response? A request shouldn’t have side effects (conform to CQS).

Then there are commands, a command can result in an event, or even send another command, if a caller is not interested in the event then it wouldn’t subscribe to it. If the command processor then performs a publish the subscriber wouldn’t get an event message.

Then there are lots of not ideal world scenarios where you might want to indicate you want to receive a response. You could do this as you state via:

  • a different message type, or
  • a property on a message, or
  • setting a header value

These usually are often indicators that something isn’t right but can sometimes just not be avoided due to legacy reasons. Even then I would really try to differentiate between queries using request/response and command and pubsub and be clear about this in your messages.

Does this help?


(Ramon Smits) #3

Did the provided info help or do you still have any questions?