Introduction
When you think of a queue, what do you think of? No, it’s not the selfish and all-powerful quantum beings (the “Q”) from the Star Trek Next Generation series. No, when I’m talking about a queue, I’m talking about the mechanism to transport messages to/from an enterprise (not the ship) application. There are two main flavors on the market today: IBM’s MQSeries, and Microsoft’s MSMQ. I’m not going to debate which one is better; too many have done that task before me. What I’d like to do is provide a component that will make monitoring particular messages in a queue much easier. My current platform of choice is MSMQ, but the concepts involved, albeit not the actual implementation, will be the same for MQSeries.
Specifics
Before the advent of the .NET framework, working with message queues was difficult. Using Windows APIs was cumbersome, and some of the ActiveX interfaces were downright impossible to use. The .NET framework now comes, out of the box, supporting message queuing, and it’s very simple to implement in an application. If you have the latest MQSeries client installed, it comes with a .NET DLL (amqmdnet.dll) you can use for queuing messages. Note that the two platforms (MQSeries and MSMQ) cannot exchange messages with one another (that would have been too simple) without a bridge application to marshal the messages from one message format to another (another idea for a component?).
With both products, when the queue is waiting for a message to arrive, it blocks, meaning that all activity on the thread where an instance of the queue resides halts until a message arrives, or a timeout is reached. Using the attached component for MSMQ, you can monitor a particular queue for a specific type of class/label that is placed onto a queue, specified by the TargetLabels property of the component. The MSMQQueueMonitor component does not block when waiting for a message to arrive, since the monitoring is spawned on a separate thread.
For simplicity, the component uses the Label property to identify targeted messages. If the static method MSMQQueueMonitor.SendMessageToQueue is used to place messages onto a queue, the Label property is set to the class name (type name) of the data being passed. This is probably not the best way to do it in a production environment, but you get the idea...we peek (examine) all dropped messages to get the label, but only receive (get) the ones the component is told to look for.
The component will work with messages formatted as Binary (BinaryMessageFormatter) or XML (XMLMessageFormatter). When using XML, a step outside of the component needs to be performed to let the queue know the types it should be deserializing. You’ll see this in the server and client code. ActiveXMessageFormatter is not supported.
Requirements
Remember, there is a 4 MB limit on the size of messages placed onto a message queue, so you might want to watch the size. If more data is returned that can fit in the 4 MB space, you will need to split these up into separate messages.
For this to run, you must be running Windows XP Professional, as XP Home does not support message queuing. To run the samples, you will also need to have Message Queuing installed on your workstation, since it is not installed by default in most installations.
- Go to Add/Remove Programs
- Select Add/Remove Windows Components
- Check Message Queuing if it is not already selected
- Continue setup
Once queuing is installed, you will also have to have two public queues created for the samples to work.
- Right-click My Computer
- Select Manage
- Open Services and Applications
- Open Message Queuing
- Right click Public Queues
- Select New -> Public Queue
- Name 1st queue myrequestqueue
- Name 2nd queue myresponsequeue
The sample comes with two executables: one is a console application acting as a server (queuemonitor) and the other is a desktop application (requestingapplication) acting as a client. It’s simpler to compile the solution and run either the client or the server application (or both) outside of the IDE. If you want to run it from the IDE to see it executed, you can set the client as the startup project and run it to do a search. The test data is stored in the EmployeeTestCollection…you can get search parameters from there. This places a request on the request queue. Shut the client down, set the server as the startup project, and run it. This will pick up the message from the request queue, process the request, and place a response on the response queue. Shut the server down, set the client as the startup project, and run it. When it is running, click the check box to monitor the reply queue, and the client will pick up the response and display it in the list view.
