How nice it is to live in an age of ever increasing network speeds. Faster networks and broadband Internet connections make work and play ever more enjoyable. But network problems still happen, and when your application cannot talk to all of it's components, still common enough in distributed applications, it can cause real problems. Most of the time we develop application exception code for this, but informing the user or components may not be enough. It may be vital to your application (and also, your job) that work still progresses. Enter Microsoft Message Queues.
We use message queuing every day. When you use your credit card, you may know that many companies do not process the actual transactions until the end of the business day. You may have heard people refer to 'batching out' at night, the act of using a modem to send all of their queued credit card transactions to the bank. This is an example of message queuing, but probably the best example of message queuing is email. Someone sends an email, a server collects it, and it sits there until someone retrieves and reads it.
Also consider the use of message queues from a bank's perspective. Say that this example bank receives transaction information at various globally distributed locations. It's a safe bet that requirements dictate that remote data containing information about these transactions is not lost under any circumstances. But being a global system, it is also a safe bet that this whole system will have to contend with high network traffic, high central processing load, or link outages. Message queues are a good way to store this data in transit.
As a side note, just as there are server and client processing rules for email, message queues can be manipulated to follow business rules as well, although we will not cover that topic in this application.