May not be "best practice" advice here... but based on real life needs and experience:
we have distributed system, 60 boxes running each 10 clients all do task X, and they need to take the next task from a queue. The queue is being fed from one other "client"...
We had used inter process communication, we used MSMQ, we tried service broker... It just doesn't work in the long term because you are giving away the control of your application to Microsoft. It works great as long as your needs are satisfied. it becomes hell when you need something not supported.
The best solution for us was: Use a SQL Database table as the queue. Don't reinvent the wheel there, since you will make mistakes (locks). There is info out there on how to do it, it is very easy and we handled over 200K messages per 24H (with 60x10 = 600 concurrent reads and writes to the queue). That is in addition to the same SQL server handling the rest of the application stuff...
Some reasons why MSMQ doesn't work:
When you need to change the logic of the queue to not FIFO, but something like "the oldest RED message" or "the oldest BLUE message" you can't do it. (I know what people will say, you can do it by having a red queue and a blue queue.. .But what if the number/types of queues is dynamic based on the way the application is administrated and changes daily?)
It adds a point of failure and deployment nightmare (the queue is a point of failure and you need to deal with setting the right permissions on all boxes to read/write messages etc' in Enterprise software you pay in blood for these type of things). SQL server... all clients are writing/reading already from the DB, it is just one more table..
