With Microsoft Message Queue Server (MSMQ), your application can communicate with other application programs by sending and receiving asynchronous messages. This is generally known as queuing. Queuing provides a very useful architectural design strategy, especially if your application must provide stable, reliable performance.
In order to understand the performance benefits of queuing, it is important to understand the basic differences between synchronous and asynchronous styles of communication.
Most distributed applications today use synchronous communication (such as remote procedure calls) and do not use queuing. Communications are synchronous (not queued) when the sender of a request must wait for a response from the receiver of the request before it can proceed on to performing other tasks. The time that the sender must wait is completely dependent on the time it takes for the receiver to process the request and return a response. It's acceptable to use synchronous communication for workgroup applications if you're willing to supply adequate hardware to handle the workload. Remember, though, that a large peak workload can require a lot of hardware. One of the limitations of the synchronous approach is the overhead involved in starting the server objects. When a client is done with a service, the server object is destroyed.
With asynchronous communication (queuing), senders make requests to receivers and then immediately move on to other tasks. There is no guarantee that receivers will process requests within any particular period of time, but good real time responsiveness can usually be achieved in all but peak load conditions.
Queuing gives developers another set of design options, including the following:
Without queuing, when a burst of requests comes in the object pool starts growing, the objects can't recycle fast enough, and the new object allocations rapidly degrade the server computer's ability to do work. Without queuing, you must have sufficient memory on the server computer to deal with the absolute peak load, which is often many times more than the memory needed for normal processing loads.
A better answer is to put a queue in front of your objects. That way, even though the queue may get big, the resources that are actually using memory and threads are optimal for the server computer. The queue manager helps to allocate the work so that the server computer can operate using just the right number object resources.
The choice to use queuing has another particular advantage: if the receiver is not running at the same time as the client, synchronous communication attempts will always fail; asynchronous communications can still succeed.
Because the queue manager maintains its queue internally, client requests are never refused. If all pre-allocated services are busy, the queue manager simply waits until one becomes available and assigns it to the next waiting client in turn. In distributed solutions, such a queue can be used to keep services busy. This results in servers running at their optimum performance level — that is, fully loaded.
It should be noted that queuing does impose some processing overhead. Remember, though, that if your application must handle a widely variable number of clients, and the server computer imposes certain resource limits, and then queuing will allow the maximum number of users to access your application with only a slight reduction in performance.
The performance value of queuing is that it allows your hardware to work at capacity without mismanagement or inefficient use. A side benefit of queuing is that, during peak workloads, the application's throughput degrades gracefully. Queuing is an important design concept required for high-performance, robust applications.
With MSMQ, application developers can include queuing operations with transactional units of work that access other recoverable resources (such as databases). MSMQ operations can commit or abort in coordination with other resources in the transaction to preserve data integrity. For example, if an application updates a database and sends a message to another application within a transaction, any abort condition will cause the database updates to roll back. MSMQ will also roll back by canceling the send operation. MSMQ never completes the send operation until transactions commit. This prevents receivers from getting messages from transactions that subsequently aborted.
MSMQ takes similar actions when receive operations occur within a transaction. If the transaction aborts, MSMQ rolls back the receive operation by putting the received message back in its queue. This message becomes available for receipt by subsequent transactions. MSMQ's transactional features are important because many types of problems will occur if abort logic does not include queue operations. For example, if a receive operation does not roll back when associated database operations are rolled back, the message effectively becomes lost because no database processing occurs.
For More Information Microsoft Message Queue Server (MSMQ) is available in the Windows NT Service Pack 4. For more information on installing and using Microsoft Message Queue Server, see http://www.microsoft.com/ntserver/guide/msmq.asp.