We have a client application that needs to send messages to a server for various notifications. In order that the client can run occasionally connected I'm going to go with a message-queue approach. The queue processing will take messages off the queue and call a web service that will put them on another queue to finally be processed. This question is about the client environment; the server environment is already decided on.
I don't want to use MSMQ because we don't have control over all the client PCs in order to install/configure and secure MSMQ properly, and because support is more challenging due to the quality of tooling for investigating the contents of MSMQ queues. SQL Server 2005 Express is on all the machines, and is used to store data for our application.
I currently have it down to two options:
ThreadPool.QueueUserWorkItem
to have them processed by handlers configured against each message type. All in a System.Transactions.TransactionScope
so they are only removed from the persistent queue if they are successfully processed.I have little experience with service buses (I still don't really get service bus terminology) so I'm concerned about the learning curve compared to writing something much more simple that meets my requirements in the way I need it to (deployment is a big consideration).
Does anyone have any thoughts?
How Azure Service Bus Queue is used? Service Bus Queue primarily helps in load balancing of system level messages. It provides pull-based messaging services that temporary stores message in queue so that the destination / consuming system can process messages at its own pace / average processing.
Azure Service Bus is a fully managed enterprise message broker with message queues and publish-subscribe topics (in a namespace). Service Bus is used to decouple applications and services from each other, providing the following benefits: Load-balancing work across competing workers.
One of the patterns easily supported by the Azure Service Bus is the 'first-in-first-out' (FIFO) pattern – which isn't supported in the other queue service – Azure Storage Queues.
If your requirements are simple, if you want to send each message to only one destination, or if you want to write code as quickly as possible, a storage queue may be the best option. Otherwise, Service Bus queues provide many more options and flexibility.
Well, I don't know that I'm going to suggest MSMQ, but I will suggest that there's a lot of edge cases to think about for 'roll your own'.
Even with a thread pool approach, be aware that there may be ordering issues if you care - two items posted sequentially to thread pools may not be executed in order, due to how the thread pools handle work items.
You'll also need to think about persistence of messages, and how long they should exist, how to detect 'fatal' non-delivery status, and what to do in that case.
There's also a number of potential edge cases in scenarios where your app goes down around the same time as it's queueing a message - for instance, it may not get the acknowledgement that the message was queued, even though it was. Yes, you can ack the queue acknowledgement, but you can endlessly get into ack circles...
Why not just have the app detect when it gets connected, and send all the data at that point?
Having written our own service bus I can tell you it's not a trivial undertaking and you will run into the same edge cases that all other implementers have already run into. kyoryu brings up two very important ones.
Whether you roll your own also depends on the skills you have in-house and will have in the future to maintain the solution.
Another consideration is the eventual scale of the system and it's reliability requirements. Will the in-house solution scale sufficiently?
Our peer-to-peer message bus, Zebus, based on ZeroMq (transport), Cassandra (peer discovery and persistence) and Protobuf (serialisation).
It is open source and production tested https://github.com/Abc-Arbitrage/Zebus
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With