MSMQ with queueing and business rules

We need to add a message queueing system with business rules to a .NET application. A typical scenario is a person requests "A" from an Internet site, the process checks information about that user, and based on that, the request gets routed to a queue in an internal intrane开发者_运维问答t site where someone manually processes the information.

The process is asynchronous, and the rules to determine which queue it would go into needs to be somewhat flexible. I was thinking of MSMQ but not sure how the queues and business rules would interact.

So, is it worth it to use MSMQ, or to just use standard database tables and roll our own? Thanks.

Related:

Rules of thumb regarding Messaging / Message Queueing

Good Strategy for Message Queuing?

to MSMQ or not to MSMQ? (or SQL Table as the Queue)

---

The considerations for using MSMQ (or indeed any other message queuing) are many and varied. However, some of the more common reason to use queues:

1. You need guaranteed delivery of data
2. You want to decouple dependencies that applications have on each other
3. You need a high availability transport mechanism

I would recommend using MSMQ above all other transport mechanisms in almost every situation (provided all the machines in your production setup are windows). The reason for this is that you get all the benefits listed above for free, and the overhead and development costs are comparable to the alternatives.

---

MSMQ is nice but if you don't absolutely need the routing capabilities (different protocols, different networks etc.) then I would definitely go with the SQL Table approach... Although I would use for inserting/updating etc. Stored Procedures... and for reading a View... this way you could even keep the business rules flexible... this approach leaves it up to you how much of the business rules you put into the DB and how much in your WCF/webservice/app etc.