Added MSMQ Features
As I have shown thus far, MSMQ provides the basic high-level requirements of a MQM tool. MSMQ, though, also contains several extra features. Two features worth mentioning are the message acknowledgements and message journaling.
When a message is sent, the developer can request a message acknowledgement when the receiving computer receives the message. Message acknowledgements are sent like regular MSMQ messages ("Optimizing Windows NT Server Performance in a Microsoft Message Queue Server Environment"). One might think that MSMQ acknowledgement messages could be sent in a straightforward, sockets-like way, without needed to undergo the overhead of sending a simple acknowledgement in the bulky MSMQ message format. However, since MQM tools need to work on volatile networks, ones that commonly have disconnected computer sources, the following situation (among many others) would require acknowledgement messages to be send in the MSMQ message format:
- Computer X wants to send a message M to Computer Y, requesting an acknowledge message A from Computer X upon receiving message M.
- A direct connection between Computer X and Computer Y is down or not available. Therefore, Computer X forwards the message information to an intermediate computer (Computer Z) that has a direct connection with Computer Y.
- Computer Y, however, is currently off-line. The message is held at Computer Z until Computer Y comes back on-line, at which time the message is sent to Computer Y.
- Sometime later, when Computer Y comes back on-line and receives the message, an acknowledgement message is prepared to be sent to Computer X.
Pause for a moment and consider what would happen if Computer Y attempted to send a socket-like message to Computer X. While this might succeed most of the time, what if, at this time, Computer X was off-line? Or what if, due to security measures, Computer Y couldn't directly connect with Computer X? As this paper has shown, MQM tools are designed to overcome these concerns. Therefore, it makes perfect sense to send the acknowledgement messages in MSMQ format.
Since MSMQ messages are loosely coupled, asynchronous, and can work over volatile networks, a message acknowledgement may take several minutes, hours, or days. In a tightly coupled message delivery system, the computer sending a message would wait for an acknowledgement until continuing to process. It is, of course, ridiculous to assume an MSMQ application to wait for an acknowledgement. Acknowledgements, therefore, solve as more of an after the fact reassurance.
Another communication assurance provided by MSMQ is message journaling, which provides a detailed report of message communication for message auditing purposes. By default, MSMQ does not save a copy of each message on each machine. That is, if Computer A needs to send a message to Computer B, which will then forward the message on to Computer C, once Computer A successfully sends its message to Computer B, traces of the message on Computer A are removed. Likewise, when Computer B successfully sends the message to Computer C, the messages traces are removed from Computer C. Finally, when the distributed application instance running on Computer C picks up the message from the queue, traces of the message are removed from Computer C.
When message journaling is enabled, however, a copy of each message is stored at computer instead of being removed. This, of course, leads to decreased performance and an increase in needed disk space, but provides for a detailed list of all messages sent and received by all of the computers participating in the distributed application. Therefore, message journaling provides for a detailed message auditing system, which is imperative for certain applications where message delivery paths and message accountability is paramount.
Using the Right Tool for the Right Job
MSMQ is not the tool of choice for all distributed applications. MSMQ fits in well into distributed applications that require loosely coupled, asynchronous communications. If communications are to occur over a volatile network, one with frequent network downtime or disconnected computers, MSMQ is a wise choice. However, there are several types of applications where MSMQ is not well suited.
Any distributed application that sends tightly coupled messages should stay as far away from MSMQ as possible. A distributed application that employed tightly coupled message passing would be one that required the sending computer to wait for an acknowledgement or message response from the receiving computer before continuing processing. Even if MSMQ is used on a non-volatile network, it still is much less efficient than more direct message passing methods (like Berkley sockets) since MSMQ adds a level of encapsulation between the distributed application and the message delivery protocol. Therefore, MSMQ is not an intelligent choice for distributed applications that use rightly coupled messages (Houston 8).
Furthermore, MSMQ is not well suited for distributed applications that require message delivery within a predefined amount of time. Such applications are one where "a response is needed within some period of time where the actual time period is usually 'business-policy related' and where the maximum time allowable is a business decision as opposed to a technical decision" (Houston 8). In these situations, MSMQ is not a desirable option. MSMQ was designed to assure message delivery over a volatile network, and was not engineered to deliver that message in a specific amount of time. Due to uncontrollable circumstances - such as failed network connections and off-line computers - message delivery can take an undetermined amount of time.
For distributed applications that need to send asynchronous, loosely coupled messages on the Windows family of operating systems, MSMQ is a powerful tool that assists the developer by taking responsibility for message delivery. MSMQ implements a store and forward mechanism using message queues, making MSMQ an ideal candidate for use over a volatile network.
For more information on MSMQ and other MQM tools, be sure to visit the following on-line reference centers:
- Message Queuing Overview and Resources.
- Messaging Middleware News and Analysis.
- IBM's MQSeries Information Site.
Blum, William. "Using Microsoft Message Queue Server." Retrieved April 3rd, 2000 from the World Wide Web: http://www.wdj.com/archive/0911/feature.html.
Gibbs, Mark. "Got a Message? Join the Queue." Network World. Retrieved on April 2nd, 2000 from the World Wide Web: http://www.nwfusion.com/archive/1999b/0607gearhead.html.
Houston, Peter. "Building Distributed Applications with Message Queuing Middleware." Retrieved April 1st, 2000 from the World Wide Web: http://www.microsoft.com/ntserver/appservice/deployment/planguide/msmqdistributed.asp.
IBM MQSeries Information Web Page. Retrieved March 22nd, 2000 from the World Wide Web: http://www-4.ibm.com/software/ts/mqseries/messaging/.
Message Queue Server Interoperability Web Page. Retrieved April 5th, 2000 from the World Wide Web: http://www.microsoft.com/NTServer/appservice/exec/features/MSMQ_Interop.asp.
"Message Queuing vs. E-mail." Retrieved April 6th, 2000 from the World Wide Web: http://msdn.microsoft.com/library/partbook/asp20/messagequeuingvsemail.htm.
MSMQ FAQ Web Page. Retrieved March 23rd, 2000 from the World Wide Web: http://www.microsoft.com/ntserver/support/faqs/msmqfaq.asp.
"Optimizing Windows NT Server Performance in a Microsoft Message Queue Server Environment." Retrieved April 6th, 2000 from the World Wide Web: http://www.microsoft.com/TechNet/winnt/msmqperf.asp.
Raj, Gopalan Suresh. "Microsoft Message Queue Server." Retrieved April 1st, 2000 from the World Wide Web: http://www.execpc.com/~gopalan/mts/msmq.html.
"Requesting Source Journaling." Retrieved April 7th, 2000 from the World Wide Web: http://msdn.microsoft.com/library/psdk/msmq/msmq_examples_api_0bqf.htm.
Singhal, Mukesh and Niranjan G. Shivaratri. Advanced Concepts in Operating Systems. McGraw-Hill: New York, 1994.