When, where & how should queues be used?

I'm new to enter开发者_Python百科prise Java development, although I'm sure this question equally applies to any language or platform, such as .NET.

For the first time ever now I'm dealing with message queues, and I'm very intrigued by them. (specifically, we're using ActiveMQ). My tech lead wants ActiveMQ queues to be the front-runners to all of our databases and internal web services; thus instead of a database query being fired off from the client and going directly to the database, it gets queued up first.

My question is this: are queues the way to go with every major processing component? Do best practices dictate putting them in front of system components that usually get hit with large amounts of requests? Are there situations where queues should not be used?

Thanks for any insight here!

Here are some examples where a message queue might be useful.

Limited resources
Lets say you have a large number of users making requests to a service. If the service can only handle a small number of requests concurrently then you might use a queue as a buffer.

Service decoupling
A key enterprise integration concept is decoupling of systems in for eg a workflow. Instead of having systems talk directly to each other, they asyncronously post messages to queues. The integration component then routes and delivers the message to the appropriate system.

Message replay
In the above example queues can also provide reliable delivery and processing of requests. If one component of the workflow breaks, others are unaffected and can still operate and post messages to the broken component. When the broken component recovers it can process all the queued up messages.

They key concepts here are load throttling, loose coupling, reliability and async operation.

As to whether they are the way to go for every major component, I would say no, this is not an automatic choice, you must consider each component individually.

Queues are indeed a very powerful and useful tool, but like every tool you should only use it for the job it is intended.

IMO they are not the away to go for every major processing component.

As a general rule I would use a queue where the requesting resource does not require an immediate, synchronous response. I would not use a queue where the timeliness and order of processing is vital.

Where asynchronous processing is allowable and you wish to regulate the amount of traffic to a service then a queue may be the way to go.

See @Qwerky's answer too, he (or she) makes some good points.

Please check out this:

http://code.google.com/p/disruptor/

Not only queues are there in the wild to solve those kind of problems.

Answering your question. Queues in this case will introduce asynchronous behavior in access to your databases. In this case it is more a question of can you afford such a great impact on your legacy systems. It just might be too much of change to push everything to the queues. Please describe what is the general purpose of your systems. Then it will be easer to answer your question fully.

Message queues are fundamentally an asynchronous communication system. In this case, it means that aside from the queue that links the sender and receiver, both sender and receiver operate independently; a receiver of a message does not (and should not) require interaction with the sender. Similarly, a sender of a message does not (and should not) require interaction with receiver.

If the sender needs to wait for the result of processing a message, then a message queue may not be a good solution, as this would force an asynchronous system to be synchronous, against the core design. It might be possible to construct a synchronous communication system on top of a message queue, but the fundamental asynchronous nature of a message queue would make this conversion awkward.