The Bare Minimum Needed to Write a Msmq Sample Application

The bare minimum needed to write a MSMQ sample application

//From Windows Service, use this code
MessageQueue messageQueue = null;
if (MessageQueue.Exists(@".\Private$\SomeTestName"))
{
    messageQueue = new MessageQueue(@".\Private$\SomeTestName");
    messageQueue.Label = "Testing Queue";
}
else
{
    // Create the Queue
    MessageQueue.Create(@".\Private$\SomeTestName");
    messageQueue = new MessageQueue(@".\Private$\SomeTestName");
    messageQueue.Label = "Newly Created Queue";
}
messageQueue.Send("First ever Message is sent to MSMQ", "Title");

---

//From Windows application
MessageQueue messageQueue = new MessageQueue(@".\Private$\SomeTestName");
System.Messaging.Message[] messages = messageQueue.GetAllMessages();

foreach (System.Messaging.Message message in messages)
{
    //Do something with the message.
}
// after all processing, delete all the messages
messageQueue.Purge();

For more complex scenario, you could use Message objects to send the message, wrap your own class object inside it, and mark your class as serializable. Also be sure that MSMQ is installed on your system

Understanding the basics of MSMQ

First of all, is there a concept of specifying the recipient of a
message?

No, there is no routing or other behavior which can provide this. The producer and consumer are fully decoupled, and MSMQ doesn't support any kind of conditional message dequeuing.

...is there a concept of sending messages which are to be processed by
all consumers, not just the first one to receive?

Again, no there is no built in "publisher" functionality.

...does every implementation always consist of one or more producer(s)
and one or more consumer(s)?

Yes, that is correct. MSMQ only has native support for uni-directional messaging so any messaging endpoints involved in the message exchange will need a queue to read off and a queue to send to. By convention, a messaging exchange participant will send to a remote queue and receive from a local queue.

I guess the questions you are asking are indicative of an expectation that a queueing platform should provide more than one-way, asynchronous messaging, but I would disagree. MSMQ is more of a transport layer than a fully fledged messaging system, but it's a very solid, reliable foundation upon which to build the kind of enterprise features you are after.

As an example, WCF provides a request/response wrapper around MSMQ, which allows bi-directional communication.

NServiceBus brings both request/response and publish/subscribe messaging patterns to MSMQ (although this is a pay-for product at high messaging volumes/scale-out).

If you want to consider other messaging systems which have more of these enterprise features built in (but don't use MSMQ) you could look at Rabbit, or Azure Service Bus

subscribe to msmq

You could also use WCF to subscribe to messages from an MSMQ queue and handle them as a service method in your WCF service.

Check out

• How to Exchange messages with WCF endpoints and message queueing applications
• WCF and MSMQ
• Sample starter project with WCF and MSMQ
• SOA'zing MSMQ with WCF (and why it's worth it)

is there any event or callback on MSMQ for new message added to queue

You do not need any event or loop. Receive method will read from the queue and if the queue is empty it will block until a new message is added. If you need to do something else in the meantime, put the receiving code in a separate thread.

You can also use asynchronous approach by using BeginReceive. This will actually raise an event when message has been read from the queue.

---

Related Topics