When you think ASP, think...
Recent Articles
All Articles
ASP.NET Articles
ASPFAQs.com
Message Board
Related Web Technologies
User Tips!
Coding Tips

Sections:
Sample Chapters
Commonly Asked Message Board Questions
JavaScript Tutorials
MSDN Communities Hub
Official Docs
Security
Stump the SQL Guru!
XML Info
Information:
Feedback
Author an Article
ASP ASP.NET ASP FAQs Message Board Feedback
Print this page.
Published: Thursday, April 13, 2000

Microsoft Message Queue - An Overview


Caveat: this is a term paper for a senior/graduate level computer science class. While the term paper focuses primarily on a high-level discussion of MSMQ, it does make reference to particular distributed algorithms and concepts.

- continued -

Introduction
When discussing a distributed application or algorithm, it is often assumed that all of the sites participating in the algorithm are connected to one another via a network and that communication channels are flawless. Most algorithms, therefore, can be implemented using Berkley sockets. Socket communication is very flexible, providing for point-to-point communication using a client-server model. One assumption a developer must make when using sockets, though, is that both the sender and receiver are able to communicate with one another instantly, connected by some network. Another assumption one makes when using sockets is that the communication channels are flawless. It is the developer's responsibility to ensure that, in the event of a lost message, the message is resent.

Unfortunately, these assumptions can make sockets difficult to use in some situations. With a growing emphasis on mobile computing these days, oftentimes computers that wish to participate in a distributed operating system may not be constantly connected to the network. Furthermore, setting up distributed application to run over a volatile network - that is, a wide area network that commonly experiences outages and other problems - can be anything but easy. Such a volatile network can wreck havoc, forcing the developer to implement message acknowledgement routines to ensure that messages are properly delivered and received. Clearly, sockets have their shortcomings in particular real-world settings.

Another laborious task developers of distributed applications are faced with is interoperability. A group of computers that form a distributed network must all use and understand the same protocol. Furthermore, the distributed application should work identically across all platforms. That is, a distributed application should be able to successfully run regardless of the platforms or operating systems of the participating computers.

As distributed applications have developed and as the field of distributed computer science has matured, a number of development tools have sprung up to aid designers of distributed applications in sending and receiving messages from various computers. These tools often use sockets at some lower level, but provide the developer with a high-level interface. With these advanced tools, the developer is relieved of the many burdens socket-use comes with, such as message acknowledgements.

In this paper I will examine Microsoft Message Queue (MSMQ). MSMQ is only useful for distributed applications that need to utilize asynchronous, loosely coupled messages (or can use such message passing methods without failing) (Houston 3). Therefore, algorithms that require tightly coupled communication - such as the Synchronous Checkpoint Algorithm - cannot utilize MSMQ. Where MSMQ does excel, however, is in lackadaisical applications (such as news servers), where real-time message passing and confirmation isn't vital.

Before I delve into the specifics of MSMQ I will briefly discussing the differences between loosely and tightly coupled.

Loosely Coupled Messages vs. Tightly Coupled Messages
Certain distributed algorithms, upon sending a message, require an immediate response from the site they sent a message to before they can send any other messages. Such algorithms are said to use tightly coupled messages. The Synchronous Checkpoint Algorithm uses tightly coupled message passing to establish a consistent cut between a number of computers. A site sending a loosely coupled message, on the other hand, does not require any sort of confirmation from the receiver site before sending any other messages to any other sites.

Loosely coupled messages are akin to asynchronous communication, while tightly coupled messages are akin to synchronous messages. The tightly coupled message is worried mother, who, after sending her baby to school sits at home anxiously awaiting young Timmy's return. Until Timmy walks through the front door at 3:30, mom does absolutely nothing but wait. Loosely coupled messages are better-adjusted mothers, ones who can pursue other, normal activities while their young one is away at school.

In class we've examined loosely coupled message algorithms and tightly coupled message algorithms. RPC uses tightly coupled messages. When a computer executes a remote procedure it shouldn't continue execution until the remote procedure completes. The vector clock algorithm, however, manages causality among loosely coupled messages.

  • Page 2 -->


  • ASP.NET [1.x] [2.0] | ASPMessageboard.com | ASPFAQs.com | Advertise | Feedback | Author an Article