[Download Code]
Before I continue, allow me to acknowledge that a SQL Server database can act as a message queue. In fact, this concept is used quite often by many developers, but message queues have two immediate advantages over the use of SQL Server. The first advantage of message queues over SQL Server databases in temporarily storing data is flexibility. Message queues are easier to access when you consider the standard security and operational overheard involved in using SQL servers (security, access, drivers). The other major advantage in favor of message queues is cost--they are free.  Message queuing is built into the Windows business platforms that you have already purchased.

This application was developed on Windows Server 2003 acting as a member server in Active Directory, but you can use Windows XP as a stand-alone workstation. Message queues can be loaded during the installation of Windows or by adding the components via the Control Panel. The type of message queues that are available depend on your Active Directory connectivity. If you are in an Active Directory, you can make public message queues available that may be listed in the Active Directory.

If your development target system is not part of an Active Directory, your message queues will be private only. Once you have loaded the message queue components, you can right-click the server icon on your start menu or otherwise access the components via the Server Management controls. In this case I elected to use private message queues as they do not require Active Directory. The basic use of either type of queue is the same, but Active Directory-connected message queues offer functionality we will not cover here. I have also elected to pull data from the venerable old Pubs database via a local SQL Server database. You can find the connection string and change it at will to what you want, even using an Access DB as long as you configure your drivers accordingly.

With that described, let's get started by describing a little about this example application.

This example is broken out into a Windows Form and a functions class. This application is designed to work with text and DataSets in the local private queue. Other objects can be stored, but I have not coded the 'filters' for this. What this means is that storing your objects in a queue is simple, but retrieving them is a bit more work. We will cover this more later.

Allow me to explain why I used a Windows Form application versus an ASP.NET application. I am a web developer by trade, but my goal was to develop and distribute an easily-debugged application, so you could begin stepping thru the code quickly. This example does not require that you configure an ASP.NET environment, but the functions class can be dropped directly into an ASP.NET application. With the exception of a tree view method used by the Windows Form, all of this code can be used by ASP.NET. In fact, the tree view method should be easily modified for ASP.NET use as well.

Now let's consider the interface provided. Three group boxes are used to separate the text message, DataSet message, and tree view / queue manipulations sections. The text creation portion is fairly straight forward. Simply type in a label used as the name of the message and a text box to contain the data. The DataSet section is a little more involved but does the same thing with a bit more code added to allow you to make you own queries and clear the Windows Form DataGrid. A global DataSet is used to keep things simple. The last section is the message queue tree group. Here you can create and delete queues, refresh the tree view, and peek into messages.

This brings us back to the basic functionality of a message queue, which is to hold data. You will of course need to not only store but also retrieve data. Saving data is very simple, but retrieving data is a bit more involved. The first function to know about is the MessageQueue.Receive method. It does what it says, but it will remove the message from the queue. If you want to retrieve a copy of the Message, you will want to use the Peek method. Other than view and remove, the two methods are mostly the same.

I have elected to code for the Peek method only, as you will easily be able to adapt this code for your own needs upon seeing how the Peek method works. The other point to know about the Peek method (Receive as well) is that it will take the top message from the stack to process. For this reason I skipped the Peek method and moved right to the PeekByID method. Finally there is a delete queue function. You can delete the queue and all of it's messages, but you will be prompted to confirm that you are sure that you want to delete the queue if it contains messages.