Platform-Independent Communication Part of the challenge of creating distributed applications is having the application work on various platforms and operating systems. In many large corporate settings, a major database may be located on an antiquated main frame, while the various employees use workstations and personal computers. Creating a message passing system that operates seamlessly with the numerous platforms and operating systems poses a great challenge.
Since MQM tools serve as a middleware between the developer's application and the actual sending and receiving of messages, the developer does not need to concern himself with creating a message passing system that works with the assorted platforms and operating systems. That responsibility is removed from the developer and placed squarely on the shoulders of the MQM tool.
While MSMQ is only supported by a limited number of operating systems - those in the Windows family - MSMQ can communicate with IBM's MQM tool, MQSeries (Message Queue Server Interoperability Web Page). Fortunately, MQSeries is interoperable with a much larger set of platforms and operating systems, including Windows NT, Windows 2000, OS/2, HP-UX, AIX, Solaris, and others (IBM MQSeries Information Web Page). Due to MSMQ's ability to communicate with MQSeries, through transitivity Windows applications using MSMQ can effortlessly send messages to non-Wintel computers.
Reliable Message Passing
Network errors are bound to happen; messages will be lost; packets will be dropped. In a local area network the occurrence of network errors is relatively low. However, in certain applications it is absolutely essential that messages be delivered. For example, stockbrokers must be certain that their stock order messages are successfully delivered (Houston 5). Duplicate messages or lost stock order messages can result in losses of millions of dollars. Also, in wide area networks or distributed applications that run over the Internet, message loss is a very real concern.
When discussing remote procedure call conventions in class, an "At Most Once" semantic was discussed. With the "At Most Once" RPC semantic, the remote procedure, upon success, was executed exactly one time. Upon failure, the remote procedure was not run at all. This all or nothing semantic is used commonly for transactions and actions in which duplicate or partial executions can wreck havoc.
MQM tools must provide such a semantic. In most distributed applications where all of the participating machines are connected concurrently, if a machine crashes or disconnects, the RPC call will fail. The machine that issued the RPC call will fret about since it is unable to communicate with the disconnected server that houses the remote procedure it is interested in. MQM tools, on the other hand, are much more laid back, and don't get worked up over unavailable computer resources. If an MQM tool attempts to send a message to a computer that is unreachable (either because it crashed or has been disconnected from the network), the MQM tool will play it cool, storing the message in a queue and sending it at some later time (Raj).
Later in this paper I will discuss the algorithms employed by MSMQ to ensure that messages are reliably sent.
Translating and Reformatting Messages En Route
Since MQM tools are designed to work on volatile networks, some mechanism needs to be provided to reroute messages that are currently on a course with network outages or failures. For example, imagine a wide area network consisting of three points of communication. Each point of communication is the entry/exit point for a LAN in a prestigious computer science university. Such a network scenario can be seen in the figure below:
If a computer on the Rolla LAN needs to send a message to the MIT LAN, but the network connection between Rolla and MIT is down, the MQM tool will attempt to send the message from Rolla to MIT through the Berkley LAN. If the Rolla to Berkley connection is available, but the Berkley to MIT connection is unavailable, the message from Rolla to MIT will be stored in the Berkley message queue, and will be sent to MIT once the communication channel between Berkley and MIT is restored. On the other hand, if the Rolla to Berkley connection is down (as well as the Rolla to MIT connection), the message will be stored in the Rolla message queue, delivered to MIT or Berkley whenever the network connection is restored (Houston 5).
Since the destination information for a message is embedded within the message headers, it is imperative that messages can be modified en route. While it's hard to see this in the three-node example given above, by adding a fourth node it becomes clear why messages need to be modified in transit. Imagine that a fourth node existed that was connected only to the Rolla LAN. If this fourth node wanted to send a message to the MIT LAN, first it would need to send it to the Rolla LAN. Depending on network failures, the message might not be able to be sent from Rolla directly to MIT. At this point, the MQM tool on the Rolla LAN would need to be able to modify the intermediate destination of the message, sending it to Berkley first.
With MSMQ the network administrator can outline what network paths a message should consider taking. Furthermore, the network administrator can assign costs to these various network paths (MSMQ FAQ Web Page). From the allowable network paths assigned by the network administrator, MSMQ determines what paths are up and running. Then, from this subset of possible network paths, MSMQ chooses the one with the lowest cost, and routes the message down that path (MSMQ FAQ Web Page).