NServiceBus sending message to one endpoint and waiting for reply in another

Question

I'm using NServiceBus with RabbitMQ in my project. I have two services that don't know about each other and don't share anything. service1 publishes request messages to endpoint1 (queue1) and service2 listens to endpoint1 and publishes responses to endpoint2 (queue2). There are two questions:

How can service1 handle responses from service2 if service1 doesn't know the response message type but only expects some particular fields in the response message?
I want to create an async API method that sends a request to endpoint1 and waits for the response in endpoint2. Is it somehow possible at all? Also how can I ensure that the reply corresponds with the request? I expect something like:
```
public async Task<object> SendRequest(string str) {
   var request = new MyRequest(str);
   await endPoint1.Publish(request);
   var reply = await endPoint2.WaitingReply();
   return reply;
}
```

I will appreciate any help.

You could argue that if the two services are decoupled, an Request/Response is not the right pattern. You'll need to look into raising Events instead, which multiple endpoints can listen to and react. The event can be raised when sending the request, or when it is done processing (based on your logic). — Hadi Eskandari, Jun 30 '22 at 11:19

score 0 · Accepted Answer · answered Jul 01 '22 at 07:50

Whenever two things communicate, there is always a contract. When functions call each other the contract is the parameters that are required to call that function. With messaging the message is the contract. The coupling is towards the message, not the sender or receiver.
I'm not really sure what you're trying to achieve? You mention an API which is async and endpoint1 and endpoint2.

First of all, there's asynchronous execution and asynchronous communication. The async part in your example code is asynchronous execution of two methods that have the word await in front of them. When we talk about sending messages, that's asynchronous communication. A message is put on the queue and then the code moves on and never looks back at the message. Even when you use the request/reply pattern, no code is actually waiting for a message.

^{You can wait for a message by blocking the thread, but I highly recommend you avoid that and not use the NServiceBus callback feature. If you think you have to, think again. If you still think so, read the red remarks on that page. If they can't convince you, contact Particular Software to have them explain another time why not. ;-)}

It could be that you need a reply message for whatever reason. If you build some website using SignalR (for example) and you want to inform the user on the website when a message returned and some work was completed, you can wait for a reply message. The result is that the website itself becomes an endpoint.

So if the website is EndpointA and it sends a message to EndpointB, it is possible to reply to that message. EndpointA would then also need a message handler for that message. If EndpointB first needs to send a message to EndpointC, which in turn responds to EndpointB and only then it replies back to EndpointA, NServiceBus can't easily help. Not because it's impossible, but because you probably need another solution. EndpointA should probably not be waiting for that many endpoints to reply, so many things could go "wrong" and take too much time.

If you're interested to see how replies work in combination with SignalR and what not, you can check a demo I built for a presentation that has that.

NServiceBus sending message to one endpoint and waiting for reply in another

1 Answers1