Message Queuing Middleware
Message Queue Middleware (MQM) is a class of developer tools for sending asynchronous, loosely coupled messages between computers (Houston 3). MQM does not move bits from one machine to another; it leaves that work to already defined standards, such as Berkley sockets. Rather, MQM tools provide an API for the developer (hence the term "Middleware").
As discussed earlier, MSMQ (which is a specific MQM tool) is a useful message passing mechanism for volatile networks and networks that often contain disconnected computers (such as laptops, PDAs, and computers that connect to a network through a dialup connection or RAS). For messages to be successfully maintained on a volatile network, MQM tools provide a message queue on each computer participating in the distributed application. This message queue allows for delayed messages: both delayed delivery from a sender and delayed pickup from a receiver. These queues allow for the distributed application to send an asynchronous message to a disconnected computer or over a faulty network. If the target computer has crashed or is off-line, the message is stored in a queue and becomes the responsibility of the MQM tool. The distributed application no longer needs to concern itself on whether or not the message was successfully delivered or not, or if the message needs to be resent (Houston 3,4).
By removing these tedious checks, the developer using an MQM tool no longer has to worry about communication failures, acknowledgements, or message resends. The developer simply informs the MQM tool to send a message and his concern ends there. From that point on, the message is in the hands of the MQM tool. Later, I will discuss what Microsoft Message Queue does with a message once it is queued and ready for delivery. For now, understand that MQM tools take responsibility for the transport of the message, removing failure concerns form the developer.
MQM tools also provide for communication between different platforms. Currently there are two major MQM tools: Microsoft's MSMQ and IBM's MQSeries. Since MQM tools have an open standard, these two implementations can communicate with one another, allowing machines using IBM's MQSeries to send and receive messages from machines using Microsoft Message Queue. Not surprisingly, MSMQ runs on Microsoft operating systems - Windows 95/98, Windows NT, and Windows 2000. IBM's MQSeries, however, runs on a plethora of platforms, including Windows NT, Windows 2000, OS/2, HP-UX, AIX, Solaris, and others (IBM MQSeries Information Web Page).
Since all MQM tools can communicate with one another, MQM tools can be written for new platforms and new operating systems that will work with existing MQM tools. Due to the open standards of MQM tools and the fact that MQM tools serve as a middle layer between the developer and the actual gritty work of sending a message, MQM tools promise cross-platform compatibility.
MQM tools are built using open standards, detailing both the low-level and high-level requirements needed for a development tool to be considered an MQM tool. All MQM tools must adhere to the following four high-level requirements. When reviewing these requirements, be sure to remember that the time a developer issues a send command and when the message is actually delivered can be minutes, hours, or even days apart (Houston 3):
1. When a developer issues a message send command, MQM tools must not require a simultaneous connection between the sender and receiver.
2. Communication between MQM tools should be platform independent.
3. MQM tools should provide reliable message passing. Message acknowledgements and stable storage can be used as they are in RPC mechanisms to ensure "At Most Once" semantics (Singhal and Shivaratri, 90).
4. MQM tools can translate and reformat messages en route.
These four high-level requirements ensure that all MQM tools have the same basic functionality. The next four sections detail the four high-level requirements for MQM tools.
One would expect connectionless communications to be a trivial concern in a corporate setting where computers are connected via a LAN or WAN. However, as the popularity of mobile computing devices - such as laptops, handhelds, and PDAs - has increased, oftentimes computer resources spend significant time disconnected from the corporate network. These mobile computing devices are often used to serve as a remote source of database information while employees are on business trips or sales calls. When the mobile computing device (and it's corresponding human owner) returns to the workplace, the database on the corporate network needs to synch up with the mobile device.
Creating an application that synched the database on the corporate network with mobile computing devices is a job Microsoft Message Queue is well suited for. In "Using Microsoft Message Queue Server," William Blum discusses a project he was involved with in which a centralized Microsoft SQL Server database needed to keep potentially disconnected computers up to date with any changes made. Blum feared that having to program a state of the art distributed message passing system that allowed for disconnected sources would push the project behind schedule. However, MSMQ came to the rescue, handling all of the low-level, nasty message passing details.
One of the requirements for this system was that each client be kept apprised of changes made to the database by other clients, even if workstations were taken off-line temporarily. I could see that this would call for some kind of store-and-forward functionality, and I was expecting it to be a real headache to try to analyze all the possible scenarios, write a store-and-forward subsystem, and test it. I was pretty sure I couldn't do it in the time allowed.
Fortunately, another solution turned up just in time. Microsoft had just come out with version 1.0 of their Message Queue Server (MSMQ), and it seemed to be just the ticket. (Blum)
Using MSMQ, the centralized database could send messages to all of the computers in the distributed application, not concerning itself with whether or not a particular computer source was connected to the network or not. MSMQ takes responsibility for eventually sending the messages to the disconnected sources. MSMQ does more than simply guarantee message delivery to disconnected computer sources. Blum notes:
I started reading up on MSMQ and found that it is loaded with functionality - far more than I needed for my application. What I needed was connectionless messaging, guaranteed delivery, and dynamic queues. But in addition to this, MSMQ provides prioritization, transactions, smart routing, security, and integration with non-NT systems. (Blum)
Some of these additional features of MSMQ will be discussed; however, keep in mind that this paper focuses on MSMQ's ability to virtually guarantee flawless communications between a volatile network.