Message Queuing--It's a Good Thing.. Loosely coupled asynchronous web-services architectures based on message queuing not only offer improved reliability, they also allow you to handle high burst loads with less hardware and software. Here's an example of a web service that receives burst request loads of 150tps (when sampled each second) during the early-afternoon hours. But when front-ended with a messaging system (i.e., a huge buffer) the load can be handled by an application server and database that are only configured to process 50tps steady state. Even at the busiest time of day, this configuration never gets more than 30 seconds behind, which is well within the design criteria for the application. (Of course you could never do this with synchronous RPC-style web services.)
 When averaged over 24 hours, the load for this web service is only 25tps (2.1 million transactions per day). If an 8-hour lag in message-queue processing were acceptable (as it is for some applications), a single 25tps application configuration could handle the whole thing. [Web Services Strategies]
A good argument for the use of asynchronous processing and the use of MOM in your middle tier and to communicate with your back end services and partners. Especially true if throughput is much more important than latency which is often the case in the back end.
For UI centric things like web applications and rich clients, or in RPC services like Servlet engines often having a low latency is important to make efficient use of hardware and give responsiveness to clients. In this case caching of information can really help reduce latency and improve the user experience.
10:25:51 AM 
|
