MSMQ's Technical Details
Since Microsoft Message Queue is an MQM tool, it must abide by the four high-level standards detailed earlier in this paper. So far, only the high-level requirements have been discussed, and the specifics of MSMQ have been left relatively untouched. In the remainder of this paper, however, I will examine how MSMQ implements the necessary MQM tool requirements.
Maintaining Connectionless Communications Through Queues
Recall that MQM tools must provide for guaranteed delivery of messages in a volatile network, a network that may contain disconnected computers, for example. When using sockets, one can attempt to connect to a site and send a message. However, if the site is not on-line at the time (or has crashed), the socket will time out. Of course, the developer could resend the socket after a short pause. However, when dealing with disconnected sources, the disconnected computer may be unavailable for hours, days, or even weeks. Continually attempting to resend a socket is burdensome and inefficient.
MSMQ, as other MQM tools, creates a message queue on all of the machines participating in the distributed application. When a site attempts to send a message, the message is first moved into the sender's message queue. If the network is up and the receiving machine is on-line, the message is transported from the sender's message queue to the receiver's message queue on the best possible network path (MSMQ FAQ Web Page).
Once the receiving computer obtains the message from the sender, it places it in its message queue, awaiting pickup. The distributed application instance running on the receiving machine can occasionally check the queue to determine if there are any received messages. Furthermore, with MSMQ, the sending machine can request an acknowledgement message to be returned when the receiving computer accepts the message in its queue ("Optimizing Windows NT Server Performance in a Microsoft Message Queue Server Environment").
By using a message queue, MSMQ allows for asynchronous, loosely coupled, connectionless communications. While MQM tools are referred to as Message Queue Middleware, MQM tools are not required to use queues - they are only required to adhere to the four high-level guidelines discussed earlier. However, the two prominent MQM tools (MSMQ and MQSeries) both use queues since they make for an easy implementation.
Platform-Independent Communication with MSMQ
Unfortunately, MSMQ only works on Windows based operating systems (Gibbs). Of course MSMQ must be capable of platform independent communication to be considered a true MQM tool. MSMQ claims it is capable of such communication due to its ability to communicate with the other major MQM tool, IBM's MQSeries. Fortunately, MQSeries is truly platform independent, working on a wide range of popular platforms and operating systems (IBM MQSeries Information Web Page).
MSMQ supports both the IPX and TCP/IP networking protocols (MSMQ FAQ Web Page). Since TCP/IP is a standard networking protocol, and since MQM tools send messages in a standard format, MSMQ can communicate with MQSeries. Specifically, MSMQ communicates with MQSeries via the MSMQ-MQSeries Communication Bridge, a component created by Level 8 Systems (Message Queue Server Interoperability Web Page).
Reliable Message Passing with MSMQ
One of the responsibilities of a MQM tool is to provide reliable message passing. The developer shouldn't have to concern himself with ensuring that a message is successfully sent and accepted by a particular machine. Rather, the developer should be able to simply be able to instruct the MQM tool that he wants to send a message to a particular computer and then continue on with processing, not worrying about delivery specifics or delivery problems. A successfully delivered message is received and processed only once while a failed delivery message is not processed at all. This type of message passing semantic is known as the "At Most Once" message passing semantic (Singhal and Shivaratri, 90).
Since an "At Most Once" semantic adds considerable overhead to the message delivery system, MSMQ offers developers the choice of sending three different types of messages. These three types of messages each provide a different tradeoff between message reliability and message delivery performance. The three types of MSMQ messages include (Gibbs):
- Express message.
- Recoverable message.
- Transactional message.
Express messages, as its name implies, are designed for maximum transfer performance. Message details for express messages are stored solely in memory for fast access ("Message Queuing vs. E-mail"). Of course this can lead to lost messages if the sending, receiving, or transient computer crashes.
Recoverable messages are stored on stable storage, ensuring that if a computer crashes, the message is not lost. Of course using recoverable messages have more overhead than express messages, since as each sent message is routed from the sender to the receiver, the message must be written to disk as opposed to memory. The advantage, of course, is that computer crashes will not result in lost messages (Gibbs).
Neither express messages nor recoverable messages use detailed logging to stable storage to determine whether or not the receiving computer has received the message. Therefore, both the express messages and recoverable messages are susceptible to being sent more than once to a receiving machine in the event of a computer crash (Gibbs). Due to this susceptibility to duplicate messages, express messages and recoverable message both conform to the "At Least Once" semantic. With the "At Least Once" semantic, a message is considered successfully delivered if the receiving machine receives and process the message at least one time. The message delivery is considered a failure if the receiving machine does not process or only partially processes the sent message (Singhal and Shivaratri, 90).
MSMQ provides for "At Most Once" semantics with transactional messages. For the cost of decreased message delivery performance, "transactional messages add transactional integrity and uniqueness as well as support for updates to other resources" (Gibbs). Transactional messages use detailed stable storage logging on both the sending and receiving computers to ensure an "At Most Once" semantic.