I am just starting with Service Broker and looking at the examples in blogs, most have a sending and receiving service with separate queues.
Looking at the SEND TO command (to send a message) I need to reference a CONVERSATION. And it seems that a CONVERSATION has FROM SERVICE and TO SERVICE parameters.
Is it wrong or bad design to send from/to the same service, with a single queue? I tried it and it seems to work.
My SQL table will have code in a trigger to send a simple empty message. This will notify a SignalR client that the table has changed, and send out new data. For such an application, surely a single queue and single service is okay?
Best Answer
You do not have to, but is a good practice.
You must be aware that your 'from' service will also get messages in it's queue, even if you never send any. There are system messages, most obvious ones being the EndDialog and Error messages. You have to handle at least those. So your code that services the queue must be able to properly handle the messages sent to the initiator (the 'from' service). With a single queue for both services you will get a mix of messages, some for initiator some for target.
Make sure you do not do Fire and Forget, read How to prevent conversation endpoint leaks to understand why is important.