Full Duplex implementation and context

Reference is made to the Full Duplex example

As I understand it now, FD can be an important pattern to make our integration landscape much more robust, but I have some questions on how and when to implement it.

I have the following questions (to start wth :wink: )

In general: How can de requester connect the reply from the replier to the context of the request? Is there an example available that explains this?

As I understand it, FD is an async message-based alternative to synchronous api calls? Correct?
Is its uses intended for simple querying only or can it also be used for interacting with a more complex microservice as replier?
If so, how would the replier return http-like responses like 4x and 5x when using messages as reply?

Your advice will be much appreciated!

Frank Nesse

Welcome to the Particular discussion group, @fnesse.

Not necessarily. The full duplex sample is a request/response or request/reply kind of pattern; the only relationship with synchronous API calls is that some information goes to a destination, and something comes back, but not necessarily to the original requestor. If the requestor is scaled out into multiple instances the response might be handled by a different instance to the one where the request originated.

NServiceBus Callbacks are more aligned with synchronous API calls in the sense that the reply goes where the requested originated and the context is kept. However, callbacks are designed for the specific use case of gradually evolving existing systems that do not use messaging in message-based systems.

Due to their fire-and-forget nature, messages should never be used to “query” data. A synchronous request (HTTP or gRPC) to a remote API is a better approach for queries. When using messages, you model failures by defining specific messages representing those failures. I wrote an article on the topic a while ago.

If you want to correlate responses to requests, a better choice would be to use sagas. Sagas are stateful and persist state. When a saga sends a request, the response is automatically correlated back to that specific saga instance. More information about sagas is in our documentation.

I could guide you towards a better solution if you could provide more details about what you’re trying to achieve.

HTH
.m

Thanks Mauro, for your welcome :slight_smile: and your extensive replies. Much appreciated!
In the meantime I found out indeed that a saga is the approach to automatically correlate a reply to the context of the request. I was a bit confused from the Full Duplex example that I a used as a starting point, for two reasons

  1. It does not show how correlation is done, while this obviously is an essential part in request reply patterns.
  2. The example gave me impression that its use is intended for querying (Submitting a Data Guid in the request, having some value returned in te response), while I am actually looking for a way to build robust and reliable (micro)services.

Perhaps it is an idea to have the FD example extended with a saga to show how correlation and explain the use-case a little bit better?

I really appreciate the concept of messaging in general and NServiceBus in ‘particular’ ;-). I am quite familiar already with events (IEvent) and commands (ICommand), but I have never actually looked into async/message based request-reply (IMessage). In my opinion this may be essential when building robust and reliable microservices. This is what I am investigating now.

Hi @fnesse

Perhaps it is an idea to have the FD example extended with a saga to show how correlation and explain the use-case a little bit better?

@mauroservienti added a new hint to the full duplex sample at the top that hopefully covers that feedback

Thanks for your input

Regards,
Daniel

Ah nice, my first ever (indirect) contribution to the NServiceBus docs :slight_smile:

2 Likes