Hi All,
So I am at the start of my journey to use NSB. I am provisioning a system that provisions servers, so the high level flow is request a server (i.e. provide a Sku), and then get the server back (username, password, ip etc).
I will need a reply in my messages, which means full duplex pattern. I was looking at some examples of this.
I would assume the interface IHandleMessages can go on my controllers (The type in angular brackets will be different of course).
I am a little bit confused about the purpose of events and commands now. Events would indicate something is done, i.e. server provisioned, and I was thinking of using that to return relevant data. So what is the use case for that?
Also, a little confused about exception handling. For example. I am using the ProblemDetails standard for business domain exceptions. In a the recieving handler, I can catch these as per normal but should I include an Exception object in my reply message to send back to the reciever? Is this correct?
What do you mean with controllers here? Like webapi controllers? That is not recommended.
Based on 1 and 2 you want to do request/response in a blocking manner and second it seems that you want to do a query.
Our recommendation is to not query over messaging. Just query a data store directly. Messaging just adds layers, thus overhead. Not saying it should never be done as that always depends and I don’t have the context of your system and the requirements.
Events have 0, or more subscribers. These should often represent state changes like OrderAccepted, PaymentSuccesfull, etc.
These should not be used for request/response. Sometimes we see users do request/response via event messages but that is often a design smell. A request often has a single logical destination and the response has exactly 1 receiver. There can be exceptions like for example doing a type of scatter/gather but its difficult to use events for that for as how NServiceBus deals with its event message type.
This also seems to imply that you want to do blocking request/response where the response would be received within a short time window of lets say 200ms. Now imaging that this would take seconds of minutes as that potentially could happen when using messaging.
Exceptions should usually not be dealt with by the sender unless they contain functional data.
For example, an exception like “dead lock” or timeout should never reach that sender. Retries should automatically resolve such issues most of the time but an exception like “payment rejected” actually isn’t an exception its an expected result that can result in an alternative flow or compensating action.
In that case that is a functional error and should be converted in a response to which the sender can react.
The question is, would you actually want to “wait” on that?
That is where sagas can be useful to orchestrate such long lived processes
So by query you mean if for example I ask for all servers of a specific type, that call should be direct to data store? That is fine and makes sense. By controllers I was thinking API controllers in ASP.NET Core, but I have made dedicated classes. I guess when an action is happening, like requesting a server, then messaging is fine.
On the second point around messages, am I on the right track by defining messages for request and reply? I think the example I saw and downloaded had this. By messages I mean inheriting from : IMessage
One more point, my handler is a windows service. This handler will be responsible for server operations, like delete, provision, modify etc. This will be for a few platforms. I want to use/have one windows service only that can handle all the calls. So I guess I will need handlers with the correct types/interfaces.