One of the most over-looked bindings available in WCF is the Microsoft Message Queue (MSMQ) binding. The virtues of HTTP and TCP are well documented. REST is the cool, “new” way to access services. MSMQ seems relegated to interfacing WCF with older “legacy” systems.

This shouldn’t be the case. The MSMQ binding provides a rich set of features and functionality that make it an excellent choice for building many types of applications.

MSMQ from 1,000 ft.

MSMQ is a first-in, first-out message queue that have been available in Windows Server since NT 4. The concept is pretty simple: a sender sends a message to the queue, and a receive pulls it off when it’s ready.

The big benefit of MSMQ is that it allows messages to be passed between computers across networks in a secure, reliable manner. Since the queue is not an actual component of either application, the receiver does not need to be running when the message is sent (it will sit in the queue and wait to be picked up) nor does the receiver have to be on-line when the message is processed. Individual messages and queues allow one-way delivery of messages, but a second queue can be added to allow for duplexing.

Messages can sit in the queue either until a receiver grabs them or until they expire. Messages that expire are placed in a special “dead letters” queue.

Windows Vista introduced an upgrade to MSMQ called the “poison queue.” If a receiver attempts to process a message but can’t due to error, and it’s retry count is reached, it is placed into the poison queue. Previous to Vista the developer had to create a mechanism to identify these messages and “handle” them or risk attempting to process the same message over and over again until human intervention stopped it.

Queues can be transactional, meaning that if any part of a message fails, the entire message is rolled back. If the retry count has not been reached the receiver will attempt to process the message again until the count is reached and the message is moved to the poison queue.

The rest of this post assumes you have MSMQ installed on your computer and have a private transactional queue called HelloMSMQ. Instructions on how to add MSMQ and create a private queue can be found here.

Using the MSMQ Binding

OK, so now that we’ve got our private transactional queue created, the next steps are to create a message sender and message receiver. Using the netMSMQBinding binding will make this simple.

Note: There are two MSMQ bindings: the netMSMQBinding, which we will use, and the MSMQIntegratedBinding. The integrated binding is designed for using MSMQ to send/receive messages from legacy mainframe systems with MSMQ. For working with WCF to WCF communication use the “net” binding. Of course, you can expose multiple endpoints on your server, and making one endpoint “integrated” and the other “net” is an option if you need to proved services to both types of clients.

Since MSMQ by nature allows communication one way through a queue, you will need to make sure your service operation supports one-way calls. This is easily done by setting the IsOneWay property of the OperationContract to true:

The next step is to create your endpoint. Here is the configuration for the endpoint that this services is exposed on:

<endpoint address="net.msmq://localhost/private/HelloMsmq"
                   binding="netMsmqBinding"
                   bindingConfiguration="DomainlessMsmqBinding"
                   contract="HelloMsmq.IMyService"/>  

Like all endpoints, this one includes the “ABC’s” of address, binding and contract. Contract here is pretty much what you would expect. The address points to a queue residing on a server somewhere, in this case the local machine. This address specifically points to the private “HelloMsmq” queue on our local machine. The binding is the netMSMQBinding. The binding configuration specifies that we aren’t going to worry about security for messages in this queue:

<bindings>
      <netMsmqBinding>
        <binding name="DomainlessMsmqBinding" >
          <security>
            <transport
              msmqAuthenticationMode="None"
              msmqProtectionLevel="None"/>
          </security>
        </binding>
      </netMsmqBinding>
    </bindings>

SVCUTIL creates a proxy that works just like any other WCF proxy; the address points at the same private queue and it uses the netMSMQBinding. From that point on you use it like you would any other WCF service

Where Would You Use This?

The inherit abilities of this binding provides a lot of benefits that can be used in many common situations. Since the service does not have to be online while clients send messages, the binding works very well in batch processing situations; clients can add messages to the queue all day, with the service being turned on at night to process the messages in a batch.

If you have a portion of your workforce that travels or needs to work disconnected at periods of time, MSMQ provides a way for them to work offline, with the queues syncing when the client reconnects to the network.

MSMQ is also an inherently reliable binding. Since messages are stored in a queue they can be “re-played” by the service if any sort of connectivity issues exist. If the message can be written to the queue it’s guaranteed that it will be delivered, at some point, to the service.

I hope this has piqued your interest in a very unappreciated and underused binding. MSMQ provides a robust and easy to use method to deliver messages to your service in a variety of enterprise scenarios. Most posts on how to utilize this binding will be coming soon…

Code on!